Adam,
Do the machines on the inside of the firewall have private addresses?
Perhaps a transparent firewall will work if the internal machines also have
public addresses.
Can you could make use of the filter directive "route-to" to route packets
to a different network?
nat on $ExtIf from !($ExtIf) to any -> ($ExtIf:0)
rdr on $ExtIf from any to ($ExtIf) port www -> 10.10.10.100 port www
pass in on $IntIf route-to { ($ExtIf_1 $ExtGw_1) } proto tcp from $IntNet to
any port www
It also sounds like you could make use of anchors in pf. With an anchor you
can add remove nat, rdr or filter rules on the fly.
Just guessing here.
OpenBSD Pf Firewall "how to" ( pf.conf )
http://calomel.org/pf_config.html
--
Calomel @ http://calomel.org
Open Source Research and Reference
On Wed, Apr 02, 2008 at 04:27:17PM -0700, Adam Richards wrote:
>Hi. Let me just say pf is absolutely fantastic! It is actually
>a joy to work with.
>
>Ok, the problem:
>
>I need to be able to create *stateless* nat rules for at least
>150,000 entries, potentially to grow to 1/2million entries. The
>reason has to do with being able to work in an asymetric routing
>environment -- stateless nat must be used because traffic might
>not egress at the same location it ingressed. In other words I
>want to do a unidirectional translation and then fahgettaboutit.
>
>For the moment let's ignore the cpu/mem/pcie/bus or other
>hardware requirements to maintain a large translation table and
>perform hdr rewrites fast enough. We can also ignore any
>performance requirements of nats/sec. And lastly we can ignore
>how translation table insertion or removal operations may affect
>pf's realtime stability/reliability. I will likely touch on
>these subtopics (perhaps in a new thread?) once I find out if
>stateless nat is even possible.
>
>Is there a "no state" directive for nat rules, similar to the
>no-state directive for filter rules? Or another clever way to
>use nat/rdr/filter statements? Even though I wasn't able to find
>any affirmative evidence in pf.conf(5) manpage I thought I'd ask
>anyway.
>
>While I'd prefer a "yes pf can do this" answer, I will accept a
>"no...but here are the code sections you'll want to look at to
>start your patch work" answer. ;)
>
>Thanks.
>
>--
>Adam Richards
>e:[EMAIL PROTECTED] | o:[EMAIL PROTECTED] | k:0x0BA2643B |
