Re: inet6 nat-to (group) address selection algorithm question

[Mike Belopuhov]

On 18 May 2017 at 19:51, Adam Thompson  wrote:
>
> So I’ve discovered that, when trying to do NAT66 (for a ULA network), a
line like:
>  "match out on egress inet6 from !(egress:network) to any nat-to
(egress:0)"
> doesn’t work.  (Yes, the network in this case is ridiculously simple.)
>
> I believe it doesn’t work because :0 indicates that aliases on the if
should be ignored, and the first IPv6 address on an if is typically going
to be the LLA… which of course doesn’t work very well for the NAT use case!
>
> However, to my surprise, simply using "nat-to (egress)" does work,
instead.
>
> What I’d like to know is, what magic in pf(4) allows it to auto-select a
"better" (in my case, at least) address when performing the translation?
There’s nothing in the man page that I can see talking about this.  The man
page talks about what happens when I *do* specify :0, but not when I
*don’t*.  (And neither does the FAQ, fyi.)
>
> My concern is that the algorithm (or blind luck, depending) that allows
"nat-to (egress)" to work for me will stop working in some slightly
different scenario or at some random point in the future when something
seemingly-unrelated changes.
>
> Thoughts/hints/explanations?  (Other than "read the source", please -
there's a reason I'm not a kernel programmer!)
>
> Thanks,
> -Adam
>

Hi,

Can you please provide a bit of context, i.e. "ifconfig egress"
output.  It's hard to say why "nat-to (egress:0)" doesn't work
w/o looking at what addresses are available.

The rule of a thumb however, is that pf address pools (things that
follow nat-to, rdr-to and some others) of a dynamic interface type
(that's when you use parenthesis to indicate the dynamic nature
of addresses, i.e. they can come and go) will skip some addresses
not-suitable for purposes of nat-to/rdr-to/etc.  Right now this
means link local addresses.

To understand why this is done, you have to answer the question:
if I have a globally routable IPv6 address(es) alongside default
link local address and I want to round-robin NAT my clients so
that they can access internet, do I want some of them to be natted
to a link local address and some not?

If you think that this needs to be documented, please submit a
pf.conf correction.

Cheers,
Mike

inet6 nat-to (group) address selection algorithm question

[Adam Thompson]

So I’ve discovered that, when trying to do NAT66 (for a ULA network), a line 
like:
 "match out on egress inet6 from !(egress:network) to any nat-to (egress:0)"
doesn’t work.  (Yes, the network in this case is ridiculously simple.)

I believe it doesn’t work because :0 indicates that aliases on the if should be 
ignored, and the first IPv6 address on an if is typically going to be the LLA… 
which of course doesn’t work very well for the NAT use case!

However, to my surprise, simply using "nat-to (egress)" does work, instead.

What I’d like to know is, what magic in pf(4) allows it to auto-select a 
"better" (in my case, at least) address when performing the translation?  
There’s nothing in the man page that I can see talking about this.  The man 
page talks about what happens when I *do* specify :0, but not when I *don’t*.  
(And neither does the FAQ, fyi.)

My concern is that the algorithm (or blind luck, depending) that allows "nat-to 
(egress)" to work for me will stop working in some slightly different scenario 
or at some random point in the future when something seemingly-unrelated 
changes.

Thoughts/hints/explanations?  (Other than "read the source", please - there's a 
reason I'm not a kernel programmer!)

Thanks,
-Adam