@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 ^^

@gambit100 I doubt it is related to your problem, it just caught my eye. The problem is should you ever need to connect to a home.com network, it won't work. That's why they came up with a top level domain name to be used for that sort of thing, in that it will never be assigned to anyone.

@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.

After a longer debug session with ChatGPT (feels weird...) it seams to be an MTU problem specifically with the VSCode server?!? When I change the MTU on a test machine from 1500 to 1480 everything works fine. The proposed solution from ChatGPT was, to change the Interface on pfSense and set the MSS to 1452 (because I'm on PPPoE with a MTU of 1492 on the WAN side). This really seams to work now. But on the other hand it feels so wrong to manually set the MSS stuff.... Is this a dirty workaround or a meaningful solution? Any other suggestions? Thanks

@JKnott because the way Scaleway has configured their IPv6 is that SLAAC will only get you the /128 IP6 address scaleway allocated to Proxmox Whilst you can get /64 IP6 address spaces (What Scaleway call "flexible IP6), but to use these you have to assign this as a static IP6. I'm aware that Scaleway may not following IP6 "best practice" - however, we have to work with what the ISP provides. Matthew