[4165] in linux-net channel archive
IP Masquerading/Routing problem
daemon@ATHENA.MIT.EDU (Stewart Allen)
Fri Aug 23 16:55:29 1996
Date: Fri, 23 Aug 1996 16:09:26 -0400 (EDT)
From: Stewart Allen <stewart@neuron.com>
To: linux-net@vger.rutgers.edu
You'll have to bear with the explanation on this one, but I think it's
a potentially serious Masquerading/Routing bug. This has to do with my
previous mail about ICMP redirects and dropped connections. It now looks
like it has to do with the masquerading/forwarding code.
We have two T1's to the internet. One in the US and one in the UK. We
also have an internal Frame Relay network connecting all of the sites
worldwide. The masquerading Linux firewall is the newest network router
and it replaced a Netblazer which was doing simple routing/filtering.
This machine has several class C's "behind" it and most of the machines
on the local lan use it as the default router. Typical masquerading rules
go like this:
ipfwadm -F -a a -S ClassC_One -D 0.0.0.0/0 -m
ipfwadm -F -a a -S ClassC_Two -D 0.0.0.0/0 -m
ipfwadm -F -a a -S ClassC_Three -D 0.0.0.0/0 -m
...
So all traffic from these class C's outbound is masqueraded. Typically,
however, traffic from the local net (let's call it One) will be destined
for Two. Since it's a stupid PC and only has one static route, it sends
the packet to the default router (Linux), which sends an ICMP redirect.
All would be happy at this point except that the initial connection drops.
By now, the PC (or Unix machine) has a host route in the kernel and by-
passes the default router for the correct (direct-route) router.
What I found that bothers me (and may be the cause of the dropped connections)
is that /proc/net/ip_masquerade contains an entry from host A on the One
net to host B on the Two net! It's attempting to masquerade the session
since, strictly speaking, it matches the masquerading rule! Unfortunately,
it is _impossible_ to create rules that say to only masquerade traffic
from net One UNLESS it is going to net Two. That would solve this.
My question is... should the masquerading/forwarding code ever really get
the packet in the first place since the static route in the kernel points
back in the opposite direction? How do I solve this. It doesn't look like
the ICMP bug I thought it was, but instead a far more heinous logistical
nightmare. help.
Thoughts, comments, suggestions?
+-
| Stewart Allen ftp.neuron.com
stewart@mail.neuron.com http://www.neuron.com
617.492.2089 FAX 617.492.5837 Neuron Information Systems |
-+
