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


Reply via email to