Hello, On Mon, 26 Nov 2001, Greg Scott wrote: > [root@xxxxxxxxxxx /etc]# /sbin/route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface > mmm.mmm.228.32 0.0.0.0 255.255.255.224 U 0 0 0 eth0 > sss.sss.200.64 mmm.mmm.228.34 255.255.255.224 UG 0 0 0 eth0 > 172.16.16.0 0.0.0.0 255.255.240.0 U 0 0 0 eth1 > 172.16.0.0 172.16.16.3 255.255.240.0 UG 0 0 0 eth1 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo > 0.0.0.0 206.144.228.62 0.0.0.0 UG 0 0 0 eth0 > [root@xxxxxxxxxxx /etc]# > > Other protocols work fine. I tried some tests with DNS and ftp from > St. Peter to Minneapolis and they make the round trip just fine. Only > ICMP ECHO REPLY packets fail the round trip. Are you sure TCP works between the same IPs where ICMP fails? Can you show such traffic with tcpdump -n ? > Here is a tcpdump trace I took from the Minneapolis firewall > (forgive the text wrapping): > > > 16:25:15.459714 < 172.16.16.2 > 172.16.0.252: icmp: echo reply The DNS requests you see are caused from tcpdump trying to resolve the IPs. Always run tcpdump with -n because we don't see the actual addresses. What is the value in /proc/sys/net/ipv4/conf/eth1/send_redirects ? It is may be unrelated but run "ip route" instead of "route -n" to see how look the routes. I'm not sure what is the pereferred source address in each route you add by hand. On each Linux try to check with ip route get from <SADDR> to <DADDR> iif <IN_DEVICE> whether the packet has access to come from the specified device. You will see where the packet should go. I assume the 3 hosts in Minneapolis are on same subnet 172.16.16.0/20 and you expect 16.1 to/not to send ICMP redirects to redirect 16.2 to 16.3? I don't see how such simple routing setup should fail. One of the problems could be the conf/DEV/rp_filter settings but I don't see why it should drop the packets. Run the above "ip route get" command. > - Greg Scott Regards -- Julian Anastasov <ja@xxxxxx>
