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

@chrcoluk said in Where are the inbound rules for routeable IPv6 on LAN interfaces? Solved: I have fully working inbound ICMP which is fine Inbound on .. LAN or WAN ? The default behavior of LAN : TCP, UDP, ICMP, and dozens of other protocols are allowed. WAN : nothing, meaning zero, which wasn't initiated from pfSense itself (or some LAN device), can enter. @chrcoluk said in Where are the inbound rules for routeable IPv6 on LAN interfaces? Solved: it is the WAN rule, logging didnt show it as its using an established state. What WAN rule ? If traffic comes in on WAN and it is established traffic, then initially, it was granted by an existing WAN firewall rule, one you place there yourself. Subsequent traffic, from the same traffic stream, will be granted right away. If you want WAN to reply on ICMPv4 from some device on the Internet, you need to create firewall rule on WAN that grants access from this device (this device, using its source IP, or "any" for everybody) selecting some or all ICMPv4 types of traffic. By default, pfSense will not reply on ICMP request coming into (= inbound into WAN) the WAN.

@gambit100 That file is really not usefull, as it doesn't show the contents. I ran Wireshark, filtering on ICMP6. Here's a list of the packets received, with the RA in the top row: [image: 1757623267241-17d2a377-a2cc-4179-aa71-f0ba19566d2d-image.png] Here is the contents of that frame, showing the relevant info. Several items can be expanded further: [image: 1757623471656-826054d0-050a-4992-890f-b88e7057c4e5-image.png] This is the sort of thing you need to understand network problems. You can use Packet Capture, in pfSense, but I find Wireshark is much better. Even if you capture with Packet Capture, you're still better off examining the capture with Wireshark. Now, if you look at the options, you'll see things like assigned addresses and DNS.

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

@mewsense That is good news, I would never have guessed that would fix it. F

@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

@luckman212 said in Verizon Fios and IPV6, Which Settings Work?: @tman222 Hello from 2025. I just upgraded my FIOS to 2GB from a 1GB circuit where DHCP6 + PD /56 was working fine. Now zero RAs given here too. Searching around here and on Reddit I can't find anyone reporting a working 2G + v6 setup either. So I guess it's back to a tunnel broker for the rest of the year... Hi @luckman212 - thanks for testing and confirming that unfortunately IPv6 still doesn't work yet on the Fios 2Gbit service. I tried getting it work way back in 2023 without success, and was about to try again to see if works now (2 years later), but your report saved me the time. Hopefully it will be implemented before too long. Thanks again.

@rushpunctured said in IPv6 questions (interface address, firewall rules for slaac hosts, GUA/ULA RA): No one seems to have answers on this one? I've been searching for methods on how to change the suffix as well, but no luck. You can do this on the client by specifying the MAC address is used to set the consistent SLAAC address. However, all the privacy addresses will still use random numbers.

@johnpoz said in 25.07: protocol "options" in default block all rule: Not true at all.. True, a load of conditions apply. If the network is mostly cameras doorbells and other (look to the east) 'connected stuff', IPv4 is probably used more. That said, the small stuff normally don't transfer a lot of data. But the classic company network, my case : a load of windows PCs and servers, unifi stuff, NAS (Syno) and 'modern networked printers : I persist : IPv6. All 'recent' PCs phone pad etc OSes use IPv6 be default. For that to happen, true, IPv6 must work flawlessly of course. A 'perfect' IPv6 starst with an ISP that supports it. A global overview of IPv6 usage in the ancient world (Europe, France to be exact) : Baromètre IPv6 Arcep 2025 edit : even amazon and facebook (in Europe) went full '6' recently. [image: 1754912951630-99e8e16d-c50c-4f20-b7f8-2e431fa5ed2d-image.png] edit : I found a command on my PC that tells me .... well, look for yourself : C:\Users\Gauche>netstat -s Statistiques IPv4 Paquets Reçus = 4546224 Erreurs d’en-tête reçues = 0 Erreurs d’adresse reçues = 2 Datagrammes transférés = 0 Protocoles inconnus reçus = 0 Paquets reçus rejetés = 52200 Paquets reçus délivrés = 4517503 Requêtes en sortie = 1816206 Routages rejetés = 0 Paquets en sortie rejetés = 0 Paquet en sortie non routés = 4 Réassemblage requis = 0 Réassemblage réussi = 0 Défaillances de réassemblage = 0 Fragmentations de datagrammes réussies = 0 Fragmentations de datagrammes défaillantes = 0 Fragments Créés = 0 Statistiques IPv6 Paquets Reçus = 8223619 Erreurs d’en-tête reçues = 0 Erreurs d’adresse reçues = 99 Datagrammes transférés = 0 Protocoles inconnus reçus = 0 Paquets reçus rejetés = 6430 Paquets reçus délivrés = 8237200 Requêtes en sortie = 3910188 Routages rejetés = 0 Paquets en sortie rejetés = 1 Paquet en sortie non routés = 0 Réassemblage requis = 8 Réassemblage réussi = 4 Défaillances de réassemblage = 0 Fragmentations de datagrammes réussies = 0 Fragmentations de datagrammes défaillantes = 0 Fragments Créés = 0 Statistiques ICMPv4 Reçus Émis Messages 307 4655 Erreurs 0 0 Destination inaccessible 66 4178 Temps dépassé 117 0 Problèmes de paramètres 0 0 La source s’éteint 0 0 Redirections 0 0 Réponses échos 124 0 Echos 0 477 Dates 0 0 Réponses du dateur 0 0 Masques d’adresses 0 0 Réponses du masque d’adresses 0 0 Sollicitations des routeurs 0 0 Annonces des routeurs 0 0 Statistiques ICMPv6 Reçus Émis Messages 33934 36651 Erreurs 0 0 Destination inaccessible 7 3247 Paquet trop grand 1 0 Temps dépassé 333 0 Problèmes de paramètres 0 0 Echos 0 1071 Réponses échos 86 0 Requêtes MLD 0 0 Rapports MLD 0 0 MLD appliqués 0 0 Sollicitations des routeurs 0 2 Annonces des routeurs 841 0 Sollicitations du voisin 19556 12773 Annonces du voisin 13110 19558 Redirections 0 0 Renumérotation du routeur 0 0 Statistiques TCP pour IPv4 Ouvertures actives = 21632 Ouvertures passives = 4966 Tentatives de connexion non réussies = 835 Connexions réinitialisées = 1549 Connexions en cours = 31 Segments reçus = 4717564 Segments envoyés = 3744453 Segments retransmis = 3531 Statistiques TCP pour IPv6 Ouvertures actives = 15844 Ouvertures passives = 506 Tentatives de connexion non réussies = 708 Connexions réinitialisées = 1772 Connexions en cours = 29 Segments reçus = 8004344 Segments envoyés = 3715614 Segments retransmis = 491 Statistiques UDP pour IPv4 Datagrammes reçus = 2437005 Aucun port = 52126 Erreurs reçues = 0 Datagrammes envoyés = 135305 Statistiques UDP pour IPv6 Datagrammes reçus = 232795 Aucun port = 6356 Erreurs reçues = 0 Datagrammes envoyés = 151262 yeah sorry, it's VO language :(

@Bob.Dig said in Can I force one /64 on my WAN?: Gateway IPv6: fe80::*** That's entirely normal. Routing is often done via the link local address. ISPs may or may not provide a global address on the WAN interface, but you have to enable it if they do. If you can't get a global address from your ISP and want to set up a VPN, etc., you can use the LAN interface address.

@cezarq said in DHCP6 server and gateway not working with ISP modem in bridge mode: If I uncheck this option the WAN gets a /128 IPV6. That's entirely normal. You don't need a global address on your WAN, but it's useful for setting up a VPN, etc.. I'd recommend you uncheck it.