Hello, On Fri, 1 Mar 2002, Greg Scott wrote: > > 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 Right, just test it. The src parameter has different purpose, it is not a key for selecting the traffic, it is a result. It will be used for traffic originated from the 16.1 box. OTOH, it is difficult to pass non-negotiated traffic (subnets) through the IPSec tunnel. Make sure you can really pass traffic with any source through this tunnel. But this is different issue. > 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. Check the device flags I mentioned first. > > 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. ok, stop the ICMP redirects and see the difference. > - Greg Regards -- Julian Anastasov <ja@ssi.bg>
