[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-misc
Subject:    ipf: possible to split outbound NAT/inbound RDR over two machines
From:       OpenBSD-misc <OpenBSD-misc () dataconnection ! com>
Date:       2001-02-28 20:34:31
[Download RAW message or body]


I want to use an x86 2.8-stable machine or machines with ipf/ipnat to do NAT

for my network (about 500 hosts) and inbound port forwarding ("rdr") for
about 40 
machines.  With both functions on the same box, and with clients pointing to
the 
internal NIC of the NAT machine as their default gateway, there is no
problem.  
But I'd like to separate the inbound redirector service from the outbound 
NAT service over two machines.  Has anyone done this before?  The intention
is to avoid over-enthusiastic NAT users affecting the inbound services, and
to
provide some level of fault-tolerance.  (If one box died, I'd just load the
extra
rules onto the other, fix a little routing and carry on.)

The main stumbling block is what happens when an external user connects to
an 
internal server using the rdr service.  It seems to me that the reply will
go out 
through the NAT box (it being the default route), so the client will get an
answer 
from an IP address it was previously unaware of, and frankly I doubt that it
would 
want to have anything to do with it :)

Setting the default route on the 40 internal servers in question to point to
the internal 
interface of the rdr machine doesn't seem like it would help, as the machine
doesn't
really know any routes.

It would be easy if I could persuade the rdr service to make the connections
appear to
come from its internal interface rather than the true Internet IP address of
the client.  
Then there would not be a routing issue, so the reply would go straight back
to the 
rdr machine, and all would be well.  If you have used rinetd
(www.boutell.com/rinetd)
 you will know what I mean.

Can anyone comment?  It feels kind of nasty to have to hack on rinetd to get
it to 
build under BSD when ipf is so strong, but I can't see another way.

s

[prev in list] [next in list] [prev in thread] [next in thread]