Re: [Shorewall-users] SW private address access 'out' its external interface to a single device?
Tom Simon you have an invalid IP configuration since the subnet between modem and firewall is the same as your internal network. Thus it's not possible to correctly route traffic to allow internal devices to access the modem. Thanks for pointing that out. A quick change/test to [net] | EXT: DHCP Client Uverse/ATT modem (bridge mode) INT: DHCP Server WebServer @ http://192.168.1.254 | | EXT: DHCP Client - IP == 1.2.3.4 Linux Router/Firewall (shorewall) INT: 10.0.1.100 | |---| --- --- EXT: 10.0.1.10 EXT: 10.0.1.20 Linux LaptopLinux MailServer (temp) --- --- and SHOREWALL/shorewall.conf NULL_ROUTE_RFC1918=No ROUTE_FILTER=No SHOREWALL/masq (empty) SHOREWALL/routes (empty) appears to solve the ACCESS problem. I am able to browse to http://192.168.1.254 from the 10.0.1.0/24 LAN. What you need to do is renumber one or other of the networks so that the subnets do not overlap. Once you have done that, you'll find that the modem is directly reachable - though you may need to relax your RFC1918 filtering*. If you don't change your masq config, then the modem will see traffic coming from your external address. You can alter that by specifying (from memory) net:!192.168.2.0/24 in your masq config file (assuming you'd changed the modem to be in the 192.168.2.0/24 subnet). * If you are still using (from memory) norfc1918 which IIRC is deprecated, then you'll need to remove it and apply rules. You need to add permit rules for the outside private network. So you'll need rules like : permit lan net:192.168.2.0/24 deny lan net:192.168.0.0/16 deny lan net:172.16.0.0/12 deny lan net:10.0.0.0/8 You are filtering RFC1918 traffic on egress aren't you ? Now, for access control/filtering of the rfc1918 nets, after reading http://shorewall.net/manpages/shorewall.conf.html http://shorewall.net/MultiISP.html#null_routing , what I've had is embarrassingly sloppy. Starting to clean up, with SHOREWALL/shorewall.conf NULL_ROUTE_RFC1918=No ROUTE_FILTER=No SHOREWALL/interfaces net EXT_IF optional,physical=eth0,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0 vpn1VPN_IF optional,physical=tun1,logmartians=0,routefilter=0,routeback=1 - INT_IF physical=eth1,dhcp,tcpflags,logmartians=1,routefilter=0 SHOREWALL/providers ISP01 1 0x100main EXT_IF detect track,balance INT_IF VPN01 2 0x200main VPN_IF 10.254.254.1 track,fallback INT_IF SHOREWALL/routes ISP01 10.0.0.0/8 blackhole ISP01 172.16.0.0/12 blackhole # ISP01 192.168.0.0/16 blackhole # ISP01 192.168.1.254/24- eth0 I've still got access to the 'net AND the modem's webserver. But if I add the 192. rfc1918 block to the restrictions, with and exlcusion for the modem's webserver, SHOREWALL/routes ... - # ISP01 192.168.0.0/16 blackhole - # ISP01 192.168.1.254/32- eth0 + ISP01 192.168.0.0/16 blackhole + ISP01 192.168.1.254/24- eth0 On compile I get an ERROR, ... Adding Providers... RTNETLINK answers: Invalid argument ERROR: Command /sbin/ip -4 route add 192.168.1.254/24 dev eth0 table ISP01 Failed Restoring Shorewall Lite... ... I'm not clear if uncommenting those two lines is incorrect, or correct with a problem elsewhere. (Looking at those permit/deny 'rules' ... are those generated when /routes are sepcified? Re-reading, I'm not sure I've got the right settings in shorewall.conf, and for routefilter= in /interfaces. Particularly whether when using /routes with ... blackhole ... if I need to ALSO specify other than NULL_ROUTE_RFC1918=No in shorewall.conf. In any case, what needs to be fixed in my config above to retain access and properly filter rfc1918 egress? -- ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Adding routes on shorewall
Hi everyone! I need some help with a four interface shorewal. I have two ISPs (eth0 and eth1), a DMZ (eth2) and a local subnet (eth3). I configured the providers file with the two ISPs. Internet access is working fine. On eth3, I have two different subnets: 10.50.105.0/25 and 10.50.3.0/24. The eth3 interface is configured with the IP 10.50.105.88 and it is reaching all this network (can ping other hosts on the same network). However I can't access any host on 10.50.3.0/24. The only way I fixed it was disabling the firewall and adding a static route using 10.50.3.253 as gateway. I can't use this configuration because I loose external access and our system stops working. If I add this route manually when shorewall is up, I loose the external access too. Is there anyway I can add this route on shorewall configuration to startup automatically? Best regards! João K. -- ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Reverse Path filtering: iptables and kernel ?
Hello, When specifying a rpfilter option for an interface, we can see after applying the firewall configuration that there is a rpfilter being added for that interface, as well as a rpfilter chain. OTOH, no rp_filter option is set in /proc/sys/net/ipv4/conf/interface|all/rp_filter. What is the difference between what seems to be two different reverse path filtering options. One is being observed by iptables and the other as a kernel module ... ? Thanks. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] init dependency ordering for system net stack, shorewall + openvpn?
On 5/26/2015 12:36 PM, PGNd wrote: Tom On Tue, May 26, 2015, at 12:15 PM, Tom Eastep wrote: Is the OpenVPN tunnel also a provider? yes, it is. Then I think that the most straight-forward thing to do is: a) Make the OpenVPN interface 'optional' with no 'wait=' specified in the interfaces file. b) Start OpenVPN after Shorewall-lite. c) Use OpenVPN scripting to enable the interface after the tunnel is up (shorewall-lite enable tunX) and to disable it when the tunnel goes down (shorewall-lite disable tunX). -Tom -- Tom Eastep\ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \ signature.asc Description: OpenPGP digital signature -- ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] SW private address access 'out' its external interface to a single device?
I've setup a DHCP connected linux box. It runs Shorewall. [net] | EXT: DHCP Client Uverse/ATT modem (bridge mode) INT: DHCP Server WebServer @ http://192.168.1.254 | | EXT: DHCP Client - IP == 1.2.3.4 Linux Router/Firewall (shorewall) INT: 192.168.1.100 | |---| --- --- EXT: 192.168.1.10 EXT: 192.168.1.20 Linux LaptopLinux MailServer (temp) --- --- Shorewall's config'd to allow in-/out-bound traffic between the LAN and the 'net. It works as intended -- Laptop MailServer are both net-functional. What I haven't managed to do, is access the modem's WebServer @ http://192.168.1.254 from the LAN. If the Laptop's directly connected to the Modem, without the Shorewall instance in between, no problem. I need to punch a hole with Shorewall to allow only LAN access to the modem's WebServer on the 192.168.1.0/24 segment, and no further. How do I properly allow that traffic, on a 'private' address segment, in/out the SW external address? Do I need to also assign a 192.168.1.X addr too the SW ext intfc? To date, I've typically config'd with private addresses NEVER being routed on the SW external interface. Not sure if it's either possible or recommended. -- ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] init dependency ordering for system net stack, shorewall + openvpn?
On Tue, May 26, 2015, at 12:47 PM, Tom Eastep wrote: Then I think that the most straight-forward thing to do is: a) Make the OpenVPN interface 'optional' with no 'wait=' specified in the interfaces file. Done. b) Start OpenVPN after Shorewall-lite. Starting it with a script from within SW? or, using the Openvpn systemd unit's dependencies? If the former, where: in SHOREWALL/started? If the latter, after which systemd dependency -- shorewall-lite.service, shorewall-lite.target, shorewall-init.service or shorewall-init.target? c) Use OpenVPN scripting to enable the interface after the tunnel is up (shorewall-lite enable tunX) and to disable it when the tunnel goes down (shorewall-lite disable tunX). At the moment, I'm using wicked ifup tun1 wicked ifdown tun1 in Openvpn's up/down scripts. I'm not clear on any advantage/requirement of either using wicked or shorewall-lite to toggle the tun1 intfc's up/down state. Is there a preference / recommendation between them? Thanks. -- ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] init dependency ordering for system net stack, shorewall + openvpn?
On 5/25/2015 2:58 PM, PGNd wrote:
I have OpenVPN Shorewall-lite installed on an Opensuse server, running its
'wicked' networking stack.
It's an all systemd-controlled init environment.
I'm interested in ordering the system network stack, openvpn and shorewall
service starts correctly to ensure that there's no unnecessary/insecure open
'hole' during startup.
Reading
OpenVPN Tunnels and Bridges
http://shorewall.net/OPENVPN.html
I don't get the necessary order, or whether I need to worry about it at all.
In my current config, I first create the tun device @ system boot,
cat /etc/sysconfig/network/ifcfg-tun1
BOOTPROTO='static'
STARTMODE='manual'
TUNNEL='tun'
TUNNEL_SET_GROUP='openvpn'
TUNNEL_SET_OWNER='openvpn'
TUNNEL_SET_PERSISTENT='yes'
IPADDR=
IPV6INIT='no'
Then I subsequently bring up/down the openvpn interface when I start/stop the
openvpn service,
cat /etc/systemd/system/openvpn.service
[Unit]
Description=OpenVPN Server
After=syslog.target network-online.target
Before=openvpn-custom.target
Wants=network-online.target
[Service]
PrivateTmp=true
Environment=PATH=/usr/local/openvpn-unpriv:/usr/local/scripts:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
Type=forking
ExecStartPre=/usr/local/etc/openvpn/scripts/up.script
ExecStart=/usr/local/openvpn/sbin/openvpn \
--daemon \
--writepid /var/run/openvpn/openvpn.pid \
--cd /usr/local/etc/openvpn/ \
--config client.conf
ExecStopPost=/usr/local/etc/openvpn/scripts/down.script
Restart=always
RestartSec=30
[Install]
WantedBy=multi-user.target
cat /usr/local/etc/openvpn/scripts/up.script
#!/bin/sh
VPN_DEV=tun1
/usr/bin/sudo /usr/sbin/wicked ifup ${VPN_DEV}
cat /usr/local/etc/openvpn/scripts/down.script
#!/bin/sh
VPN_DEV=tun1
/usr/bin/sudo /sbin/ip addr flush ${VPN_DEV} 2/dev/null
1/dev/null
/usr/bin/sudo /usr/sbin/wicked ifdown ${VPN_DEV} --no-delete
That's straightfoward enough.
What I'm not certain about is the relative startup trigger/order of shorewall
and openvpn.
As packaged, Shorewall's unit files' dependencies include
cat /usr/lib/systemd/system/shorewall-init.service
[Unit]
Description=Shorewall IPv4 firewall (bootup security)
Before=network.target
Conflicts=iptables.service ip6tables.service firewalld.service
...
cat /usr/lib/systemd/system/shorewall-lite.service
[Unit]
Description=Shorewall IPv4 firewall (lite)
Wants=network-online.target
After=network-online.target
Conflicts=iptables.service firewalld.service
...
When, relative to the four available shorewall systemd timing/dependency
points
shorewall-init.service
shorewall-init.target
shorewall-lite.service
shorewall-lite.target
should Openvpn be launched?
With a change to Openvpn's unit,
Description=OpenVPN Server
- After=syslog.target network-online.target shorewall-lite.target
+ After=syslog.target network-online.target
+ Requires=shorewall-lite.service
?
Or similar in shorewall's units?
Or via pre-up/down or post-up/down scripts either in the unit files, or
within the openvpn /or shorewall application scripts themselves?
Is the OpenVPN tunnel also a provider?
-Tom
--
Tom Eastep\ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \
signature.asc
Description: OpenPGP digital signature
--
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Reverse Path filtering: iptables and kernel ?
On 5/26/2015 7:53 AM, jonetsu wrote: Hello, When specifying a rpfilter option for an interface, we can see after applying the firewall configuration that there is a rpfilter being added for that interface, as well as a rpfilter chain. OTOH, no rp_filter option is set in /proc/sys/net/ipv4/conf/interface|all/rp_filter. What is the difference between what seems to be two different reverse path filtering options. One is being observed by iptables and the other as a kernel module ... ? See shorewall-interfaces(5) and note the difference between 'routefilter' and 'rpfilter'. 'routefilter' uses /proc while 'rpfilter' is done via iptables. -Tom -- Tom Eastep\ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \ signature.asc Description: OpenPGP digital signature -- ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] init dependency ordering for system net stack, shorewall + openvpn?
Tom On Tue, May 26, 2015, at 12:15 PM, Tom Eastep wrote: Is the OpenVPN tunnel also a provider? yes, it is. -- ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] SW's default findgw looks in wrong dhcp lease location on opensuse+wicked net stack
I'm switching my current linux box from staticIP - dynamicIP via dhcp.
On net start of my linux box, connecting via native wicked dhcp on Opensuse
13.2,
wicked ifdown eth0 wicked ifup eth0
I have connectivity
ip -4 addr show dev eth0
4: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc
pfifo_fast state UP group default qlen 1000
inet AA.AA.AA.215/22 brd BB.BB.BB.255 scope global eth0
valid_lft forever preferred_lft forever
ip route show
default via AA.AA.AA.1 dev eth0 proto dhcp
AA.AA.AA.0/22 dev eth0 proto kernel scope link src
AA.AA.AA.215
10.1.1.0/24 dev eth1 proto kernel scope link src
10.1.1.100
ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=25.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=25.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=25.2 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 25.263/25.578/25.775/0.225 ms
But on shorewall start
systemctl start shorewall-lite
I lost connection
ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
(no response)
Checking the routes, SW's changed the default route, assigning the wrong gateway
ip route show
default via XX.XX.XX.1 dev eth0
XX.XX.XX.1 dev eth0 scope link src AA.AA.AA.215
AA.AA.AA.0/22 dev eth0 proto kernel scope link src
AA.AA.AA.215
10.1.1.0/24 dev eth1 proto kernel scope link src
10.1.1.100
That XX.XX.XX.1 has nothing to do with my current ISP or config -- it's a VERY
old gateway from years ago.
I'd no idea where Shorewall's was getting that XX.XX.XX.1 gateway.
It's not in my shorewall config sources
cd /usr/local/etc/shorewall
grep -rlni XX.XX.XX .
(empty)
It's not in the target firewall
cd /var/lib/shorewall-lite
grep -rlni XX.XX.XX .
(empty)
And it's not in the dhcp lease file.
grep XX.XX.XX /var/lib/wicked/lease-eth0-dhcp-ipv4.xml
(empty)
tracing the restart finds the source
+++ gateway=
+++ file=/var/lib/dhcpcd/dhcpcd-eth0.info
+++ '[' -z '' -a -f /var/lib/dhcpcd/dhcpcd-eth0.info ']'
grep '^GATEWAYS=' /var/lib/dhcpcd/dhcpcd-eth0.info
+++ eval 'GATEWAYS='\''XX.XX.XX.1'\'''
GATEWAYS=XX.XX.XX.1
+++ '[' -n XX.XX.XX.1 ']'
+++ GATEWAYS=XX.XX.XX.1
+++ gateway=XX.XX.XX.1
+++ for file in '${VARLIB}/dhcp/dhclient-${1}.lease'
'${VARLIB}/dhcp/dhclient.${1}.leases'
+++ '[' -n XX.XX.XX.1 ']'
+++ break
+++ '[' -n XX.XX.XX.1 ']'
+++ echo XX.XX.XX.1
++ gateway=XX.XX.XX.1
++ '[' -n XX.XX.XX.1 ']'
++ '[' -n XX.XX.XX.1 ']'
++ '[' -n XX.XX.XX.1 ']'
++ echo XX.XX.XX.1
+ SW_ETH0_GATEWAY=XX.XX.XX.1
It's
/var/lib/dhcpcd/dhcpcd-eth0.info
a very old, pre-'wicked' networking stack dhcp lease file left dangling around.
Removing
rm -f /var/lib/dhcpcd/*eth0*
Now, cycling SW no longer breaks the route connection.
wicked ifdown eth0 wicked ifup eth0
shorewall-lite restart
ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=25.6 ms
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 25.642/25.642/25.642/0.000 ms
ip show route
default via AA.AA.AA.1 dev eth0
AA.AA.AA.0/22 dev eth0 proto kernel scope link src
AA.AA.AA.215
AA.AA.AA.1dev eth0 scope link src AA.AA.AA.215
10.1.1.0/24 dev eth1 proto kernel scope link src
10.1.1.100
IIUC, SW's not 'getting' the SW_ETH0_GATEWAY / SW_ETH0_ADDRESS
SW's default findgw
#if [ -f /var/lib/dhcp/dhclient.${1}.lease ]; then
#grep 'option routers' /var/lib/dhcp/dhclient.${1}.lease | tail -n
1 | while read j1 j2 gateway; do echo $gateway | sed 's/;//'; return 0; done
#fi
appears unaware of
/var/lib/wicked/lease-eth0-dhcp-ipv4.xml
et al.
Should wicked's default lease location be added to that default SW code/search
path? With priority if/when wicked is in use?
Or should this be left to the end-user to DIY in
SHOREWALL/findgw
config? If so, what's the right method to ensure that SW_ETH#_GATEWAY /
SW_ETH#_ADDRESS get correctly populated when 'detect' in providers is set for a
given interface, when using custom findgw
Re: [Shorewall-users] init dependency ordering for system net stack, shorewall + openvpn?
On 5/26/2015 1:01 PM, PGNd wrote: On Tue, May 26, 2015, at 12:47 PM, Tom Eastep wrote: Then I think that the most straight-forward thing to do is: a) Make the OpenVPN interface 'optional' with no 'wait=' specified in the interfaces file. Done. b) Start OpenVPN after Shorewall-lite. Starting it with a script from within SW? or, using the Openvpn systemd unit's dependencies? If the former, where: in SHOREWALL/started? Shorewall isn't a service manager -- the only time I use Shorewall to start a service is if the service developer doesn't supply init scripts. If the latter, after which systemd dependency -- shorewall-lite.service, shorewall-lite.target, shorewall-init.service or shorewall-init.target? You want to start OpenVPN *after* Shorewall-lite has started (however you do that with systemd). c) Use OpenVPN scripting to enable the interface after the tunnel is up (shorewall-lite enable tunX) and to disable it when the tunnel goes down (shorewall-lite disable tunX). At the moment, I'm using wicked ifup tun1 wicked ifdown tun1 in Openvpn's up/down scripts. I'm not clear on any advantage/requirement of either using wicked or shorewall-lite to toggle the tun1 intfc's up/down state. Is there a preference / recommendation between them? I have no preference since I don't even know what 'wicked' is, and I don't run systemd. -Tom -- Tom Eastep\ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \ signature.asc Description: OpenPGP digital signature -- ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] SW private address access 'out' its external interface to a single device?
On 5/26/2015 1:05 PM, PGNd wrote: I've setup a DHCP connected linux box. It runs Shorewall. [net] | EXT: DHCP Client Uverse/ATT modem (bridge mode) INT: DHCP Server WebServer @ http://192.168.1.254 | | EXT: DHCP Client - IP == 1.2.3.4 Linux Router/Firewall (shorewall) INT: 192.168.1.100 | |---| --- --- EXT: 192.168.1.10 EXT: 192.168.1.20 Linux LaptopLinux MailServer (temp) --- --- Shorewall's config'd to allow in-/out-bound traffic between the LAN and the 'net. It works as intended -- Laptop MailServer are both net-functional. What I haven't managed to do, is access the modem's WebServer @ http://192.168.1.254 from the LAN. If the Laptop's directly connected to the Modem, without the Shorewall instance in between, no problem. I need to punch a hole with Shorewall to allow only LAN access to the modem's WebServer on the 192.168.1.0/24 segment, and no further. How do I properly allow that traffic, on a 'private' address segment, in/out the SW external address? Do I need to also assign a 192.168.1.X addr too the SW ext intfc? To date, I've typically config'd with private addresses NEVER being routed on the SW external interface. Not sure if it's either possible or recommended. all-users You have an unworkable IP configuration -- the Uverse/ATT modem's internal IP address is in the same network as your local systems. -Tom -- Tom Eastep\ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \ signature.asc Description: OpenPGP digital signature -- ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] SW private address access 'out' its external interface to a single device?
PGNd d...@pgnd.us wrote: I've setup a DHCP connected linux box. It runs Shorewall. [net] | EXT: DHCP Client Uverse/ATT modem (bridge mode) INT: DHCP Server WebServer @ http://192.168.1.254 | | EXT: DHCP Client - IP == 1.2.3.4 Linux Router/Firewall (shorewall) INT: 192.168.1.100 | |---| --- --- EXT: 192.168.1.10 EXT: 192.168.1.20 Linux LaptopLinux MailServer (temp) --- --- Tom has beaten me to it - you have an invalid IP configuration since the subnet between modem and firewall is the same as your internal network. Thus it's not possible to correctly route traffic to allow internal devices to access the modem. What you need to do is renumber one or other of the networks so that the subnets do not overlap. Once you have done that, you'll find that the modem is directly reachable - though you may need to relax your RFC1918 filtering*. If you don't change your masq config, then the modem will see traffic coming from your external address. You can alter that by specifying (from memory) net:!192.168.2.0/24 in your masq config file (assuming you'd changed the modem to be in the 192.168.2.0/24 subnet). * If you are still using (from memory) norfc1918 which IIRC is deprecated, then you'll need to remove it and apply rules. You need to add permit rules for the outside private network. So you'll need rules like : permit lan net:192.168.2.0/24 deny lan net:192.168.0.0/16 deny lan net:172.16.0.0/12 deny lan net:10.0.0.0/8 You are filtering RFC1918 traffic on egress aren't you ? NB - I had a similar setup at one time, with an ADSL modem on RFC1918 address and router getting address from ISP by DHCP. -- ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
