I finally got back to that site with the routing problem with ICMP
echo reply packets. Here is the problem:
Two subnets, 172.16.0.0/20 and 172.16.16.0/20. They are connected
across the Internet by a VPN set up in parallel with two Linux
firewall/router systems. The VPN servers are Windows 2000 machines,
one in each subnet. The firewall/routers are supposed to route
traffic bound for the other side of the VPN back to the VPN servers.
Here is the problem: When I ping from 172.16.0.nnn to any host
inside 172.16.16.nnn, the ICMP echo reply never gets past the
firewall at 172.16.16.1. (Everyone's default gateway in the
172.16.16.nnn subnet is 16.1.) The ICMP echo gets to the correct
host, that host replies, but the echo reply never gets past the 16.1
firewall. The firewall/router at .16.1 is supposed to route anything
for .0.nnn back to the VPN system at .16.3. But it just drops these
echo reply packets into the bitbucket.
The 172.16.16.1 firewall uses iptables and a 2.4 kernel. It has
the problem. The 172.16.0.1 firewall uses ipchains and a 2.2 kernel.
It does not have the problem. After lots of troubleshooting, I **know**
the problem is inside the 172.16.16.1 firewall. Anybody inside .16.nnn
can ping anybody in .0.nnn. The problem is pinging from .0.nnn to hosts
inside .16.nnn.
I have tcpdump -n output showing the echo reply packets coming back
from the host being pinged, but they never get past the Linux system
to the VPN server. I've turned off all firewall filtering rules and
set the default policy to ACCEPT, no change in symptoms.
Julian, you asked me to get some things:
> Are you sure TCP works between the same IPs where ICMP fails?
> Can you show such traffic with tcpdump -n ?
I've been thinking about that for the last 3 months. From any host in
172.16.0.nnn I can telnet 172.16.16.2 53. (16.2 is a Windows NT DNS
server.) I wish I knew a few quick DNS commands and I would feed a few
and see if any kind of response comes back. And I would capture it all
with tcpdump -n. I always assumed that since telnet made a connection,
traffic would go both ways. But now I am not so sure. When I
tried telnet 172.16.16.2 21 (an ftp port), the 16.2 host immediately (and
correctly) rejected the connection because it is not an ftp server.
> 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
> 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
eth0 is the Internet interface.
eth1 is the trusted internal interface.
> It is may be unrelated but run "ip route" instead of "route -n" to
> see how look the routes.
[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
172.16.0.0/20 via 172.16.16.3 dev eth1
172.16.0.0/20 via 172.16.16.151 dev eth1
127.0.0.0/8 dev lo scope link
default via aaa.bbb.228.62 dev eth0
[root@csfampls-fw /]#
(I disguised the public IP addresses.)
Also note the reference to .16.3 and .16.151. This is from my
troubleshooting.
.16.3 is the real internal IP address of the VPN system. .16.151 is the
address of the virtual device the Win2000 VPN software sets up. I tried a
bunch of experiments yesterday with both IP addresses, no change in
symptoms.
> 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?
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.
thanks
- Greg Scott
-----Original Message-----
From: Julian Anastasov [mailto:ja@ssi.bg]
Sent: Monday, November 26, 2001 6:27 PM
To: Greg Scott
Cc: LARTC@mailman.ds9a.nl
Subject: [LARTC] Re: Routing that doesn't route
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/
