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@csfampls-fw /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@csfampls-fw /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@InfraSupportEtc.com
Greg Scott
2001-Oct-26 04:56 UTC
RE: Why won''t this box route ICMP echo reply packets???????
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@InfraSupportEtc.com> -----Original Message----- > From: Greg Scott > Sent: Wednesday, October 24, 2001 11:58 PM > To: ''lartc@mailman.ds9a.nl'' > 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@csfampls-fw /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@csfampls-fw /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@InfraSupportEtc.com >