pfSense

This will be required for most consumer internet providers that give dynamic IPv6 addresses.

Verizon FiOS just enabled IPv6, but I will be unable to use this until dynamic NTp is enabled via pfSense.

Any update here? We need dynamic Prefix support for IPv6 Multi WAN.

Does anybody aware of any preparation/planning or any other related work already done?

I think that these changes can basically do the job (take it as a high level plan):
1. Changing the /usr/local/www/firewall_nat_npt_[edit].php to let the user choose the "dynamic" destination which inserts <destination><network>wanip</network><destination> instead of <destination><address>[Manually entered IPv6 address]</address><destination>. (Probably needs a new wanipv6?!)
2. Calling filter_configure_sync() (located in filter.inc) from rc.newwanipv6 which will change the <network>wanip</network> to the last IPv6 provided by the ISP. (AFAIK)
Anyone any thoughs?
(I might just leave this here just for the records.)

That alone wouldn't do anything useful -- it would have to be the entire network, not a single address. If it's the entire network, you'd need proxy NDP which does not exist on pfSense.

What it really needs is:

• Code in the DHCP6 client which stores the current delegated prefix(es) somewhere accessible by pfSense, rather than writing them directly to interfaces and not allowing other parts of the system to see what they are without log scraping/guessing
• A way to select a track interface and set a prefix ID to determine a delegated prefix to use for NPt
• Code to use the track interface+prefix ID to setup NPt rules (which will work because the delegated prefixes are already routed to the firewall, no need for proxy NDP)

There are a number of issues that the first point will solve, but currently the DHCP6 client doesn't support that upstream. It needs the feature added there first. Someone in the community was working on that a while back, but I'm not sure that ever progressed to a point where it was usable.

Looks like the wanip is good enough if $rule['ipprotocol'] == "inet6". But the npt has no 'ipprotocol' attribute which should be worked around somehow.

Probably there can be 2 or 3 "dynamic" scenarios:
1. wanip = changing to/from the actual wan ipv6 address with npt. There should be an option (checkbox?) to do a "hidden" wanip-to-wanip NPt rule in case 2 to keep the wanipv6 as it is for e.g. PMTUDv6 packet too big messages.
2. wan = changing to/from the whole wan ipv6 subnet with npt.
3. wan + some subnet = changing just the subset of the ipv6 subnet. (This might needs further fileds on the NPt edit page.

Jim Pingle wrote:

...

Thank you!

I though much simpler at first by trying to follow my own manual steps when my IPv6 changed.
My WAN IPv6 is always made from the IPv6 "prefix" (it just /64 all the time) and the end of my Link-Local address (from my MAC).

Do you think that it is owe to think about a setting somewhere to have a manual/fixed "suffix" instead of LLA?

Does it really a valid case getting more then a single /64 prefix from the ISP when they provide dynamic IPv6 prefix? Reason of asking is that I always have /64 only from Telekom Hungary.

NPt is "Network Prefix Translation" not "IPv6 outbound NAT", it is effectively "IPv6 1:1 NAT for single addresses or entire subnets". It does not translate many:1 (overload).

There is no potential use for the IPv6 WAN address alone in NPt. It must always be an entire prefix, and as I said, using the WAN prefix is not viable since it would require proxy NDP.

Using any kind of suffix has the same issues I also mentioned. You must be able to specify a track interface and prefix ID or it has no idea what to add that suffix to.

Got that point.

I did two things here with my NPt:
1. Now I have 4 networks (LAN, DMZ, GUEST, VPN), basically /80 each, which I 1-1 to the /64 I got from ISP. This works properly (however I have modify it in every 3-5 days when the /64 changes toghether with my IPv4 address). The pfSense's WAN uses automatically a single IPv6 address out of that /64 (by adding its LLA's end to the /64 prefix).
2. Previously I tried to 1-1 my internal networks as a whole /64 to the WAN /64 facing an issue where the Path Discovery MTU's "packet too big" ICMPv6 message got lost because a double NPt on a loop towards the WAN so I had to setup a "dummy" NPt for the pfSense WAN address to NPt it to the same address which overrides the /64 NPt.

These both works without proxy NDP as the ISP just sends me everything which belongs to my /64.

In case 1 I have to modify the ISP provided /64 to have my internal /80s by concatenate a fixed "suffix" to the /64.

In case 2 it is much easier but I have to do that dummy 1-1 trick for the GW used WAN IPv6. (This dummy is which I mentioned above as "hidden" wanip-to-wanip NPt trick which might be enabled/disabled with a checkbox.)

Csoban Kesmarki, are you sure that you cannot get a "real" prefix from your ISP? The correct way would be that you get e.g. a /56 prefix and additionally a /64 for your router. That's the way e.g. the German Telekom does it. In my opinion, using /80 as a prefix is against the IPv6 specifications. In IPv6, the host past of the IP address is always the lower 64 bit and only the higher 64 bit shall be used for routing. What you are doing breaks e.g. SLAAC (Stateless Address Auto Configuration) and I don't know what else. It might work in some scenarios but I would definitely not recommend it.

I'm waiting for dynamic NPt, too, but for a different reason: I have 2 ISPs with dynamic prefixes. I need NPt so I can configure ULAs internally and map them via NPt to the two dynamic external prefixes. Unfortunately, https://redmine.pfsense.org/issues/6880 needs to be fixed for that, too, because currently, I cannot even get the prefix from my second ISP and use it for some of my VLANs without failover (wouldn't need NPt for that part, only for failover). With IPv4 and NAT it works perfectly: For some VLANs I use ISP1 with fallback to ISP2 and for other VLANs I use ISP2 with fallback to ISP1, using Gateway Groups.

Holger Glemser wrote:

CK, are you sure that you cannot get a "real" prefix from your ISP?...

Thanks Holger, now I did however I had to fully reconfigure my whole network moving the DHCP server from my ubuntu box to the pfSense. So basically it work however not as I planned but at least I got much closer to understand the concept of the dynamic NPT.

I got stacked at a point in my way to trace/investigate/understand/etc. :) the issue: the dhcp6c binary's source itself.
Am I understand it properly that the last source of the dhcp6-20080615.2 (which is included into pfSense 2.4.4p3) is either https://github.com/hrs-allbsd/wide-dhcpv6 or https://github.com/opnsense/dhcp6c or I compleatly wrong and should rely on the http://wide-dhcpv6.sourceforge.net/?

Thanks, CK

Well it took until late 2020 but I finally have two local ISPs providing native /56 IPv6 routes over DHCPv6. It would be great to use static internal prefixes and use NPt to track the dynamic external connections to allow failover between them. (Though I'm also running into https://redmine.pfsense.org/issues/6880 )

https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/54

I'm going to chime in to the usefulness of this. My use case is a little different, but the same principle. I have a 1Gbps Fiber connection(no IPv6), however, I do have IPv6 through work(2 datacenter sites), and a tunnel from my home pfSense to the office pfSense. I also have Starlink(IPv6 provided as /56 PD). I want currently have my work IPv6 through the tunnel, and set as my default IPv6 gateway. I would like to create a gateway group that includes P1 main office IPv6, and P2 as Starlink, and then use NPt to make everything work nice and happy. Just my 2 cents.

I found this issue two days ago while I tried to provide internet access via IPv6 to my OpenVPN clients.

Right now my OpenVPN clients receive a ULA address (beside an IPv4 address out of RFC1918). Together with a redirect-gateway their IPv6 traffic goes through the tunnel. But this way they can't communicate with the internet as they have no GUA adress. Thus I set up NPt for my OpenVPN ULA prefix to of my GUA prefixes. This works as long the provides does not change the prefix. I'd like to live without the NPt, but for now it solves the problem.

OpenVPN currently does not support dynamic prefixes: https://community.openvpn.net/openvpn/ticket/498?__cf_chl_jschl_tk__=pmd_v8Dyom5dk81oCdajl79zwjGb76DEga0UAodRJMPtcA4-1632472768-0-gqNtZGzNAeWjcnBszQl9

Clean way's of doing this might be:
- fix of the OpenVPN issue - out of scope here
- Some kind of prefix delegation to OpenVPN via pfsense but I don't know if this would be possible. Any feature request know for that?
- others?

This fix here would remove the manual labor of updating the NPt, even it might not be a clean solution in the end, at least for my usecase I think.

My setup:
- pfsense 2.5.2
- provider: Deutsche Glasfaser
- connection: fibre with ds-lite (IPv4 with carrier grade NAT + native IPv6 with dynamic /56 prefixes)

Thanks.

Hi,

I made a sort of workaround: I created two php scripts (checknpt and fixnpt) which checks all NPT settings and compare those which are on the WAN interface to the LAN's IPv6 prefix (using fix /56 in code, yet) and displays a message (checknpt) and fixes (fixnpt) to the correct prefix using the administered NPT's suffix (the 72 bits after the 56 bits prefix). Both scripts are located in the /etc/phpshellsessions folder and can be run with the command: 'pfSsh.php playback checknpt' and 'pfSsh.php playback fixnpt'. No GUI or configuration exists, yet.
Can be used by adding a system patch to pfSense by the URL: https://github.com/csobankesmarki/firewall/blob/master/NPTscripts.patch.
Tested and working with pfSense 2.4.x and 2.5.x. Also possible it can be run from cron, too (under testing).

If you are interested I made similar ones for CARP: https://github.com/csobankesmarki/firewall/blob/master/CARPscripts.patch
These ones does similiar check and fixes for CARP VIPs. Checks all IPv6 CARP VIPs whether the prefix (fix /64 here) is the same as the prefix of the interface it belongs to and displays a message (checkcarp) or fixes (fixcarp) to the correct prefix. It keeps the administered /64 suffix of the CARP VIP.

Regards,
CK

Hi,

So the CARP fixing is broken as of yet: the script founds the old CARP address as interface address and fixes the everything (including the correct) back to the old prefix after the ISP changes the IPv6 /56 prefix to a new. I have to fix the script or manually delete the old CARP addresses (aliases) before running 'fixcarp' script.

However when looking around the issue I found the there is a way forward towards the dynamic NPt:
- DHCP6's dhcp6c needs to patched to be able to pass the IA_PD to the dhcp6c_wan_script.sh as an additional environment variable (besides e.g. dns servers and dns domain name, etc.) As far as I understand this is the actual source of WIDE-DHCP6 for FreeBSD: https://github.com/hrs-allbsd/wide-dhcpv6/tree/freebsd, somebody correct me if I'm wrong, here, please!
- The script can pass the IA_PD's value to the rc.newwanipv6 php script.
- The rc.newwanipv6 can load it to the config as a (new) value to store the ISP's IPv6 prefix.
- The firewall_virtual_ip.php and the firewall_virtual_ip_edit.php needs to be changed to add dynamic prefix as NPt possibility.
- "Couple" of additional functions needs to be created to get_wan_profix/set_wan_prefix and some refreshment process in the background to automate. "Easy". :D (I'm interested but don't see how much lot work it is, yet.)

CK

There is a PR pending for this since 11 months apparently, what's the current status?

It is blocked waiting on #6880 which is still undergoing testing and development.

Flole Systems wrote in #note-25:

There is a PR pending for this since 11 months apparently, what's the current status?

What's the PR number, please?

Hi Viktor,

awesome, thank you for this patch. I've trired this on our test system:

From my understanding it is now possible to use a dynamic IPv6 subnet, which is assigned to an existing interface (e.g. Lan).
The problem is that I cannot assign a ULA IPv6 Prefix to the LAN interface in parallel, because the interface IP is already blocked by the "Trac Inferface from WAN".
It is also not working to assign the ULA with a virtual IP to the LAN interface because the ULA-IP is then not reachable for some reason in this case.
Also in case there are two WAN connections with dynamic IPs (which I assume is the most used case here) I cannot track two WAN interfaces on the same LAN interface.

What works is asigning the IPv6 Prefix tracking to a third (and fourth) physical interface, assigning the ULA to the LAN interface and then using NPT with WAN as the destination and the two extra interfaces as the source with the ULA from LAN each.

So the following question: is it somehow possible to include the "track interface part" into the NPT configuration site? Otherwise we would need an additional interface per NPT rule and thats a little bit complicated.

Hi,

If you want to play with this further, I changed a the wide-dhcpv6 client a bit: https://github.com/csobankesmarki/wide-dhcpv6/tree/freebsd it adds a new environment variable 'new_iapd_prefixes' containing the new IAPD prefix including the subnet mask e.g. fdxx:xxxx:xxxx:xxxx::/56.
The binaries can also be downloaded for testing: https://github.com/csobankesmarki/wide-dhcpv6/tree/freebsd-binary.

Use it with caution as it is just a test version.
(There are strange things [at least looks a bit strange for me, but maybe my bad] in how the DHCP6 client stores the IAPD prefix, yet, as it is located in a sublist of the iapd_list sublist, but I just adjust my changes to the exiting one and didn't change the logic.)

If we figure out a (good) way to add it to the pfsense config and use it some way within the NPT setup that might helps to go further with a (much) flexible setup.

CK

L J wrote in #note-30:

It is also not working to assign the ULA with a virtual IP to the LAN interface because the ULA-IP is then not reachable for some reason in this case.

This worked for me; the ULA VIP was reachable with ping.

I've seen the following from ISPs, both of which have some caveats in the current 22.05 NPt implementation:

• Multi-WAN dynamic IPv6 would require creating additional interfaces to configure with the "Track Interface" option.

• Only a single interface can be configured with "Track Interface", hence needing to translate multiple ULA prefixes to a single GUA prefix. To avoid potential conflicts, NPt must be done with a prefix length such as /80. For example:
  1. Set "Track Interface" on a spare LAN interface.
  2. Set "Static IPv6" on LAN1 with x:x:x:10:10::1/64.
  3. Set "Static IPv6" on LAN2 with x:x:x:20:20::1/64.
  4. On LAN1 and LAN2, set Router Advertisements to Managed and enable DHCPv6 Server with DHCP range:
     • LAN1 range" x:x:x:10:10::0 to x:x:x:10:10:ffff:ffff:ffff
     • LAN2 range" x:x:x:20:20::0 to x:x:x:20:20:ffff:ffff:ffff
  5. Create an NPt rules:
     • Interface WAN, Source IPv6 prefix x:x:x:10:10::/80, Destination IPv6 prefix y:y:y:y:10::/80
     • Interface WAN, Source IPv6 prefix x:x:x:20:20::/80, Destination IPv6 prefix y:y:y:y:20::/80
• This configuration results in the following on WAN:
  

  15:53:10.439154 IP6 y:y:y:y:10:6a74:3ff5:eeac > 2606:4700:4700::1111: ICMP6, echo request, seq 58, length 40
  15:53:10.483034 IP6 2606:4700:4700::1111 > y:y:y:y:10:6a74:3ff5:eeac: ICMP6, echo reply, seq 58, length 40
  [...]
  15:55:25.176884 IP6 y:y:y:y:20:6a74:3ff5:eeac > 2606:4700:4700::1111: ICMP6, echo request, seq 64, length 40
  15:55:25.210816 IP6 2606:4700:4700::1111 > y:y:y:y:20:6a74:3ff5:eeac: ICMP6, echo reply, seq 64, length 40

• To work around this, the NPt configuration should allow for the selection of "Track Interface" and a prefix length which overrides that selection.

It would be nice to address the second point at least before 22.05 is released. Request submitted here:
https://redmine.pfsense.org/issues/13070

Edit: Turns out the /80 was just working around a bug. With the fixes in #13070, both Track interface and manual destination works with a /64, no need for the /80.