Hi I have the following setup. server A eth1: 192.168.254.5/24 server A eth2: 192.168.253.1/24 Routing tables in A 0.0.0.0 196.44.37.X 0.0.0.0 UG 100 0 0 eth0 10.0.0.0 192.168.254.1 255.255.240.0 UG 0 0 0 eth1 192.168.253.0 0.0.0.0 255.255.255.252 U 0 0 0 eth2 192.168.254.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 196.44.37.Y 0.0.0.0 255.255.255.248 U 0 0 0 eth0 ip rule add fwmark 0x1 table net1 ip rule add fwmark 0x2 table net2 ip route add 10.0.0.0/20 via 192.168.254.1 table net1 ip route add 10.0.0.0/20 via 192.168.254.3 table net2 IPtables in Server A: *mangle -A PREROUTING -p tcp -m tcp --dst 10.0.4.2 -j MARK --set-mark 0x02 COMMIT *nat -A POSTROUTING -d 10.0.0.0/20 -j SNAT --to-source 192.168.254.5 COMMIT Server B eth2: 192.168.253.2/24 10.0.0.0 192.168.253.1 255.255.240.0 UG 0 0 0 eth2 192.168.253.0 0.0.0.0 255.255.255.252 U 0 0 0 eth2 When I ping from Server B 10.0.4.2 I need the route "10.0.0.0 192.168.254.1 255.255.240.0 UG 0 0 0 eth1" on server A or the returning packet does not get back to me, altough the routing to 10.0.4.2 goes via the net2 table. Kind Regards Jan van der Vyver ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Jan van der Vyver wrote:> I have the following setup. > > server A eth1: 192.168.254.5/24 > server A eth2: 192.168.253.1/24 > > Routing tables in A > > 0.0.0.0 196.44.37.X 0.0.0.0 UG 100 0 0 > eth0 > 10.0.0.0 192.168.254.1 255.255.240.0 UG 0 0 > 0 eth1 > > 192.168.253.0 0.0.0.0 255.255.255.252 U 0 0 > 0 eth2 > > 192.168.254.0 0.0.0.0 255.255.255.0 U 0 0 > 0 eth1 > 196.44.37.Y 0.0.0.0 255.255.255.248 U 0 0 0 > eth0 > > ip rule add fwmark 0x1 table net1 > ip rule add fwmark 0x2 table net2 > > ip route add 10.0.0.0/20 via 192.168.254.1 table net1 > ip route add 10.0.0.0/20 via 192.168.254.3 table net2 > > IPtables in Server A: > > *mangle > -A PREROUTING -p tcp -m tcp --dst 10.0.4.2 -j MARK --set-mark 0x02 > COMMIT > > *nat > -A POSTROUTING -d 10.0.0.0/20 -j SNAT --to-source 192.168.254.5 > COMMIT > > Server B eth2: 192.168.253.2/24 > > 10.0.0.0 192.168.253.1 255.255.240.0 UG 0 0 > 0 eth2 > 192.168.253.0 0.0.0.0 255.255.255.252 U 0 0 > 0 eth2 > > When I ping from Server B 10.0.4.2 I need the route > > "10.0.0.0 192.168.254.1 255.255.240.0 UG 0 0 0 eth1" > > on server A or the returning packet does not get back to me, altough the > routing to 10.0.4.2 goes via the net2 table. >Please forward the output of ''shorewall dump'' -- you aren''t looking at the entire picture. -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 \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Hope This helps to explain. Regards Jan -----Original Message----- From: Tom Eastep [mailto:teastep@shorewall.net] Sent: 24 June 2012 08:51 PM To: Shorewall Users Cc: Jan van der Vyver Subject: Re: [Shorewall-users] Why route needed in main routing table? Jan van der Vyver wrote:> I have the following setup. > > server A eth1: 192.168.254.5/24 > server A eth2: 192.168.253.1/24 > > Routing tables in A > > 0.0.0.0 196.44.37.X 0.0.0.0 UG 100 0 0 > eth0 > 10.0.0.0 192.168.254.1 255.255.240.0 UG 0 0 > 0 eth1 > > 192.168.253.0 0.0.0.0 255.255.255.252 U 0 0 > 0 eth2 > > 192.168.254.0 0.0.0.0 255.255.255.0 U 0 0 > 0 eth1 > 196.44.37.Y 0.0.0.0 255.255.255.248 U 0 0 0 > eth0 > > ip rule add fwmark 0x1 table net1 > ip rule add fwmark 0x2 table net2 > > ip route add 10.0.0.0/20 via 192.168.254.1 table net1 ip route add > 10.0.0.0/20 via 192.168.254.3 table net2 > > IPtables in Server A: > > *mangle > -A PREROUTING -p tcp -m tcp --dst 10.0.4.2 -j MARK --set-mark 0x02 > COMMIT > > *nat > -A POSTROUTING -d 10.0.0.0/20 -j SNAT --to-source 192.168.254.5 COMMIT > > Server B eth2: 192.168.253.2/24 > > 10.0.0.0 192.168.253.1 255.255.240.0 UG 0 0 > 0 eth2 > 192.168.253.0 0.0.0.0 255.255.255.252 U 0 0 > 0 eth2 > > When I ping from Server B 10.0.4.2 I need the route > > "10.0.0.0 192.168.254.1 255.255.240.0 UG 0 0 0 eth1" > > on server A or the returning packet does not get back to me, altough > the routing to 10.0.4.2 goes via the net2 table. >Please forward the output of ''shorewall dump'' -- you aren''t looking at the entire picture. -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 \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 06/25/2012 05:58 AM, Jan van der Vyver wrote:> Hope This helps to explain. >It doesn''t :-( The dash shell included in the latest versions of Ubuntu is not backward compatible with earlier versions. The recent Shorewall 4.5 releases work around this incompatibility -- 4.4.26 does not. The attached patch should work around the problem so that a useful dump can be obtained. patch /usr/share/shorewall/lib.cli < DASH.patch Better yet would be to upgrade your Shorewall installation. -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 \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Sorry about that. Updated to 4.5.5.1 Kind Regards Jan -----Original Message----- From: Tom Eastep [mailto:teastep@shorewall.net] Sent: 25 June 2012 04:01 PM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] Why route needed in main routing table? On 06/25/2012 05:58 AM, Jan van der Vyver wrote:> Hope This helps to explain. >It doesn''t :-( The dash shell included in the latest versions of Ubuntu is not backward compatible with earlier versions. The recent Shorewall 4.5 releases work around this incompatibility -- 4.4.26 does not. The attached patch should work around the problem so that a useful dump can be obtained. patch /usr/share/shorewall/lib.cli < DASH.patch Better yet would be to upgrade your Shorewall installation. -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 \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 06/25/2012 09:18 AM, Jan van der Vyver wrote:> Sorry about that. Updated to 4.5.5.1 >Are you seeing lots of ''Martian'' messages in /var/log/kern.log when you don''t have the route you mention? I''m guessing so, since you are (or your distro is) setting reverse path filtering on all interfaces. The reponse packets from 10.x.x.x are likely being dropped as martians. -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 \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>Are you seeing lots of ''Martian'' messages in /var/log/kern.log when youdon''t have the route you mention? I''m guessing so, since you are (or your>distro is) setting reverse path filtering on all interfaces. The reponsepackets from 10.x.x.x are likely being dropped as martians. interfaces: net eth0 detect tcpflags,nosmurfs,routefilter,logmartians,routeback apn eth1 detect tcpflags,nosmurfs,routefilter,logmartians,routeback itrn eth2 detect tcpflags,nosmurfs,routefilter,logmartians,routeback providers: #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY ll 1 0x1 - eth1:192.168.254.5 192.168.254.1 track,loose - sg 2 0x2 - eth1:192.168.254.5 192.168.254.3 track,loose - act 3 0x3 - eth1:192.168.254.5 192.168.254.4 track,loose - FROM http://shorewall.net/manpages/shorewall-interfaces.html Note There are certain cases where routefilter cannot be used on an interface: If USE_DEFAULT_RT=Yes in shorewall.conf(5) and the interface is listed in shorewall-providers(5). If there is an entry for the interface in shorewall-providers(5) that doesn''t specify the balance option. I have routefilter on in the intenrfaces file but acording to the note I cannot use it. Regards Jan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 06/25/2012 01:16 PM, Jan van der Vyver wrote:> > I have routefilter on in the intenrfaces file but acording to the note I > cannot use it.But you *are* using route filtering. From the dump: /proc/sys/net/ipv4/ip_forward = 1 /proc/sys/net/ipv4/icmp_echo_ignore_all = 0 /proc/sys/net/ipv4/conf/all/proxy_arp = 0 /proc/sys/net/ipv4/conf/all/arp_filter = 0 /proc/sys/net/ipv4/conf/all/arp_ignore = 0 /proc/sys/net/ipv4/conf/all/rp_filter = 1 <========= /proc/sys/net/ipv4/conf/all/log_martians = 0 /proc/sys/net/ipv4/conf/default/proxy_arp = 0 /proc/sys/net/ipv4/conf/default/arp_filter = 0 /proc/sys/net/ipv4/conf/default/arp_ignore = 0 /proc/sys/net/ipv4/conf/default/rp_filter = 1 <========= /proc/sys/net/ipv4/conf/default/log_martians = 1 /proc/sys/net/ipv4/conf/eth0/proxy_arp = 0 /proc/sys/net/ipv4/conf/eth0/arp_filter = 0 /proc/sys/net/ipv4/conf/eth0/arp_ignore = 0 /proc/sys/net/ipv4/conf/eth0/rp_filter = 1 <========= /proc/sys/net/ipv4/conf/eth0/log_martians = 1 /proc/sys/net/ipv4/conf/eth1/proxy_arp = 0 /proc/sys/net/ipv4/conf/eth1/arp_filter = 0 /proc/sys/net/ipv4/conf/eth1/arp_ignore = 0 /proc/sys/net/ipv4/conf/eth1/rp_filter = 1 <========= /proc/sys/net/ipv4/conf/eth1/log_martians = 1 /proc/sys/net/ipv4/conf/eth2/proxy_arp = 0 /proc/sys/net/ipv4/conf/eth2/arp_filter = 0 /proc/sys/net/ipv4/conf/eth2/arp_ignore = 0 /proc/sys/net/ipv4/conf/eth2/rp_filter = 1 <========= /proc/sys/net/ipv4/conf/eth2/log_martians = 1 /proc/sys/net/ipv4/conf/lo/proxy_arp = 0 /proc/sys/net/ipv4/conf/lo/arp_filter = 0 /proc/sys/net/ipv4/conf/lo/arp_ignore = 0 /proc/sys/net/ipv4/conf/lo/rp_filter = 1 <========= /proc/sys/net/ipv4/conf/lo/log_martians = 1 It is enabled (along with log_martians) on all of your interfaces. I suspect that you have something like this in /etc/sysctl.conf: net.ipv4.conf.default.rp_filter=1 net.ipv4.conf.all.rp_filter=1 -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 \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 06/25/2012 01:35 PM, Tom Eastep wrote:> On 06/25/2012 01:16 PM, Jan van der Vyver wrote: > >> >> I have routefilter on in the intenrfaces file but acording to the note I >> cannot use it. >> > It is enabled (along with log_martians) on all of your interfaces. > > I suspect that you have something like this in /etc/sysctl.conf: > > net.ipv4.conf.default.rp_filter=1 > net.ipv4.conf.all.rp_filter=1Or you have ROUTE_FILTER=Yes in shorewall.conf. -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 \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>Or you have ROUTE_FILTER=Yes in shorewall.conf.The was yes, I deactivated it. See new dump. I now get the following Jun 25 23:22:47 trio kernel: [1833703.280826] Shorewall:itrn2net:REJECT:IN=eth2 OUT=eth0 MAC=fe:e8:d7:56:44:b5:00:25:90:63:37:63:08:00 SRC=192.168.253.1 DST=10.0.4.2 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=21988 DF PROTO=TCP SPT=41146 DPT=9191 WINDOW=14600 RES=0x00 SYN URGP=0 TCRULE: 2:P 192.168.253.1 10.0.4.2 - RULE: ACCEPT:info itrn:192.168.253.1 apn:10.0.4.2 all - When I connect from server B(192.168.253.1) via Server A eth2(192.168.253.2) to the routers on Server A eth1(192.168.254.5) which has 10.0.0.0/20 behind 192.168.254.1 and 192.168.254.3 I get the reject above. I want an tcrule which should mark the connection above 0x2 and then it goes into the sg routing table and to 192.168.254.3 (with the SNAT to 192.168.254.5). Then the packet must come back to 192.168.253.1 Why do I get itrn2net chain? I would have expected itrn2apn chain? Must route_filter be on or off on this case? Is my tcrules wrong? Is my rule wrong? is there routes missing? Why is this not working? Sorry for asking so maby questions. It feels I''m so close but yet so far. Thank you for the support/help Regards Jan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 06/25/2012 02:34 PM, Jan van der Vyver wrote:>>> Or you have ROUTE_FILTER=Yes in shorewall.conf. > > The was yes, I deactivated it. See new dump. > > I now get the following > > Jun 25 23:22:47 trio kernel: [1833703.280826] > Shorewall:itrn2net:REJECT:IN=eth2 OUT=eth0 > MAC=fe:e8:d7:56:44:b5:00:25:90:63:37:63:08:00 SRC=192.168.253.1 DST=10.0.4.2 > LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=21988 DF PROTO=TCP SPT=41146 DPT=9191 > WINDOW=14600 RES=0x00 SYN URGP=0 > > TCRULE: > 2:P 192.168.253.1 10.0.4.2 - > > RULE: > ACCEPT:info itrn:192.168.253.1 apn:10.0.4.2 all - > > When I connect from server B(192.168.253.1) via Server A eth2(192.168.253.2) > to the routers on Server A eth1(192.168.254.5) which has 10.0.0.0/20 behind > 192.168.254.1 and 192.168.254.3 I get the reject above. > > I want an tcrule which should mark the connection above 0x2 and then it goes > into the sg routing table and to 192.168.254.3 (with the SNAT to > 192.168.254.5). Then the packet must come back to 192.168.253.1 > > Why do I get itrn2net chain? I would have expected itrn2apn chain? > > Must route_filter be on or off on this case?Turn route_filter off -- it never helps and can only hurt when you are trying to debug.> Is my tcrules wrong? > Is my rule wrong? > is there routes missing? > Why is this not working?It''s not working because there is still a default route in the main routing table and your routing rules are checking the packet marks *after* the main table is traversed. Let''s back up a bit -- what exactly are you trying to accomplish here? When I see the long list of tcrules targeting individual pairs of IP addresses, I''m certain that there has to be a better way. -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 \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 06/25/2012 02:58 PM, Tom Eastep wrote:> On 06/25/2012 02:34 PM, Jan van der Vyver wrote:>> Why is this not working? > > It''s not working because there is still a default route in the main > routing table and your routing rules are checking the packet marks > *after* the main table is traversed.To close out this thread, I talked to Jan on IRC yesterday and suggested that he add his external interface as a provider with ''balance''. At last report, that was working as expected. The problem being solved here is one of duplicate RFC-1918 subnets with the duplication being beyond Jan''s control. -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 \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/