I added a static Virtual IPv6 /64 to the WAN Interfcae, but that static IPv6 will not be recognized by the DHCPv6 Service. It still display the error: The DHCPv6 Server can only be enabled on interfaces configured with a static IPv6 address. This system has none.

@Bob-Dig Thank you for the quick response. Not much you can do about it other than running some script via cron for fixing this. So, is this behavior normal? What causes it? Is it known whether the problem will be fixed? That is news to me. So, should the problem occur here as well? At least I haven't observed it so far. I will take a closer look when I get the chance...

Thank you for the explanation! Then I don't need this patch :-) With ifconfig on the console I see all addresses :-) Yes, I still have the problem with the dynamic IPv6 prefix. To "work around" this, I tried to "route" the incoming IPv6 connections with the HA proxy to the appropriate ULA address based on the URL called: https://forum.netgate.com/topic/186422/provider-prefix-delegation-prefix-changes-ha-proxy/3 which unfortunately does not work :-(

In the LAN, I use fixed ULA addresses on the server VMs in addition to the public IPv6 addresses that come from the provider An example. My media server has the following IP configuration: 2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether xx:xx:xx:f7:e3:ee brd ff:ff:ff:ff:ff:ff altname enp6s18 inet 192.168.83.10/24 brd 192.168.83.255 scope global dynamic ens18 valid_lft 41630sec preferred_lft 41630sec inet6 xxxx:xxxx:2180:8e1c:5c20:3aff:fef7:e3ee/64 scope global dynamic mngtmpaddr valid_lft 86188sec preferred_lft 14188sec inet6 fdd0:a044:f4c::a/64 scope global valid_lft forever preferred_lft forever inet6 fe80::5c20:3aff:fef7:e3ee/64 scope link valid_lft forever preferred_lft forever A corresponding AAAA record is set in the subdomain at the domain host. I now create the firewall rule: [image: 1709220133589-bd68baf2-35c9-4f66-a956-44d5eab8fe7f-grafik-resized.png] Everything works. It is unfortunate that when the provider changes the PD, I have to adjust the firewall rules every time :-( I wanted to get the HA proxy to listen on the WAN interface (as I did with IPv4) and accept the HTTPS requests. If the requested URL matches the host, it is forwarded to its ULA address; [image: 1709220377930-6d60347e-9dd0-4fb0-a953-ad52ef32d61a-grafik-resized.png] [image: 1709220426528-6a9dd3c6-bd40-42f0-98bc-f22222930ca2-grafik-resized.png] [image: 1709220467996-1eab4595-f341-4e7d-b3d9-0ff9738e2549-grafik-resized.png] [image: 1709220502776-ea61d6b8-f80b-4369-bab9-e0bb20e64978-grafik-resized.png] [image: 1709220544526-fe2df45f-7740-4eaa-b3da-e09cdc70d080-grafik-resized.png] but I do not have access to it. Does it even work in the HA proxy to accept an incoming connection on the public IPv6 address and forward it to a host based on its ULA address? In the diagnostics, I can ping the target host in the LAN under its public IPv6, its ULA address and with its host name.

@haraldinho have no idea why they would setup a rule for fe80/10, also pfsense by default setups up hidden rules for all things needed for IPv6 to work.. # IPv6 ICMP is not auxiliary, it is required for operation # See man icmp6(4) # 1 unreach Destination unreachable # 2 toobig Packet too big # 128 echoreq Echo service request # 129 echorep Echo service reply # 133 routersol Router solicitation # 134 routeradv Router advertisement # 135 neighbrsol Neighbor solicitation # 136 neighbradv Neighbor advertisement pass quick inet6 proto ipv6-icmp from any to any icmp6-type {1,2,135,136} ridentifier 1000000107 keep state # Allow only bare essential icmpv6 packets (NS, NA, and RA, echoreq, echorep) pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {129,133,134,135,136} ridentifier 1000000108 keep state pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {129,133,134,135,136} ridentifier 1000000109 keep state pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {128,133,134,135,136} ridentifier 1000000110 keep state pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type {128,133,134,135,136} ridentifier 1000000111 keep state pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {128,133,134,135,136} ridentifier 1000000112 keep state pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type {128,133,134,135,136} ridentifier 1000000113 keep state But there nothing saying that some rando IPv6 address out on the public net needs to be able to ping you.. Allowing that would be up to you - say if you want to get a 20 on your test ;) They also want your IP to resolve for PTR if you want a 20, most of the time that would be out of the users control.. edit: I take it this is the 20/20 score your shooting for ;) [image: 1708981936816-test.jpg] Since I am using HE for my IPv6, they allow for setting up PTRs - which allows for that hostname part of the test to work.. And if you allow ping on your pfsense to whatever IPv6 your testing from behind pfsense, and it answers ping as well.. Some host firewalls might also block that you should be rocking your 20/20

After digging deeper and lots of analysis, I came to the embarrassing conclusion that my IPv6 setup was incorrect. It only appeared working because I had "Limit IP address tracking" enabled on my Mac. This makes the Mac route traffic through Apple's obfuscation service through Cloudflare In reality IPv6 internet connectivity did not work at all on the LAN. Problem solved anyway

@JKnott The second file pcap dhcpv6_2 is similar to your example. Please check that.

@hsv I don't have that problem. However I'm on 2.7.0.

@Bob-Dig said in Network Prefix Translation (NPt) prefix translation bug: That is true for everything, not only ping. It's good to know that the behavior isn't only for ICMP6 packets. @Bob-Dig said in Network Prefix Translation (NPt) prefix translation bug: NPt doesn't solve this problem (unsolicited inbound traffic) on pfSense. Good to know. Perhaps I'll open a bug report on redmine for this issue, see what the devs have to say.

I seem to have managed to get this to work by going into "Advanced DHCP6 Client Configuration" and setting the "Prefix Interface" to an enabled but otherwise inoperative "LAN2"

@Bob-Dig sorry for my late reaction. Work was busy. The gateway rule does the trick with me!

@marcosm indeed... without the reboot, my interface still doesnt get an IPv6 address on " track"

Per @Bob-Dig suggestion, I connected a Cisco SG200 switch to the IGC2 port as a trunk VLAN and connected the MacBook Air to a VLAN 40 port on the switch. Same results, IPv4 works correctly, as soon as IPv6 is turned on the IGC2 port bounces. This is what I expected, as macOS Sonoma has full support for VLAN's built-in, which is how the MacBook Air was previously configured sans intermediary switch. Any thoughts on how to get this to work would be appreciated, since it is working for other VLANs on the other ports of the Netgate 6100. Thanks, Brent

@shamrock for starters why would you ever put a /56 on an interface? /64 is the only thing that should be on an interface. Maybe a /128 in some circumstances.. But an interface on a device/router/firewall etc.. should and would only be /64 You can use other larger prefixes in say a firewall rule or route.. Or a delegation to some downstream device that will break up that larger prefix.. 2nd - that is the correct /56.. it would run from.. fd00:fd00:246:200:: - fd00:fd00:246:2ff:fff:ffff:ffff:ffff A prefix is going to start on specific net break, if you put an address that is in the middle of the network, that doesn't change the network address. Its easier to read with IPv4 as example.. Lets say you are using a 192.168.0.0/22 This range is 192.168.0.0- 192.168.3.255 If You put an address of say 192.168.2.1/22 on your interface.. The network that is on is still 192.168.0.0- 192.168.3.255 If you used 192.168.1.1, or 192.168.1.254 or 192.168.3.254 or 192.168.2.27, etc.. the network is still that 192.168.0/22 that runs from 192.168.0.0 to 192.168.3.255, does not matter where in that space the address you put on the interface lands. A prefix or netblock/network is always going to start and end at specific addresses.. Just because you put an IP that is in that range on the interface, doesn't change the the network boundaries If you wanted to use 246:246, that would be like the 71st subnet out of your /56 fd00:fd00:246:246::/64 fd00:fd00:246:246:0000:0000:0000:0000-fd00:fd00:246:246:ffff:ffff:ffff:ffff

@Bob-Dig You are the best! Thanks for the info, i really appreciate it

@mathais I haven't configured a bridge in pfSense, so I can't speak from experience, however physical bridges don't have any addresses. They're supposed to be transparent. Do the actual interfaces have a link local address.

@DrPhil said in Configure IPv6 on multiple LAN interfaces: Hi, I am trying to configure IPv6 on multiple LAN interfaces (LAN and DMZ). Did you ever get this sorted? The thread seemed to peter out at the end... What works for me on Verizon FIOS Interfaces / Wan IPv4 Configuration Type dhcp IPv6 Configuration Type dhcp6 DHCPv6 Prefix Delegation size 56 Send IPv6 prefix hint checked Do not wait for a RA checked it ends up looking a bit weird -- only a link local (FE80::something) configured on the Wan interface, but it works (you can probably find the RFC about using only ipv6 link local addresses on routers - I'm not going to bother searching) Then on the LAN interfaces IPv6 Configuration Type Track interface and under "Track IPv6 Interface" IPv6 Interface WAN IPv6 Prefix ID <pick a unique number -- I like using the vlan #> Then under "Services / DHCPv6 Server" DHCPv6 Server gets checked Range pick something Prefix Delegation Size is 64 Default lease time I used the 7200 default Max lease time I went with 28800. I started with one day but the dhcpv6 address occasionally showed up as deprecated and 'valid_lft forever preferred_lft 0sec' Hopefully that's a good enuf description :)

@DrPhil said in IPv6 static leases when ISP changes the prefix: Under System > Advanced > Networking, there's a setting Do not allow PD/Address release. Is that selected? If not, your prefix will change for something as simple as disconnecting & reconnecting the WAN cable. Thank you! That's exactly what I was hoping to hear. I've now checked that box, and will monitor. If the ISP still changes the prefix on me, I'll just call them. I'm on Verizon FIOS and they do change the prefix all too often. Even without a reboot or anything that would cause the interface to bounce the delegated prefix can change :( The good news is that if you leave the prefix off of the IPv6 address in the DHCPv6 config the server will supply the prefix for you. I haven't figured out how to predict the DUID so I just let the system assign an ipv6 address from the free pool & then go to the ' Status / DHCPv6 Leases' page, find the entry that I want to convert to a static address, and under Actions click the 'Add static mapping' button. That brings up the ' Services / DHCPv6 Server & RA / LAN / DHCPv6 Server / Edit Static Mapping' page and then I put just the "::host addr" in the IPv6 address field. The system will fill in the delegated prefix part of the address when it gives out the DHCPv6 address later on. .