@alnico FWIW you don't need pinging for that. https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/firewall-rules.html https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/rules.html

This problem has been solved after working with my spectrum ISP. The issue was on their side as opposed to an issue with my pfsense router. Just adding some info to this thread in case someone else has a similar issue. Based on comments from @JKnott above I started concentrating on issues between my router and my ISP. What I first noticed was that my router was sending IPv6 renew packets out the WAN interface but no response was ever received. [image: 1761148892546-ipv6-renew-request-resized.png] My understanding (although I'm not an expert here) is that this is a way for IPv6 routers to request the current prefix be renewed instead of waiting for it to expire. Since I never got a response, I assume the LAN client IPv6 connections expired and were therefore dropped by the ISP. I'm not clear why they dropped at different times. After my ISP replaced the cable to my house and did some unknown changes on their end, I started seeing the following messages in the router system log every day or two and everything is now working correctly. "Oct 22 08:20:33 php-fpm 422 /rc.newwanipv6: rc.newwanipv6: Info: starting on igb0."

@louis2 said in Filter an IPV6-address not possible !!?? :(: No idea why I had this trouble ! Note that I still can not enter an address where the text states 'alias or address' Mmmh, if I set the 'Address Familty' to 'IPv6' it does work for me (but not if set to 'IPv4+IPv6')

The original settings in this thread worked fine for me a few years ago when Verizon began rolling this out. Then they seemed to roll everything back in late 2023 and I went the whole of 2024 with no ipv6. I noticed this summer that I was seeing ipv6 addresses again and when looking into it, they appeared to have enabled it all again in Jan. of this year. But by the time I noticed over the summer, I had upgraded to the latest pfsense version and also switch over to KeaDHCP server. I tried using it for an online game and was noticing that I was getting dropouts for 15 minutes about every hour, so I just went back to using ipv4. This weekend I started looking at it more closely and found that every 1 hour 15 minutes, I would lose the ability to use ipv6. These are the entries I would see in my logs. The period from 9:52-10:04, I would have no ipv6 connectivity. IPv4 would renew the leases fine and connectivity there was unaffected. Oct 12 10:04:40 dhcp6c 55217 dhcp6c Received INFO Oct 12 10:04:39 dhcp6c 55217 Sending Renew Oct 12 10:04:36 dhclient 40170 bound to <redacted ip> -- renewal in 3600 seconds. Oct 12 10:04:36 dhclient 18404 Creating resolv.conf Oct 12 10:04:36 dhclient 17251 RENEW Oct 12 10:04:36 dhclient 40170 DHCPACK from <redacted ip> Oct 12 10:04:36 dhclient 40170 DHCPREQUEST on igb0 to <redacted ip> port 67 Oct 12 09:52:27 kea-dhcp6 21138 WARN [kea-dhcp6.alloc-engine.0x1c3afd017400] ALLOC_ENGINE_V6_ALLOC_FAIL_CLASSES duid=[<redacted>], [no hwaddr info], tid=0x6b0e2c: Failed to allocate an IPv6 address for client with classes: ALL, pool_lan_0, UNKNOWN Oct 12 09:52:27 kea-dhcp6 21138 WARN [kea-dhcp6.alloc-engine.0x1c3afd017400] ALLOC_ENGINE_V6_ALLOC_FAIL_NO_POOLS duid=[<redacted>], [no hwaddr info], tid=0x6b0e2c: no pools were available for the lease allocation Oct 12 09:52:27 kea-dhcp6 21138 WARN [kea-dhcp6.alloc-engine.0x1c3afd017400] ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET duid=[<redacted>], [no hwaddr info], tid=0x6b0e2c: failed to allocate an IPv6 lease in the subnet <redacted ip>::/64, subnet-id 1, shared network (none) Oct 12 09:52:27 kea-dhcp6 21138 WARN [kea-dhcp6.alloc-engine.0x1c3afd016d00] ALLOC_ENGINE_V6_ALLOC_FAIL_CLASSES duid=[<redacted>], [no hwaddr info], tid=0x6b0e2c: Failed to allocate an IPv6 address for client with classes: ALL, pool_lan_0, UNKNOWN Oct 12 09:52:27 kea-dhcp6 21138 WARN [kea-dhcp6.alloc-engine.0x1c3afd016d00] ALLOC_ENGINE_V6_ALLOC_FAIL_NO_POOLS duid=[<redacted>], [no hwaddr info], tid=0x6b0e2c: no pools were available for the lease allocation Oct 12 09:52:27 kea-dhcp6 21138 WARN [kea-dhcp6.alloc-engine.0x1c3afd016d00] ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET duid=[<redacted>], [no hwaddr info], tid=0x6b0e2c: failed to allocate an IPv6 lease in the subnet <redacted ip>::/64, subnet-id 1, shared network (none) After fooling around with various settings and searching online, I came to the conclusion that pfsense's implementation of KeaDHCP did not appear to handle renewals of the prefix delegation. I don't know if that is the right conclusion, but the config that was being generated looked to have hard coded subnet ranges and never used Kea's pd-pools config block. Ultimately, all I did to "fix" this was to disable the KeaDHCP service on my LAN interface and change the Router Advertisment-->Router Mode from Managed to Assisted and let my clients sort ipv6 themselves instead of having the router do DHCP. I could set it to Stateless but if someone can tell me what I was doing wrong I'll try and set up DHCP6 again. As I could not find others online having this problem, I assume I did not have the DHCP server configured correctly, but at least for my use case, I don't actually need DHCP6. [image: 1760369517889-beb9b838-c78b-496e-813b-653f044d6232-image.png] Since making that change, my ipv6 dropouts ceased. Also, an unexpected 1.5-2ms reduction in ping time to the target I was using. [image: 1760369744926-42176401-a3c8-4d22-b829-a9b5c0b4516a-image.png] Hopefully this helps others who might end up in a similar boat. This and the now lost thread on dslreports.com were tremendous resources for getting this working originally.

@Gertjan said in IPv6 prefix delegation not working on Netgate 3100 with Free (France ISP): @ggpf said in IPv6 prefix delegation not working on Netgate 3100 with Free (France ISP): the problem with Orange we don't have any info how they implement IPV6, we have to snif Remplacer la LiveBox par un routeur The very first pinned forum thread (you have to read the 116 pages !!) [image: 1759313272826-a195f719-e565-41bf-bc96-737dd80ffb91-image.png] Explained is how to set up the dhcp6c (DHCPv4 and IPv6 client process), as the DHCPclient has to communicate during the IPv4 and IPv6 lease request the orange /fti/xxx and the password, and mandatory DHCP options, etc. As promised : this won't be a "click and play" solution. But the orange livebox replacement with pfSense only works for IPv4 as Orange requires several DHCP6 options that the builtin DHCP6c client in pfSense cannot handle. While pfSenses kea DHCP6 server supports most things or can be costumized in the UI to do so, the same cannot be said of the DHCP6c client. That has to be the worst/least compatible DHCP6 client implementation across all known operating systems at this point. I have tried 4 different ISP’s and only one works out of the box in pfSense, another can be brought to works with special settings. The rest just won’t work with pfSense. Any linux flavor I test works just fine.

@JKnott I'll try it again later today. Unfortunately no, I don't have a managed switch.

@Gertjan said in IPV6 not working since my yesterday update !! :( :(: Btw : about your WAN_PPPOE upstream IP that the monitoring uses to 'ping' : is that your ISP router sitting a couple of feet away from your pfSense, or your connection really that good (0,3 ms is 'not far' away) ? I doubt if that the time matches reality, despite I do have a 1Gbit fiber connection to a high quality provider. Note that my actual google DNS ping time is only 2ms! Every thing shown in the widget related to IPV6 is .... not ok! And in fact that is all ready the case since the new PPOE version was introduced months ago. Note that also he old PPOE version was sometimes showing 'no connection' (in the past year(s)), where luckily in reality there was an connection And that is the big issue now. Up to very very recent, the widget was indication nonsense as related to IPV6, but in reality IPV6 was working. Not now !! There is no IPV6-connection to the network at all !! @Gertjan said in IPV6 not working since my yesterday update !! :( :(: When you upgrade to 25.07.1 there are no 'system patches' anymore that are 'network' (WAN) related. Afaik, these are quality of live patches for other things : I did revert those patches, which did not solve the problem! @Gertjan said in IPV6 not working since my yesterday update !! :( :(: It looks like you have a double set of WAN gateways, two for IPv4 and two for IPv6 : was that like before ? More normal is : That is nonsense. I did see this today for the first time !! A few things to add I did upgrade HA-proxy to the new version. Perhaps that caused the problem I did make a lot of changes in the pas few days, but absolutely not related to the WAN. This makes that I do not want / can revert to an old boot environment I think that boot environments are nothing more or less than ZFS snapshots. The problem is that I do not know how disk and datasets are organized! And as a consequence of that, I do not know which data is affected / is in the snapshot. That should be documented much better! I can not install the system from zero with a boot-usb and a config usb like I could do before. I understand Netgate, but I absolutely do not like it! I am running this snapshot now [image: 1759257077828-d1709c83-73c2-42a8-a58f-71398531e599-image.png]

@ggpf it’s extremely rare to run your own DHCP server on WAN. If you are, pfSense creates hidden rules to allow that. If you are not, you need open no ports on WAN. For the permission error see https://forum.netgate.com/topic/195602/transmit-failed-permission-denied …and ensure IPv6 is enabled.

MSS 1420 fixed the same issue on OPNsense, so I assume this is something common to both maybe a FreeBSD quirk. I remembered to set the MTU to 1508 at the same time,

@chrcoluk said in Where are the inbound rules for routeable IPv6 on LAN interfaces? Solved: looking for another rule that might be whats allowing the traffic I presume your monitoring service pings (right ?!) from 'somewhere on the outside, somewhere from the Internet' so a firewall rule on the WAN interface is needed to allow this traffic coming into the WAN. The good news : normally ^^ you don't have many rules on WAN and typically none on the floating tab. So the matching rule is easy to find. In this case : look for the rules that match ICMP (or any), and a : 'any' as a source. @chrcoluk said in Where are the inbound rules for routeable IPv6 on LAN interfaces? Solved: If that makes sense. Yep. Re saving the firewall rules doesn't terminate already exiting states. Normally, these will time out, and disappear. But this is a case where you have to 'reset' them all, even loosing other connections, like the very noticeable web browser LAN pfSense GUI connection : you have to login again before you can see the changes. And that is just the tip of the iceberg, as more services on any LAN device that had open connections will get interrupted. Example : that gmail app in your phone, that update service in your PC and any other other service that wants to have a connection at all times for whatever reason. These will all get signaled : the connection closed, and they will re open one. You could have used an intermediate step to discover the IP of the Internet based device : Packet capture. [image: 1758694519433-81ca2312-fea4-4b87-b989-68f9d2803897-image.png] You'll see multiple packet popping up very regularly. The most obvious one : the pfSense WAN monitoring tool called dpinger, sending out an ICMP ping request, and getting an ICMP ping reply back. You can recognize these bu the sending IP? and replying destination. You will also see the ICMP ping request coming IN, and pfSense sending an ICMP ping reply - to the IP that is monitoring your WAN from the outside. Maybe you'll find other devices (== IPs) that are pinging pfSense WAN IP ^^

@JKnott I do not expect ATT to change my address, I have had the same IP4 address for over 7 years. Right now I am making sure I understand how PiHole will behave and get in place my DNS blocking to prevent to use of rouge DNS. I suspect to solution will be to block all IPv6 port 53 (except PiHole) and force the use of internal IPv6 and continue to masquerade IP4 rouge DNS requests.

@b_chris Sorry to reply to an old thread, but this thread is what search engines find when dealing with this issue. What just worked for me was this NPt entry: Interface: WAN (not IPsec) Internal IPv6 prefix: Internal invert: not checked Internal address: fdxx:xxxx:xxxx:xxxx::/64 (IPsec virtual address pool ULA prefix) Destination IPv6 prefix: Destination invert: not checked Destination type: OPT1 delegated prefix (any unused interface here)

@GaZaai said in Struggling to get if_pppoe kernel module working: Regarding the IPv6 monitoring, do you think that is possibly a bug? Yes, It is possible. Before reporting I would wait for comments from Netgate representatives.

@Gertjan Thank you for responding. I get your point about the ping targets. It's been difficult for me to find one in Starlink's own network at our point-of-presence. After digging some more, I tried today to see if Gemini could come up with one and it found an ipv4 and ipv6 at the Phoenix PoP that appears to tie in Starlink to the peering network. I've switched to those and will see how it goes. I'll also turn on IPv6 debug in Kea. Thanks for the idea. So, even with that, I'm skeptical it was just an issue with Google's dns not responding, since immediately after rebooting pfSense Google responded to ipv6 gateway status pings again. Previously, I'd tried the gateway save/reload and interface save/reload steps without recovering the status ping. So something must be going on at reboot to recover the gateway status ping functionality that does not go on at the other attempted reload times.

@Alphaphi-by said in Strange IPv6 connection problem: Don't think that Wireshark is lying, I didn't say it was lying - I said it might display the overhead differently.. For example it doesn't show you the overhead of vlan tags normally.. Be it 2 or 6 or 8 or 10.. I thought the overhead with pppoe was normally 8.. But maybe its 10.. And who knows ipv6 might be different? Again its been awhile since did anything with pppoe, let alone via a packet capture. My point was yes there is overhead - so yes as you move from normal network with no overhead to a network with added overhead because of the pppoe.. You would see this. As to your problem - looks like fins were sent, and then that IP sent a RST.. Other than a couple of dup mentions.. Which didn't look enough and not enough info about your network, etc. where captured, etc. .etc.. Looks like connection, opened then closed - and rst sent, which isn't uncommon to see.