Adam Richards wrote:
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.
[...] there are some unique requirements this network brings which
make public IP consumption unworkable.
[...] table-management operations -- perhaps 10's of operations per
second on a table of 500,000 entries/mappings. (operations, like
inserts or deletes)
Maybe for resilliency, or for ISP cost reasons, you want to take
advantage of asymetric routing, or "nearest-exit" routing, in a
unified multi-site network? That is, routing where no Traffic
Engineering priciples are used. Clearly stateful tracking inhibits
nearest-exit routing by nature. (Side note: to ensure TCP
connections are maintained in a stateless enviornment you'd
obviously need to enforce 1:1 binat mappings).
I'm seeing mixed messages from the above quotes. It's your project,
but consider this a friendly thought-check :)
You're looking at creating 1:1 mappings from internal IPs to 150-500k
public IPs. You talk about a high rate of mapping changes, so clearly
you're managing entries dynamically, which is just another way of
keeping state.
You mention NAT being an impediment to asymmetric routing, but NAT is
unrelated to routing, so I can infer some possibilities here:
* 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, so that implies synchronizing state between them.
You consider pf's stateful behavior to be ill-suited to this use case,
so you're investigating "stateless" options.
* 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.
Are either of these correct?
If you are trying to do distributed NAT, I would ask if that is
actually a design requirement. 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.
