[TriLUG] fIREWALL QUESTION

Ryan Leathers Ryan.Leathers at globalknowledge.com
Fri Jan 3 10:11:46 EST 2003


The big question is: can Linux (firewall/NAT) respond to ARP requests
for addresses not assigned to its own interfaces, then translate (NAT)
the packets that follow ?

I am looking for a way to replace one of my current firewall products
with a multi-interface Linux box.  The goal is to increase my interface
count to 5 and reduce licensing fees.  There is a catch... I need to
perform an unusual brand of NAT.  I'm not sure if this will work on
Linux.  
Requirements:
I have two matching private networks and must static NAT between them.
For example, 10.0.0.1 NATs to 10.0.0.1
I have a public and a private network and must static NAT between them.
For example, 10.0.0.1 NATs to 68.152.31.1
I have multiple private networks that must be able to route via the
firewall.  For example 172.16.0.0 reaches 172.16.1.0 via 10.0.0.254
Various rules are needed on each interface.
This all seems very doable to me except for the first requirement I
listed above.  What's really going on here is that a number of hosts
that used to be in a private network have been moved to another private
network with the same addressing - which avoided renumbering them.  Over
time the new private network has grown and now has quite a large number
of devices.  Several hosts on the new private network need to be
accessed from the old private network.  The Linux box will need to
respond, in the old network, to the ARPs against these several host
addresses so that packets can be NATed and passed to the hosts in the
new network.  Since the address space is the same in both networks this
has to be done by ARP ( I suppose a less desirable approach would be to
use static ARP cache entries where needed ).    
Ryan





    

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3061 bytes
Desc: not available
URL: <http://www.trilug.org/pipermail/trilug/attachments/20030103/bf889834/attachment.bin>


More information about the TriLUG mailing list