OK, maybe my explanation last night was a little convoluted. It didn't help that some email server's autowrapping really messed up the diagram of my problem. After thinking about it, I think I can explain my problem a little more clearly. Here goes: ICMP Echo packets come into the LAN to an internal host via one path, not through the Linux router box. The internal host replies with Echo Reply packets and sends them out via its default gateway, which is the Linux router box. So the Linux router box sees these ICMP Echo Reply packets coming from an internal host, but it never saw any prior ICMP Echo packets - these came in via different path. So instead of routing them, the Linux box evidently just throws them away, because the packets never make it over to the VPN router, even though I have a static route that tells it to do so. I demonstrated this behavior with absolutely no firewall rules and with default policy to ACCEPT. The system in question is Red Hat Linux 7.1, which uses the 2.4 kernel. Am I interpreting what I see correctly? Is this a bug or a feature? What can I do about it? thanks - Greg Scott GregScott@xxxxxxxxxxxxxxxxxxx > -----Original Message----- > From: Greg Scott > Sent: Wednesday, October 24, 2001 11:58 PM > To: 'lartc@xxxxxxxxxxxxxxx' > Cc: Patsy Rossow (E-mail) > Subject: Why won't this box route ICMP echo reply packets??????? > > Hi All - > > I looked for mention of this in the archives but wasn't able to find > anything. > This isn't even an advanced routing question, it should be a dirt-simple, > basic, no-brainer, routine routing job. But I'm not getting it! > > I have a Linux iptables based firewall system that is making me crazy. > The gist > of the problem is, even when I turn off all firewall rules and make the > default > policy to ACCEPT, I have two Linux systems that refuse to route ICMP Echo > Reply > packets through anything but the default gateway when those ICMP echo > reply > packets come from the internal LAN. I just tried it again - absolutely no > > firewall rules and the problem persists. And I have two independent sites > that > behave this way. > > Here's the relevant parts of the topology with one situation: > > St. Peter internal LAN Minneapolis > LAN > 172.16.0.0 / 20 172.16.16.0 / > 20 > > OpenVMS System Firewall Firewall NT 4 > server > 172.16.0.252 172.16.0.254 aaa.bbb.228.33 172.16.16.1 > 172.16.16.2 > | | | | | | > ------+-------+--+ +--+--> <---+-----+ > +---+-------+----> > | | | | > Win2K VPN Server (VPNSTPETER) Win2K VPN Server > (VPNMPLS) > 172.16.0.251 xxx.yyy.200.93 aaa.bbb.228.34 > 172.16.16.3 > > > OK, my ASCII art isn't very good. The point is, the two VPN servers > connect in > parallel to the firewalls. They're exposed to the Internet and also > connected > to the internal LANs. > > The test: from the OpenVMS system at 172.16.0.252, ping the NT 4 server > at > 172.16.16.2. We can also run the same ping test from other PCs in St. > Peter, > with the same results. > > Everyone in both internal LANs use the firewall as their default gateway. > Each > firewall has a static route that "bounces back" packets bound for the > other end > of the VPN tunnel to the local VPN server. > > The firewall subsystem in St. Peter is based on Red Hat Linux 6.2 and > ipchains. The Minneapolis firewall is based on Red Hat Linux 7.1 and > iptables. > > The problem is with the Minneapolis firewall. When a host inside the St. > Peter > LAN tries to ping anyone inside the Minneapolis LAN, the echo reply dies > inside > the Minneapolis Linux "router". Remember, this happens even with *all* > firewall rules turned off and default policy to ACCEPT. So there is no > packet > filtering going on. > > Here is the route table in the Minneapolis firewall: > > [root@xxxxxxxxxxx /etc]# /sbin/route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface > 206.144.228.32 0.0.0.0 255.255.255.224 U 0 0 0 > eth0 > 216.114.200.64 206.144.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]# > > So this says to route anything bound for the other end of the tunnel thru > 172.16.16.3. > > I know this routing table is good because I can send TCP port 53 right > through > and it comes back just fine. (Telnet 172.16.16.2 53 from the other end > really > does establish a Telnet session to an internal DNS server.) > > I did a tcpdump from the Minneapolis firewall and I can see the echo > replys > come right through. But the replys never hit the VPN server (I can do > packet > traces with Win2K and I see the pings but no replys.) So the echo reply > dies > inside the Minneapolis Linux box somehow. Why doesn't it forward the > echo-reply??? > > I gotta belive I need to modprobe something or load something. I must be > doing > something dumb, but what? Any ideas would be greatly appreciated. > > Right now, I'm embarrassed, frustrated, and worried that my customer > thinks I'm > a total idiot. > > Oh - yes, I did turn on IP routing: echo "1" > > /proc/sys/net/ipv4/ip_forward > > Is there something else I should be turning on? Why won't this box route > ICMP Echo Reply packets?? > > thanks > > - Greg Scott > cell phone 651-260-1051 > Greg Scott@xxxxxxxxxxxxxxxxxxx >
