Large scale NAT with PF - some weird problem

[Milan Obuch]

On Mon, 29 Jun 2015 12:42:22 +0200
Ian FREISLICH <ian.freislich at capeaugusta.com> wrote:

> Milan Obuch wrote:
> > On Mon, 29 Jun 2015 11:29:32 +0200
> > Daniel Hartmeier <daniel at benzedrine.ch> wrote:
> > 
> > > On Mon, Jun 29, 2015 at 10:52:01AM +0200, Milan Obuch wrote:
> > > 
> > > > Does this answerred your question fully or something more would
> > > > be usefull?
> > > 
> > > How are you doing ARP?
> > >
> > > You're not assigning every address on x.y.26.0/23 as an alias, are
> > > you?
> > > 
> > > So who answers ARP requests of the upstream router?
> > 
> > There is no ARP on routed address block.
> > 
> > In cisco speak, there is just
> > 
> > ip route x.y.24.0 255.255.252.0 x.y.3.19
> > 
> > statement and that's it. Nothing more. Whole address range from
> > x.y.24.0 to x.y.27.254 is routed here as it should be. For something
> > like this ARP would be really evil solution.
> 
> That's OK, as long as the NAT network is routed to your PF box it
> will work.
>

This was just an explanation, I am sure this is OK, as I have some
network experience already for... well, a ong time.

> The situation you mentioned in a previous message where you see
> lots and lots of NAT states for a single public IP address is what
> I suspected was happening.  When you require more NAT states per
> IP than ephemeral ports you will run into issues because you will
> run out of NAT space.
>

No, there were not much states per problematic IP, maybe just tens of
them for one or couple internal IPs. That's weird.

> If the round-robin works with a smaller pool, then I suspect Glebius
> will be interested.
> 

Well, if he chimes in, I would only welcome that. Currently I am
waiting for any signs of troubles with shrinked pool, if there will be
any.

Milan