On 2014-10-03, Russell Sutherland <russell.sutherl...@utoronto.ca> wrote:
> I am trying to determine whether using an OpenBSD system to perform
> institutional NAT for our wireless users would be a viable option.
>
> At the present time we are evaluating the A10 Thunder CGN appliance.
>
> There are a few issues for which I would like to get some input for those
> using pf for NAT in large environments ( > 10k users )
>
>
> * are there problems with arp cache resources ?
> * can logging be modified to use radius ? We really need some hooks to
> determine who is/was responsible for a given session.
>
> Thanks in advance for any operational experience you may have using pf in a
> similar environment.
Normal PF logging isn't particularly well-suited to CGNAT-type requirements,
in order to record both the internal address and the nat mapping you need
to log both the inbound and outbound packets and piece it together from the
two separate log entries. (pflow doesn't help either as this only records the
untranslated address, rather than both translated+untranslated).
About the best thing I can think of (and this is similar to something done
by commercial systems) is to restrict each individual source address to
using a certain port range ("match in from 100.64.0.1 nat-to $nat1 port
1024:2047" etc.etc.) and keep a record of those mappings to confirm
against dhcp logs or some other information.
Obviously this is going to need some tooling to generate the configs -
either statically, or I suppose if you had some hooks into other systems
(802.1x/radius?) you could possibly add these dynamically via an anchor.
In many cases doing this would avoid the need to keep local records
of each individual connection so better for privacy, disk space, and i/o
throughput.
