On Wed, May 30, 2001 at 08:56:37PM -0500, Rodrigo Goya wrote: > > It might be that the linux router sends you ICMP redirects as the > > forwarding interface is the same as the incoming interface but > > it also should've happened when you "ping 192.168.1.8 "on Sun-1. > > I had problems with a linux router doing NAT on the same interface, > it was doing redirects, and though packets were "seen" on the wire with > tcpdump, there were conflicts between private and public IPs and the > packets were lost. > > Don't know if this is the case here, but just in case you could set all > the "send_redirects" in /proc/sys/net/ipv4/conf to 0. > I don't think that is what's happening here. Just today, I had one linux router with the correct source IP and a more specific route with a different IP (I'm working with IPsec tunnels here) When I ran a ping through the tunnel to the host described above it would respond; but if I initiated a ping from the host, it would choose the more specific route and thus the wrong one for my purposes. Here's an example (this is gatway to gateway; if hosts already within the specified subnets can't communicate, the tunnel isn't working at all): host a inet ip: 1.2.3.4 local subnet: 192.168.1.0/24 internal ip: 192.168.1.1 host b inet ip: 9.8.7.6 local subnet: 10.1.1.0/24 internal ip: 10.1.1.1 tunnel: 192.168.1.0/24 (1.2.3.4) ==== (9.8.7.6) 10.1.1.0/24 In order to get the traffic tunneled you have to change the source IP: on a: ip ro rep 10.1.1.0/24 dev ($dev) src 192.168.1.1 on b: ip ro rep 192.168.1.0/24 dev ($dev) src 10.1.1.1 </example> Now that we have that history behind us... What I did wrong was: ip ro rep 10.1.1.0/24 dev ($dev) ip ro rep 10.1.1.0/8 dev ($dev) src 192.168.1.1 It would respond only to incomming packets, but not connections initiated from this host. Ok.... I looked at the origional post... didn't before... :( This won't help at all. Maybe it'll help someone else... Mike
