[LARTC] Re: Routing that doesn't route

From: Julian Anastasov <ja@ssi.bg>
To: lartc@vger.kernel.org
Subject: [LARTC] Re: Routing that doesn't route
Date: Mon, 26 Nov 2001 22:24:02 +0000	[thread overview]
Message-ID: <marc-lartc-100681343818736@msgid-missing> (raw)

	Hello,

On Mon, 26 Nov 2001, Greg Scott wrote:

> [root@csfampls-fw /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@csfampls-fw /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@ssi.bg>

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/