Thanks Julian. > ip route add 172.16.0.0/20 via 172.16.16.3 dev eth1 src 172.16.16.1 That's not really what I want to do. I want everthing bound for the 0.0/20 subnet, no matter the source, to route thru 16.3. 16.1 is the firewall/router and it might initiate some packets, but there are a bunch of hosts in 16.0 that will also initiate packets. The echo reply packets that are giving me problems should be just like any other IP packet shouldn't they? I don't want to filter or redirect or masquerade or shape any of this, just route it. Note the problem is in replying to anybody in 0.0/20 - I use 0.252 because it's a convenient host. My test packets come from 16.2 (they could come from anybody in 16.0/20), replying to 0.252. Since the default gw from 16.2 is 16.1, the echo reply should flow like this: 16.2 --> 16.1 --> 16.3 --> (VPN stuff) --> 0.251 --> 0.252. Since 16.1 has a specific route to 16.3 for anything with destination 0.0/20, it should just forward it back out eth1 and over to 16.3. But it doesn't - it just bitbuckets the dad-blamed thing! That's why I think I'm looking at a kernel bug. Note the physical path inside the Linux box. The packet comes in eth1 and I want to sent it back out eth1. I think that's the key. I am trying to route a packet out the same interface on which it came in. > If clearing all send_redirects and rp_filter flags to 0 and > using correct preferred source IP addresses does not help then you > hit a kernel bug. Try with recent kernel. But this all works well with similar testing using the 2.2 kernel on the other end. It's the 2.4.2-2 kernel that ships with Red Hat 7.1 giving me problems. > you are trying alternative routes which work only by using my patches, > the following can't work in plain kernel: >> 172.16.0.0/20 via 172.16.16.3 dev eth1 >> 172.16.0.0/20 via 172.16.16.151 dev eth1 Apologies for that one. That was from a bunch of troubleshooting yesterday and only yesterday. Here is the way it is normally setup: [root@csfampls-fw gregs]# /sbin/ip route show aaa.bbb.228.32/27 dev eth0 proto kernel scope link src aaa.bbb.228.33 ccc.ddd.200.64/27 via aaa.bbb.228.34 dev eth0 172.16.16.0/20 dev eth1 proto kernel scope link src 172.16.16.1 172.16.0.0/20 via 172.16.16.3 dev eth1 127.0.0.0/8 dev lo scope link default via aaa.bbb.228.62 dev eth0 - Greg -----Original Message----- From: Julian Anastasov [mailto:ja@ssi.bg] Sent: Thursday, February 28, 2002 4:49 PM To: Greg Scott Cc: LARTC@mailman.ds9a.nl; Patsy Rossow (E-mail) Subject: RE: [LARTC] Re: Routing that doesn't route Hello, On Thu, 28 Feb 2002, Greg Scott wrote: > > What is the value in /proc/sys/net/ipv4/conf/eth1/send_redirects ? > > [root@csfampls-fw /]# more /proc/sys/net/ipv4/conf/eth1/send_redirects > 1 This is one of the values you can try to alter. Try to set both all/send_redirects and eth1/send_redirects to 0. > > On each Linux try to check with > > ip route get from <SADDR> to <DADDR> iif <IN_DEVICE> > > [root@csfampls-fw /]# > [root@csfampls-fw /]# /sbin/ip route get from 172.16.16.2 to 172.16.0.252 > iif eth1 > 172.16.0.252 from 172.16.16.2 via 172.16.16.3 dev eth1 src 172.16.16.1 > cache <src-direct,redirect> mtu 1500 iif eth1 OK, traffic is not dropped from rp_filter. But this box should send ICMP redirects (note the "redirect" flag), i.e. it redirects traffic from 16.2 to 0.252 through 16.3. If you try with {all,eth1}/send_redirects=0 the traffic will be silently accepted and then forwarded to 16.3. > [root@csfampls-fw /]# > [root@csfampls-fw /]# /sbin/ip route show > aaa.bbb.228.32/27 dev eth0 proto kernel scope link src aaa.bbb.228.33 > ccc.ddd.200.64/27 via aaa.bbb.228.34 dev eth0 > 172.16.16.0/20 dev eth1 proto kernel scope link src 172.16.16.1 you are trying alternative routes which work only by using my patches, the following can't work in plain kernel: > 172.16.0.0/20 via 172.16.16.3 dev eth1 > 172.16.0.0/20 via 172.16.16.151 dev eth1 Note also that the above routes should have a preferred source IP. Avoid using the "route" tool in advanced routing setups. Try with "ip": ip route add 172.16.0.0/20 via 172.16.16.3 dev eth1 src 172.16.16.1 > 127.0.0.0/8 dev lo scope link same here, make sure all your routes have right preferred source IP: > default via aaa.bbb.228.62 dev eth0 In the other case you risk the kernel to select wrong IP address for your originating or masqueraded traffic. > [root@csfampls-fw /]# > > > One of the problems > > could be the conf/DEV/rp_filter settings but I don't see why it should > > drop the packets. > > How do I look at these and what are they? /proc/sys/net/ipv4/conf/{all,eth1}/rp_filter but it seems it's not a problem. Of course, try to set all them to 0 for the test. > Every setting I can think of so far looks good. What am I > missing???? Or is there a bug? Note, this is happening in two completely > unrelated places. But it could be that I set up both places with the same > mistake. If clearing all send_redirects and rp_filter flags to 0 and using correct preferred source IP addresses does not help then you hit a kernel bug. Try with recent kernel. > thanks > > - Greg Scott Regards -- Julian Anastasov <ja@ssi.bg> _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
