NPTv6 Config Backwards?

[Andne]

I'm not sure if I'm overthinking this or not, but I have had a difficult time getting NPTv6 working, and it partially feels like some of my confusion was due to either items being backwards or the docs just not being clear enough about what I should do. Some of it was definitely related to a bug I've filed in GitHub, but even after I figured that out I seems like what the form is asking for is inverted from the model I have in my head.

Currently I have this working by setting the Interface to WAN, the Internal IPv6 Prefix to my ULA prefix, leaving the External IPv6 Prefix empty (it changes dynamically) and the Track Interface to my internal interface (which is configured to track the WAN IPv6 address and has a virtual IP for the ULA prefix on it).

I know that this is configured using pf's binat rule, and I can find the rule in the firewall diagnostics:

Code: [Select]

@0 binat on wan_stf inet6 from fdXX:XXXX:XXXX:XX00::/56 to any -> (ixv3:0)/56- wan_stf should be the 6rd interface created for WAN
- ixv3 is the internal interface I selected to track (SYSADMIN in the attached screenshot)

Where I get confused is this looks like it's expecting packets from my ULA prefix on the WAN interface. I've been struggling a bit to find clear documentation on how pf's binat works so I can better understand what the rule means. Maybe because it's bidirectional the rule is just going to look weird. I have verified that a device on that internal interface can now access the internet as desired, which implies that the rule is correct, if just weird to think about. I did find the following information from a pf man page: https://man.freebsd.org/cgi/man.cgi?pf.conf(5)

# BINAT
# Translate outgoing packets' source address (any protocol).
# Translate incoming packets' destination address to an internal   machine
# (bidirectional).
binat on   $ext_if   from 10.1.2.150   to any -> $ext_if

# Translate packets arriving on $peer_if   addressed to 172.22.16.0/20
# to the   corresponding address in 172.21.16.0/20   (bidirectional).
binat on   $peer_if from 172.21.16.0/20 to   any -> 172.22.16.0/20

And after I pasted that I finally realized I think I understand how this configuration works and how to leverage it:
My ISP gives me a /56 via 6rd. I can slice this up into various /64's for the different VLAN's in my network. (This is done by setting Prefix ID on the Tracking Interfaces.)
My chosen/generated ULA prefix is a /48, meaning it doesn't map especially well to my assigned /56. Setting another 8 bits statically for my entire network seemed a bit limiting to making the network segments semi-easy to correlate (I often duplicate numbers between subnets and VLANs for easier mapping).
However, since the firewall rule is referencing the tracked IP address on the internal interface, I can leverage that to assign a given /64 ULA subnet to a different /64 GUA subnet. I convert my tracked /56 to internal /64's using the Prefix ID in the interface config (or whatever size prefix I want to do). I was getting a bit hung up at one point when assigning ranges to how I map the 16 bits of "prefix ID" I can assign to the ULA ranges vs the only 8 bits in the tracked GUA ranges. I still need to watch out for conflicts, but this is where the Tracking Interface + Virtual IP configuration comes in handy. I use the Prefix ID of the Tracking Interface (internal interface) to determine which of my 256 /64 GUA prefixes is mapped to a specific ULA subnet in my network. This allows my ULA prefixes to better map to my internal network, usually by including some of the VLAN information in those 16 bits. Granted, some of that information gets thrown away when converted, but this is mostly for devices to access internet and not serving stuff to the external internet.

I still think the rule is written out in a weird fashion. I'm should probably figure out how to contribute to the source to see if I can improve the help on that page some, I think it could be more obvious which field is external interface vs. internal interface. Granted, that assumes that some other use case shouldn't swap them the other way anyways.

P.S. I understand the limitations around ULA, some of the devices I'm trying to set that up for are not dual-stack, so it's not an issue for them. I also don't think ULA vs. any other scheme to solve my dynamic prefix issue impacts what I'm seeing. I wish my ISP would get with the times and move to full dual-stack with the recommended static IPv6 prefixes, but that's a whole different topic.