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
