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

@pst said in Router advertisement not sending default gateway: That rule shouldn't be needed, it is part of the automatic rule set added by pfSense. I get those by means of pfSense magic: (check in /tmp/rules.debug) here are some snips from that file (I can see ICMP added automatically, but not UDP): 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 We use the mighty pf, we cannot be fooled. block log quick inet proto { tcp, udp } from any port = 0 to any ridentifier 1000000114 label "Block traffic from port 0" block log quick inet proto { tcp, udp } from any to any port = 0 ridentifier 1000000115 label "Block traffic to port 0" block log quick inet6 proto { tcp, udp } from any port = 0 to any ridentifier 1000000116 label "Block traffic from port 0" block log quick inet6 proto { tcp, udp } from any to any port = 0 ridentifier 1000000117 label "Block traffic to port 0" Furthermore I can see that I have autoadded config rules for DHCP4 and DHCP6 here: allow access to DHCP server on LAN pass in quick on $LAN proto udp from any port = 68 to 255.255.255.255 port = 67 ridentifier 1000002541 label "allow access to DHCP server" pass in quick on $LAN proto udp from any port = 68 to 192.168.2.3 port = 67 ridentifier 1000002542 label "allow access to DHCP server" pass out quick on $LAN proto udp from 192.168.2.3 port = 67 to any port = 68 ridentifier 1000002543 label "allow access to DHCP server" allow access to DHCPv6 server on LAN pass quick on $LAN inet6 proto udp from fe80::/10 to fe80::/10 port = 546 ridentifier 1000002551 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 546 ridentifier 1000002552 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 547 ridentifier 1000002553 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from ff02::/16 to fe80::/10 port = 547 ridentifier 1000002554 label "allow access to DHCPv6 server" pass in quick on $LAN inet6 proto udp from fe80::/10 to 2001:2042:334b:c300:a236:9fff:fe7a:603f port = 546 ridentifier 1000002555 label "allow access to DHCPv6 server" pass out quick on $LAN inet6 proto udp from 2001:2042:334b:c300:a236:9fff:fe7a:603f port = 547 to fe80::/10 ridentifier 1000002556 label "allow access to DHCPv6 server" But as IPv6 seems to use port 5355 for something called link-local resolution according to google (https://www.google.com/search?q=ipv6+5355) those presets does not help. So adding the rule adds the missing config (probably could be more restrictive to only match 5355): pass in quick on $LAN inet6 from fe80::/10 to ff02::/16 ridentifier 1752488409 keep state label "USER_RULE" label "id:1752488409"

@patient0 Managed to sort it out, working on windows and android now. Started again and I'm not entirely sure what sorted it but all good. Thanks for your help.

What is the difference between the device/PC that IPV6 works on and the ones that don’t? I would start with looking at the IPV6 settings on the devices/PCs that are having problems. I’m going to guess that your router advertisements are managed. Try stateless DHCP advertisements and see if that solves your problem.

@JKnott said in Should my dhcpv6 clients also get a /64 address?: @Gertjan said in Should my dhcpv6 clients also get a /64 address?: In a pure SLAAC setup you could even disable the DHCPv6 server. (Never tried this, I hope I don't say stupid things here) I have never enabled it. Just enable RDNSS to provide the DNS server address. That's the Enable DNS setting, under DNS configuration, on the Router Advertisement page. That approach seems to work: just stopped dhcpv6 servers on all interfaces, and addressing and net functionality seems unchanged. Well, that is simple. Thanks!