I would like preface my inline replies with stating what my
original goal was, and still is, in starting this thread:
I want to pursuade the pf community that stateless NAT is a
desired feature and should be part of the core code. :) My
use-case is just one example of how this can be a useful
feature.
Now I'm not one to say if it is easy or hard to implement the
stateless feature given pf's current state (heh), but the
rumblings I've heard coming from the frozen lands of
penguin-haven aren't due to giant antarctic iceburgs breaking off
as a result of global warming:
http://kerneltrap.org/mailarchive/linux-netdev/2007/9/27/323756
(well, I guess "rumblings" may be too strong a word to describe
the inclusion of something as wimpy as stateless NAT... maybe
"gentle ripple" or a light "plunk"...)
c'mon... pf is the swiss army knife of highly performant, and
highly configurable, opensource packet filters! ;)
> You're looking at creating 1:1 mappings from internal IPs to
> 150-500k public IPs.
No. Sorry, I should've been clearer: 1:1 mappings between, say,
a /18 worth of public IP space to something like a /13 worth of
possible private IP space.
It's not 1:1 over the entire mathematical set, obviously, but
rather 1:1 between (public, private) IP pairs for an arbitrarily
defined duration. Maybe a requirement is that I'll never have
more concurrent connections than I have public IPs? Maybe this
will change in the future to where I may need 1:n mapping?
On a slight tangent, one of the nice things about NAT in general
is that it allows internal IPs to change while giving a
consistent public facing interface which doesn't change -- the
same public IP everywhere. We can probably invent many reasons
why internal IPs might change.
> You talk about a high rate of mapping changes, so clearly
> you're managing entries dynamically, which is just another way
> of keeping state.
Keeping state, yes, but not by the NAT layer. Perhaps by an
external system that correlates a lot more information than just
IPs? Many pieces tied together to enable highly resillient
services across a shared substrate?
We all know there are usually many solutions to any one problem,
some more right than others. :)
As you've guessed I'm not using NAT to conserve public IP space
or to achieve basic security by enforcing flow-matching, but
rather to give me some useful control knobs.
Regarding the rate of mapping changes, yes, I need to be able to
sustain a high rate of changes per second across the *whole*
cluster of NAT devices without a significant forwarding
performance hit.
> You mention NAT being an impediment to asymmetric routing, but
> NAT is unrelated to routing,
Ok, ok, I must be clearer! :) I realize NATing is all about
mapping and translation, and routing is all about creating graphs
(topologies) with certain constraints put on them; and with such
graphs and constraints I may be able to ultimately influence
forwarding decisions. Protocols like OSPF, ISIS, and BGP build
the graphs and distill best-path information into a forwarding
base...
and NAT knows absolutely nothing about "arcs and graph edges",
just destinations (or sources).
However it is clear that in stateful NATing with your typical
non-TE'd network, return traffic will always come back through
the same NAT device irrespective of the internal server's network
locality to the Internet. That is, the internal server (or VIP)
may live closer, topologically, to "Internet Feed B", whereas the
NAT device may live closer to "Internet Feed A". Thus depending
on where internal services live, standard stateful NATing may
inhibit return traffic from egressing the *nearest* exit. This
is the opposite of what I want!
> * You want to distribute NAT by implementing it on or near each
> border. In order for anything bidirectional to function, the
> mappings must be consistent
Yup.
> so that implies synchronizing state between them.
Well, it depends on what we mean by "synchronizing state".
I want to have the same mapping information-base exist
everywhere, but NAT state (ie, flow state matching) is NOT
required nor needed. Just a simple unidirectional L3 translation
and then move on our merry way. I say unidirectional to mean
that the NAT device doesn't drop a packet if it results in a
flow-matching miss. This is just the old style "dumb nating"
from yesteryear... as a matter of fact, the same NAT which used
to exist on the linux side of the house (and incidentally is
being re-introduced; again, another part of the thread mentioned
above
<http://kerneltrap.org/mailarchive/linux-netdev/2007/9/27/323772>)
> You consider pf's stateful behavior to be ill-suited to this
> use case, so you're investigating "stateless" options.
Yeah. But it's not that there's anything wrong with pf's
stateful behavior, but that I simply don't want NAT state at all.
Maybe a pf.conf knob that allows me to turn off stateful tracking
for a particular "nat on <iface> ..." rule?
> * You are implementing routing on the same device that runs pf,
> and you believe pf's state-keeping will prevent asymmetric
> routing from taking place.
No.
But that's an interesting idea to use openospfd on the NAT
device... hum.
> Are either of these correct?
Yes, the first.
> If you are trying to do distributed NAT, I would ask if that is
> actually a design requirement.
Yes. "distributed NAT" in that the actual NAT function doesn't
care about direction... for example both of these mapping
operations should be valid -- conxion initiated from a client on
the Internet:
(on NAT device X, inbound traffic destined for 72.14.255.99)
72.14.255.99 ----gets mapped to----> 1.1.1.30
(on NAT device Y, return traffic gets sourced)
1.1.1.30 ----mapped to----> 72.14.255.99
For ingress, destinations are mapped. For egress, sources are
mapped. (In that sense I suppose you can argue directionality
matters... but in a different way than in traditional NATing)
The same table is pushed out everywhere, perhaps by an external
system.
> It may be easier to place NAT near the internal devices
> instead. In a dynamic environment, it may reduce complexity
> and failure modes simply by avoiding the synchronization needed
> for distributed mappings.
I'll need to think about this one...
Sorry for the lengthy missive. I'm err'ing on the side of
verbosity. :)
Thanks for your thoughts and input!
-Adam
