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

@betapc I haven't set up the tunnel yet, because I ran out of time yesterday. but I'm going to try these 3: ROUTE64 BGPTunnel.com Hurricane Electric I'll let you know about the results. I had the same problem years ago (with macOS mostly) where clients were preferring the IPv6 route, so I wrote a Python module for Unbound to strip away AAAA records from DNS responses. This forces IPv4-only but still allows V6 traffic when I specifically target an IPv6 host by address. The script also has an allowlist (config file) of domains to pass AAAA records thru for, since I have some IPv6-only services I deal with. So far so good on all that. But it's only been 2 days.

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

@drodgers Hey. I'm going through this exact thing now with Vodafone and pfSense and struggling. I've replicated your settings but it seems very intermittent. My clients get ipv6 addresses and can ping out fine however browsing this forums dies because it responds with and ipv6 address. For some reason as soon as I enable ipv6 netflix and paramount also stop streaming They browse fine but as soon as you try to play a video it's a no go. Any ideas or pointers please or could you post your most recent working config please?

Hi @SteveITS. That was an excellent tip, I had missed the "self" target completely. This allowed me to get rid of all of my firewall aliases I needed earlier. Thanks!

@JonathanLee said in Seeking Insight on IPV6 Suricata Alerts – "Excessive Retransmissions" and "Wrong Direction First Data": SURICATA Applayer Wrong direction first Data Here is the link in the Suricata docs for this stream rule alert: https://docs.suricata.io/en/latest/rules/app-layer.html#applayer-wrong-direction-first-data. The short version of the story is that even today, after several attempted fixes within Suricata, the coders of client/server software apps seem to still be able via crappy coding to craft network flows that trip up the Suricata parser. This is basically a harmless error. As @SteveITS said, the best thing is to disable all the Suricata stream event rules. They are informational anyway and don't necessarily indicate malicious traffic.

@bearhntr I would presume not, at least not yet. ️

@Gertjan Yes I'm running in debug mode Jul 11 16:29:49 dhcp6c 82560 extracted an existing DUID from /var/db/dhcp6c_duid: 00:01:00:01:2b:8f:81:6a:20:7c:14:a1:bf:06 Jul 11 16:29:49 dhcp6c 82560 failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory Jul 11 16:29:49 dhcp6c 82560 failed initialize control message authentication Jul 11 16:29:49 dhcp6c 82560 skip opening control port Jul 11 16:29:49 dhcp6c 82560 <3>[interface] (9) Jul 11 16:29:49 dhcp6c 82560 <5>[igb0] (4) Jul 11 16:29:49 dhcp6c 82560 <3>begin of closure [{] (1) Jul 11 16:29:49 dhcp6c 82560 <3>[script] (6) Jul 11 16:29:49 dhcp6c 82560 <3>["/var/etc/dhcp6c_wan_dhcp6withoutra_script.sh"] (46) Jul 11 16:29:49 dhcp6c 82560 <3>end of sentence [;] (1) Jul 11 16:29:49 dhcp6c 82560 <3>end of closure [}] (1) Jul 11 16:29:49 dhcp6c 82560 <3>end of sentence [;] (1) Jul 11 16:29:49 dhcp6c 82560 <3>[id-assoc] (8) Jul 11 16:29:49 dhcp6c 82560 <13>[na] (2) Jul 11 16:29:49 dhcp6c 82560 <13>[1] (1) Jul 11 16:29:49 dhcp6c 82560 <13>begin of closure [{] (1) Jul 11 16:29:49 dhcp6c 82560 <3>end of closure [}] (1) Jul 11 16:29:49 dhcp6c 82560 <3>end of sentence [;] (1) Jul 11 16:29:49 dhcp6c 82560 called Jul 11 16:29:49 dhcp6c 82560 some IA configuration defined but not used Jul 11 16:29:49 dhcp6c 82560 called Jul 11 16:29:49 dhcp6c 82642 reset a timer on igb0, state=INIT, timeo=0, retrans=891 Jul 11 16:29:49 dhcp6c 82642 Sending Solicit Jul 11 16:29:49 dhcp6c 82642 a new XID (93ca57) is generated Jul 11 16:29:49 dhcp6c 82642 set client ID (len 14) Jul 11 16:29:49 dhcp6c 82642 set elapsed time (len 2) Jul 11 16:29:49 dhcp6c 82642 send solicit to ff02::1:2%igb0 Jul 11 16:29:49 dhcp6c 82642 reset a timer on igb0, state=SOLICIT, timeo=0, retrans=1091 Jul 11 16:29:49 dhcp6c 82642 receive advertise from fe80::88ce:87ff:fec6:156a%igb0 on igb0 Jul 11 16:29:49 dhcp6c 82642 get DHCP option client ID, len 14 Jul 11 16:29:49 dhcp6c 82642 DUID: 00:01:00:01:2b:8f:81:6a:20:7c:14:a1:bf:06 Jul 11 16:29:49 dhcp6c 82642 get DHCP option server ID, len 14 Jul 11 16:29:49 dhcp6c 82642 DUID: 00:01:00:01:21:56:39:cc:fa:32:37:34:e3:9f Jul 11 16:29:49 dhcp6c 82642 get DHCP option identity association, len 40 Jul 11 16:29:49 dhcp6c 82642 IA_NA: ID=1, T1=1000, T2=2000 Jul 11 16:29:49 dhcp6c 82642 get DHCP option IA address, len 24 Jul 11 16:29:49 dhcp6c 82642 IA_NA address: 2a06:4000:8888:ffff::2 pltime=3000 vltime=4000 Jul 11 16:29:49 dhcp6c 82642 get DHCP option DNS, len 32 Jul 11 16:29:49 dhcp6c 82642 get DHCP option IA_PD, len 41 Jul 11 16:29:49 dhcp6c 82642 IA_PD: ID=1, T1=1000, T2=2000 Jul 11 16:29:49 dhcp6c 82642 get DHCP option IA_PD prefix, len 25 Jul 11 16:29:49 dhcp6c 82642 IA_PD prefix: 2a06:4000:8888::/48 pltime=3000 vltime=1546855634413031328 Jul 11 16:29:49 dhcp6c 82642 server ID: 00:01:00:01:21:56:39:cc:fa:32:37:34:e3:9f, pref=-1 Jul 11 16:29:49 dhcp6c 82642 reset timer for igb0 to 0.958394 Jul 11 16:29:49 dhcp6c 82642 receive advertise from fe80::88ce:87ff:fec6:156a%igb0 on igb0 Jul 11 16:29:49 dhcp6c 82642 get DHCP option client ID, len 14 Jul 11 16:29:49 dhcp6c 82642 DUID: 00:01:00:01:2b:8f:81:6a:20:7c:14:a1:bf:06 Jul 11 16:29:49 dhcp6c 82642 get DHCP option server ID, len 14 Jul 11 16:29:49 dhcp6c 82642 DUID: 00:01:00:01:21:5a:37:e1:96:96:78:4c:ae:6d Jul 11 16:29:49 dhcp6c 82642 get DHCP option identity association, len 40 Jul 11 16:29:49 dhcp6c 82642 IA_NA: ID=1, T1=1000, T2=2000 Jul 11 16:29:49 dhcp6c 82642 get DHCP option IA address, len 24 Jul 11 16:29:49 dhcp6c 82642 IA_NA address: 2a06:4000:8888:ffff::2 pltime=3000 vltime=4000 Jul 11 16:29:49 dhcp6c 82642 get DHCP option DNS, len 32 Jul 11 16:29:49 dhcp6c 82642 get DHCP option IA_PD, len 41 Jul 11 16:29:49 dhcp6c 82642 IA_PD: ID=1, T1=1000, T2=2000 Jul 11 16:29:49 dhcp6c 82642 get DHCP option IA_PD prefix, len 25 Jul 11 16:29:49 dhcp6c 82642 IA_PD prefix: 2a06:4000:8888::/48 pltime=3000 vltime=1546855634413031328 Jul 11 16:29:49 dhcp6c 82642 server ID: 00:01:00:01:21:5a:37:e1:96:96:78:4c:ae:6d, pref=-1 Jul 11 16:29:50 dhcp6c 82642 picked a server (ID: 00:01:00:01:21:56:39:cc:fa:32:37:34:e3:9f) Jul 11 16:29:50 dhcp6c 82642 Sending Request Jul 11 16:29:50 dhcp6c 82642 a new XID (61396e) is generated Jul 11 16:29:50 dhcp6c 82642 set client ID (len 14) Jul 11 16:29:50 dhcp6c 82642 set server ID (len 14) Jul 11 16:29:50 dhcp6c 82642 set elapsed time (len 2) Jul 11 16:29:50 dhcp6c 82642 send request to ff02::1:2%igb0 Jul 11 16:29:50 dhcp6c 82642 reset a timer on igb0, state=REQUEST, timeo=0, retrans=909 Jul 11 16:29:50 dhcp6c 82642 receive reply from fe80::88ce:87ff:fec6:156a%igb0 on igb0 Jul 11 16:29:50 dhcp6c 82642 get DHCP option client ID, len 14 Jul 11 16:29:50 dhcp6c 82642 DUID: 00:01:00:01:2b:8f:81:6a:20:7c:14:a1:bf:06 Jul 11 16:29:50 dhcp6c 82642 get DHCP option server ID, len 14 Jul 11 16:29:50 dhcp6c 82642 DUID: 00:01:00:01:21:56:39:cc:fa:32:37:34:e3:9f Jul 11 16:29:50 dhcp6c 82642 get DHCP option identity association, len 40 Jul 11 16:29:50 dhcp6c 82642 IA_NA: ID=1, T1=1000, T2=2000 Jul 11 16:29:50 dhcp6c 82642 get DHCP option IA address, len 24 Jul 11 16:29:50 dhcp6c 82642 IA_NA address: 2a06:4000:8888:ffff::2 pltime=3000 vltime=4000 Jul 11 16:29:50 dhcp6c 82642 get DHCP option DNS, len 32 Jul 11 16:29:50 dhcp6c 82642 get DHCP option IA_PD, len 41 Jul 11 16:29:50 dhcp6c 82642 IA_PD: ID=1, T1=1000, T2=2000 Jul 11 16:29:50 dhcp6c 82642 get DHCP option IA_PD prefix, len 25 Jul 11 16:29:50 dhcp6c 82642 IA_PD prefix: 2a06:4000:8888::/48 pltime=3000 vltime=1546855634413031328 Jul 11 16:29:50 dhcp6c 82642 dhcp6c Received REQUEST Jul 11 16:29:50 dhcp6c 82642 nameserver[0] 2a06:4000:0:6::6 Jul 11 16:29:50 dhcp6c 82642 nameserver[1] 2a06:4000:0:6::5 Jul 11 16:29:50 dhcp6c 82642 executes /var/etc/dhcp6c_wan_dhcp6withoutra_script.sh Jul 11 16:29:50 dhcp6c 36281 dhcp6c REQUEST on igb0 - running rtsold Jul 11 16:29:50 dhcp6c 82642 script "/var/etc/dhcp6c_wan_dhcp6withoutra_script.sh" terminated Jul 11 16:29:50 dhcp6c 82642 removing an event on igb0, state=REQUEST Jul 11 16:29:50 dhcp6c 82642 removing server (ID: 00:01:00:01:21:56:39:cc:fa:32:37:34:e3:9f) Jul 11 16:29:50 dhcp6c 82642 removing server (ID: 00:01:00:01:21:5a:37:e1:96:96:78:4c:ae:6d) Jul 11 16:29:50 dhcp6c 82642 got an expected reply, sleeping.

@Gertjan plus I have that authenticated ntp patch on that file also

@Gertjan Fixed it. I had on the interface address both an IPv6 address and an "IPv4 address embedded in the IPv6 address (this is known as IPv6-mapped IPv4 addresses or IPv6 embedded IPv4 addresses)" before that is normally not for interfaces only the static device assignments so that is corrected my Pv6-mapped IPv4 addresses or IPv6 embedded IPv4 addresses are now only on the Lan devices and not on the firewall interfaces. [image: 1752100262620-screenshot-2025-07-09-at-15.29.37-resized.png]

I ran this command after upgrading from 2.7.2 to 2.8.0, as I started experiencing significant issues with my work VPN connection behind the firewall. Upon checking the connection properties, I noticed that the VPN was attempting to connect through an IPv6 gateway. What’s particularly strange is that while the VPN would eventually connect, it often required multiple connection attempts before any traffic would actually pass through. I’m hoping this fix resolves the issue moving forward—fingers crossed for the next time I need to connect.