@ansel That was the weird part there was nothing in the logs and the interface showed up. I say "was" as it hasn't happened in the last week. Sigh. Heisenbug? Sun Spots?

@keyser I seem to remember that the draft for IPv6 was out before IPv4 NAT became a thing. Even the original author of NAT (Paul Francis?) didn't think much would come of it. Then came PIX hardware and the world changed.

@darkonc To my knowledge, this needs to be configured manually in pfSense. The LAN interfaces get their subnets by following the WAN interface, however, the WAN cannot follow itself. In other words: if the prefix change, one needs to manually configure it again - or have some sort of scripting to do this. All tho I get that "providers should keep prefix fixed, preferably, for the time the contract is active", in reality, most of them do not. They change the prefix if you change/upgrade your router and depending on the configuration you change on the router it can trigger a new prefix (it is based on the DUID in the case of Telus). In my mom's house (Brazil), the IPv6 prefix changes almost every 3 weeks with default configuration (why? to annoy users maybe...). In short, I agree with everything you said, I would like to have the IPv6 set to the WAN, but I can live without it. Thanks, JrBenito.

@RobbieTT Part of the reason for the U.S. being so slow with IPv6 goes back to when IPv4 was created and most of the addresses went to the U.S.. As a result it didn't have the pressure of the IPv4 address shortage as the rest of the world did. Of course, when it was originally set up, it wasn't intended to be world wide. It was just to support defense researchers and grew from there. Also, back then, there wasn't a lot of data crossing the pond, as there wasn't much capacity until fibre came along.

@SteveITS said in IPv6 not passing despite rules: Do you have two WANs bingo! Just disabled WAN2 for testing, IPv6 works immediately.

Works fine for me now, good job.

@sorg said in How to 4rd with pfsense ?: This guide is not relevant for our situation. We are not connected through VDSL, but with Fiber (FTTH using 10G-EPON.) Ok now I now it a bit better. We already have the necessary hardware (the ONT) to connect the incoming fiber to a modem and we know the steps to achieve the results. This was not clear to me from the opening post. We need to spoof the MAC address of the Freebox on the ethernet interface that will be connected to the ONT: It's ok and working. We need access to VLAN 836 on this interface and get an ipv6 link with dhcpv6 provisionning: It's ok and working. Ok. We need to open a tunnel of type ipip6 over this link in order to get the ipv4 Wan connection. Ideally this tunnel is negotiated with 4rd or map-e protocol, however, we can also force the settings manually. Oh ok I see it is in real another problem, so I was not really able to get it right. I have not been available to achieve this last step on pfsense/opnsense, while i have all this set up an working in vyos or openwrt. Oh ok if you got it working in VyOS and OpenWRT it should be a way to find out how it should work using pfSense.

@JKnott I will check tomorrow, after the reboot I did the issue has gone. Maybe it was caused by the temporary nic I am using (an usb 2.5 gb) for the wan Thanks again ;)

It now seems likely that this wasn't related to the 23.05, but to a change in the Signal app around the same time which causes it to start preferring IPv6 over IPv4. There's a thread about it at https://github.com/signalapp/Signal-Desktop/issues/6393 It's still mysterious what the actual problem is.

@SteveITS I just tested two scenarios where it works, none included changing IPv6 config type to none on the interface. One was to just disable the second gateway and leave on automatic; Second was to manually choose the WAN_DHCP6 interface as v6 gateway and reboot; Both working. It's only Automatic with both active that seems to be breaking things. So let me go back to the first time I booted 23.05 and no IPv6: I had a gateway group for IPv6 with WAN_DHCP6 (T1) and WAN2_DHCP6 (T2). This configuration that was working before (giving preference and having the T1 GW active) now seems to malfunction.

@dblclick Another reason to support this would be DDNS. We are unable to provide a IPv6 address to services .

@matty10209 Not sure why you think that is some sort of lease? Nor what rabbit hole you went down that you think you should delete an interfaces link-local address? [image: 1684077043752-ndp.jpg] Those are the link-local address of pfsense own interfaces.. You can disable IPv6 in pfsense, this doesn't remove the under laying IPv6 support in the OS, ie link-local addresses on the interfaces..

@starcodesystems If you want to have local only addresses, you want ULA. These work pretty much the same way as RFC 1918 addresses on IPv4. Link local happens automagically on all IPv6 capable devices, but you don't want to use them in the same way as global or ULA addresses. They're more for ICMP messages, router advertisements, etc..

@gamienator-0 Regarding Windows Bug I'm livin with the imagination that pfsense should not not let the request through on that interface for the wrong subnet. ///Peter!

@jknott said in 23.01 DUID question - I can't spoof my way to a new prefix: @mfld This is the opposite problem of what some others have. That's the story of my life, brother I specialize in bizarre tickets. The reason I want a new prefix is that this one directly resolves to the actual MAC address of the CPE and the OUI on this one is very specific. I'd rather obfuscate. Just out of habit. I did uncheck that option (meaning yes absolutely release the PD on restart) but they still send the same prefix. It may need to be offline for a bit. Maybe they tie it to the pppoe credential for a period of time and a reboot is too short. I called them to ask if their policy changed and the prefixes are static now but they assured me that it's still a /64 only and it's definitely dynamic.

@johnpoz said in What If ISP can only provide a /64: The point is that you can subnet a /64. Um not according the the specification - breaking up a /64 is going to be problematic for sure.. If everyone stuck to the specifications and best practice then there would be zero need to have such conversations. To be clear, I'm not an advocate of splitting up a /64 and certainly not an advocate of anyone receiving just a /64 or worse, not being served by IPv6 at all. None of these limitations are applicable to my situation either. This is just a conversation for those stuck in the gap between what should be happening and what is actually happening when stupid strikes. ️