"Recent posts
#1
25.7, 25.10 Series / Re: IPv6 erratically broken fr...
Last post by Monviech (Cedrik) - January 02, 2026, 10:02:45 PMIf the android devices fail, first assumption would be they drop the default IPv6 gateway for whatever reason. Did you check that on the devices?
I guess you ruled firewall issues out, so routing or ndp might be the cause?
Routing - Clients loose default gateway or receive wrong gateway due to RA
NDP - Clients cannot resolve default gateway (or SLLA option sent by RA daemon is not as expected and traffic gets sent to the wrong router)
If you have two RA daemons running on different firewalls in the same network, both asvertising default router, this can also happen as they both advertise their own SLLA option and traffic gets routed wrong eventually.
I guess you ruled firewall issues out, so routing or ndp might be the cause?
Routing - Clients loose default gateway or receive wrong gateway due to RA
NDP - Clients cannot resolve default gateway (or SLLA option sent by RA daemon is not as expected and traffic gets sent to the wrong router)
If you have two RA daemons running on different firewalls in the same network, both asvertising default router, this can also happen as they both advertise their own SLLA option and traffic gets routed wrong eventually.
#2
25.7, 25.10 Series / Re: IPv6 erratically broken fr...
Last post by rmayr - January 02, 2026, 09:41:24 PMThanks for the quick reply! The Guest interface I have generated these tcdpump and live firewall logs from doesn't actually have any Virtual IP Aliases on it at the moment (some other VLANs do, and the Android devices on those behave similarly). This Guest interface only has a static IPv4 address (which works without an issue on the Android devices) and the IPv6 address tracking the WAN assigned prefix.
These are (hopefully relevant parts of) the interface details for Guest:
For the Guest interface, "Allow manual adjustment of DHCPv6 and Router Advertisements" is set. DHCPv4 is served by Dnsmasq, and no DHCPv6 at the moment (as Android devices won't use it anyways). Router advertisements (radvd, not dnsmasq so far) are set to Stateless with "Advertise Default Gateway" ticked and Source Address to "Automatic".
These are (hopefully relevant parts of) the interface details for Guest:
Code Select
Media 1000baseT <full-duplex>
Media (Raw) Ethernet autoselect (1000baseT <full-duplex>)
Status up
nd6
flags
performnud
auto_linklocal
Routes 192.168.65.0/24
2a03:fa00:650:31::/64
fe80::%igb2_vlan65/64
Identifier opt5
Description Guest
Enabled true
Link Type static
addr4 192.168.65.254/24
addr6 2a03:fa00:650:31:20d:b9ff:fe58:5e2a/64
IPv4 Addresses
192.168.65.254/24
192.168.65.1/24 vhid 6
IPv6 Addresses
2a03:fa00:650:31:20d:b9ff:fe58:5e2a/64
fe80::20d:b9ff:fe58:5e2a/64
VLAN Tag 65
Gateways
Driver vlan1
...
Line Rate 1.00 Gbit/s
Packets Received 154404
Input Errors 0
Packets Transmitted 204150
Output Errors 0
Collisions 0For the Guest interface, "Allow manual adjustment of DHCPv6 and Router Advertisements" is set. DHCPv4 is served by Dnsmasq, and no DHCPv6 at the moment (as Android devices won't use it anyways). Router advertisements (radvd, not dnsmasq so far) are set to Stateless with "Advertise Default Gateway" ticked and Source Address to "Automatic".
#3
General Discussion / Re: Partition or not?
Last post by OPNenthu - January 02, 2026, 09:37:10 PMMaybe you'll decide that 512GB is just too much to waste, but a benefit of having a good amount of unused space in general is that it extends the service life of the SSD. Not a bad thing for an appliance that you want to keep running for presumably several years, if not more, especially with ZFS and logs/netflow enabled. Depending on trends, replacement SSDs may be more expensive or harder to come by soon. Already happening in the GPU and RAM consumer markets.
#4
25.7, 25.10 Series / Re: IPv6 erratically broken fr...
Last post by Monviech (Cedrik) - January 02, 2026, 08:58:25 PMI would suggest to create the simplest topology for the wifi (no virtual IP addresses, no CARP, no firewall aliases (just any as destination).
Then retry if you have issues.
If not, introduce these features back in one by one.
Best if you use a new vlan you send out via another SSID to check.
Maybe the devices don't like using a vietual CARP MAC address as their gateway, or something about the firewall policies is wrong.
As general rule of thumb, reducing complexity is always a good way to catch bugs.
Then retry if you have issues.
If not, introduce these features back in one by one.
Best if you use a new vlan you send out via another SSID to check.
Maybe the devices don't like using a vietual CARP MAC address as their gateway, or something about the firewall policies is wrong.
As general rule of thumb, reducing complexity is always a good way to catch bugs.
#5
General Discussion / Allow IGMP queries on WAN for ...
Last post by OPNenthu - January 02, 2026, 08:52:13 PMSome weeks ago my ISP did some infrastructure upgrades in the area and since then I'm seeing constant IGMP membership queries on WAN to the all-members multicast address (224.0.0.1). I understand this traffic to be link-local and likely is from the ISP's CMTS for all cable subscribers on the segment.
Should I be allowing these to pass, or is it better to keep dropping? AFAIK these shouldn't impact our services as we don't subscribe for IPTV.
You cannot view this attachment.
Should I be allowing these to pass, or is it better to keep dropping? AFAIK these shouldn't impact our services as we don't subscribe for IPTV.
You cannot view this attachment.
#6
25.7, 25.10 Series / IPv6 erratically broken from A...
Last post by rmayr - January 02, 2026, 08:47:18 PMHi everybody,
I have been bumping my head against this issue for too many months and would really like to solve this now, but don't know where to continue debugging.
Issue: Android clients on WiFi often fail to connect through OPNsense on IPv6 to the WAN connection, while all other Linux hosts work fine, with static IPv6 addresses assigned manually as well as with SLAAC and privacy extensions generated addresses.
Setup: I run a cluster of two OPNsense firewalls. IPv6 address space is assigned by the FTTH provider with DHCPv6-PD over PPPoE on the respective master firewall. This works without issues, and I assign a derived address to the WAN interface (PPPoE) through a Virtual IP Alias to make sure the firewall itself is globally reachable through IPv6. All local interfaces (on VLANs assigned to a trunk port) are tracking the WAN interface for IPv6 with unique prefixes. Additionally, some of the local interfaces have ULA Virtual IP Aliases (statically as well as through CARP tied to the IPv4 shared address) for local IPv6 connectivity when the WAN side is down.
All_local is an interface group around all local interfaces (those that are neither WAN nor VPN).
Firewall rules: Fairly simple setup for each of the local interfaces: e.g. for the Guest interface, the first interface-specific rule is
When I watch the traffic on this interface locally on the firewall shell with tcpdump, I see the traffic from the (randomized) MAC address of an Android device trying to run https://test-ipv6.com:
but no replies. In the firewall live log, when filtering for this (randomized) SLAAC address, I see some pass, but also some occasional block messages:
The weirdest thing is that, when disconnecting the Android device from WiFi and reconnecting (forcing a refresh of the SLAAC addresses), it occasionally works for a brief period (in the range of minutes) before it fails again. Other Linux hosts work consistently. I have tried many different things during debugging (disabling source or destination matches, adding an explicit only-IPv6 rule, etc.) and am completely confused why that rule might not match some of the packets. Any hints would be greatly appreciated.
I have been bumping my head against this issue for too many months and would really like to solve this now, but don't know where to continue debugging.
Issue: Android clients on WiFi often fail to connect through OPNsense on IPv6 to the WAN connection, while all other Linux hosts work fine, with static IPv6 addresses assigned manually as well as with SLAAC and privacy extensions generated addresses.
Setup: I run a cluster of two OPNsense firewalls. IPv6 address space is assigned by the FTTH provider with DHCPv6-PD over PPPoE on the respective master firewall. This works without issues, and I assign a derived address to the WAN interface (PPPoE) through a Virtual IP Alias to make sure the firewall itself is globally reachable through IPv6. All local interfaces (on VLANs assigned to a trunk port) are tracking the WAN interface for IPv6 with unique prefixes. Additionally, some of the local interfaces have ULA Virtual IP Aliases (statically as well as through CARP tied to the IPv4 shared address) for local IPv6 connectivity when the WAN side is down.
All_local is an interface group around all local interfaces (those that are neither WAN nor VPN).
Firewall rules: Fairly simple setup for each of the local interfaces: e.g. for the Guest interface, the first interface-specific rule is
- pass
- non-quick
- interface: Guest
- Direction: in
- TCP/IP Version: IPv4/IPv6
- Protocol: any
- Source: Guest net
- Destination: (inverted) All_local net
- Occasionally with logging enabled while I am debugging, and also experimented with advanced "State Type" set to "sloppy", but that does not seem to change anything.
When I watch the traffic on this interface locally on the firewall shell with tcpdump, I see the traffic from the (randomized) MAC address of an Android device trying to run https://test-ipv6.com:
Code Select
20:33:55.367693 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.40900 > 2600:3c0e::f03c:94ff:fed0:118c.443: Flags [S], seq 3874906471, win 65535, options [mss 1432,sackOK,TS val 502769255 ecr 0,nop,wscale 8], length 0
20:33:55.414492 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.40510 > 2a01:7e01::f03c:94ff:fed0:4087.443: Flags [S], seq 1619834821, win 65535, options [mss 1432,sackOK,TS val 2932320577 ecr 0,nop,wscale 8], length 0
20:33:55.437239 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.40512 > 2a01:7e01::f03c:94ff:fed0:4087.443: Flags [S], seq 4131834176, win 65535, options [mss 1432,sackOK,TS val 2932320598 ecr 0,nop,wscale 8], length 0
20:33:55.463117 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.47108 > 2a01:7e01:e001:8a6::1280.443: Flags [S], seq 1539005391, win 65535, options [mss 1432,sackOK,TS val 2440076159 ecr 0,nop,wscale 8], length 0
20:33:55.473900 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.40516 > 2a01:7e01::f03c:94ff:fed0:4087.443: Flags [S], seq 3851900761, win 65535, options [mss 1432,sackOK,TS val 2932320635 ecr 0,nop,wscale 8], length 0
20:33:55.479104 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.40532 > 2a01:7e01::f03c:94ff:fed0:4087.443: Flags [S], seq 3848844477, win 65535, options [mss 1432,sackOK,TS val 2932320641 ecr 0,nop,wscale 8], length 0
20:33:55.620392 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.40916 > 2600:3c0e::f03c:94ff:fed0:118c.443: Flags [S], seq 1870185323, win 65535, options [mss 1432,sackOK,TS val 502769508 ecr 0,nop,wscale 8], length 0
20:33:55.667322 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.40536 > 2a01:7e01::f03c:94ff:fed0:4087.443: Flags [S], seq 2725483835, win 65535, options [mss 1432,sackOK,TS val 2932320829 ecr 0,nop,wscale 8], length 0
20:33:55.690199 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.40550 > 2a01:7e01::f03c:94ff:fed0:4087.443: Flags [S], seq 3188154451, win 65535, options [mss 1432,sackOK,TS val 2932320851 ecr 0,nop,wscale 8], length 0
20:33:55.716457 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.47118 > 2a01:7e01:e001:8a6::1280.443: Flags [S], seq 1085541019, win 65535, options [mss 1432,sackOK,TS val 2440076413 ecr 0,nop,wscale 8], length 0
20:33:55.725721 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.40552 > 2a01:7e01::f03c:94ff:fed0:4087.443: Flags [S], seq 2983529768, win 65535, options [mss 1432,sackOK,TS val 2932320887 ecr 0,nop,wscale 8], length 0
20:33:56.392231 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.40900 > 2600:3c0e::f03c:94ff:fed0:118c.443: Flags [S], seq 3874906471, win 65535, options [mss 1432,sackOK,TS val 502770279 ecr 0,nop,wscale 8], length 0
20:33:56.419442 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.40510 > 2a01:7e01::f03c:94ff:fed0:4087.443: Flags [S], seq 1619834821, win 65535, options [mss 1432,sackOK,TS val 2932321581 ecr 0,nop,wscale 8], length 0
20:33:56.487596 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.47108 > 2a01:7e01:e001:8a6::1280.443: Flags [S], seq 1539005391, win 65535, options [mss 1432,sackOK,TS val 2440077184 ecr 0,nop,wscale 8], length 0
20:33:56.644072 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.40916 > 2600:3c0e::f03c:94ff:fed0:118c.443: Flags [S], seq 1870185323, win 65535, options [mss 1432,sackOK,TS val 502770531 ecr 0,nop,wscale 8], length 0
20:33:56.675675 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.40536 > 2a01:7e01::f03c:94ff:fed0:4087.443: Flags [S], seq 2725483835, win 65535, options [mss 1432,sackOK,TS val 2932321837 ecr 0,nop,wscale 8], length 0
20:33:56.739577 02:a2:4a:0c:29:fd > 00:0d:b9:58:5e:2a, ethertype IPv6 (0x86dd), length 94: 2a03:fa00:650:31:b307:9f59:86f:33a9.47118 > 2a01:7e01:e001:8a6::1280.443: Flags [S], seq 1085541019, win 65535, options [mss 1432,sackOK,TS val 2440077436 ecr 0,nop,wscale 8], length 0but no replies. In the firewall live log, when filtering for this (randomized) SLAAC address, I see some pass, but also some occasional block messages:
Code Select
Guest In 2026-01-02T20:33:15 TCP [2a03:fa00:650:31:b307:9f59:86f:33a9]:37112 [2a01:7e01:e001:8a6::1280]:443 pass Allow Guest to WAN
Guest In 2026-01-02T20:33:15 TCP [2a03:fa00:650:31:b307:9f59:86f:33a9]:39150 [2a01:7e01::f03c:94ff:fed0:4087]:443 pass Allow Guest to WAN
Guest In 2026-01-02T20:33:12 TCP [2a03:fa00:650:31:b307:9f59:86f:33a9]:59330 [2a00:1450:4001:80e::200a]:443 block Default deny / state violation rule
Guest In 2026-01-02T20:33:03 TCP [2a03:fa00:650:31:b307:9f59:86f:33a9]:60540 [2a00:1450:4001:831::2003]:443 pass Allow Guest to WAN
Guest In 2026-01-02T20:33:03 TCP [2a03:fa00:650:31:b307:9f59:86f:33a9]:60530 [2a00:1450:4001:831::2003]:443 pass Allow Guest to WAN
Guest In 2026-01-02T20:33:00 TCP [2a03:fa00:650:31:b307:9f59:86f:33a9]:60040 [2a01:7e01::f03c:94ff:fed0:4087]:443 pass Allow Guest to WANThe weirdest thing is that, when disconnecting the Android device from WiFi and reconnecting (forcing a refresh of the SLAAC addresses), it occasionally works for a brief period (in the range of minutes) before it fails again. Other Linux hosts work consistently. I have tried many different things during debugging (disabling source or destination matches, adding an explicit only-IPv6 rule, etc.) and am completely confused why that rule might not match some of the packets. Any hints would be greatly appreciated.
#7
German - Deutsch / Re: Glasfaser Plus + Telekom +...
Last post by moe.camp - January 02, 2026, 08:11:58 PMJa die Faser war angeschlossen, den Gerätetausch konnte ich bei der Telekom nicht erfolgreich durchführen, weil das SFP nicht im Minutentakt sondern sekündlich bootet und somit vermutlich gar keine Verbindung mit dem OLT zustande kommt. Hab jetzt erstmal wieder das Huawei drin und versuche den Glasfasersupport zu erreichen.
Was ich noch gemacht hab: Ich habe den Mini PC aktuell noch doppelt da, weil bei dem einen der Versand sich verzögert hatte. Ist leider dieselbe Hardware, darum ist der Test jetzt nicht soo aussagekräftig, aber Zyxel und Huawei verhalten sich in dem anderen Mini PC identisch. Also Zyxel ist alle paar Sekunden weg und das Huawei geht bis O5, aber dann kommt beim PPPoE keine Antwort. Auf dem zweiten Mini-PC ist ein pfSense drauf, das verhält sich da identisch.
Edit: Ohne angeschlossene Faser verhält sich das Zyxel genauso. Zeigt komische Werte (Temperatur 255 oder 0, und verschwindet gänzlich aus der Ausgabe von ifconfig -v ix0).
Was ich noch gemacht hab: Ich habe den Mini PC aktuell noch doppelt da, weil bei dem einen der Versand sich verzögert hatte. Ist leider dieselbe Hardware, darum ist der Test jetzt nicht soo aussagekräftig, aber Zyxel und Huawei verhalten sich in dem anderen Mini PC identisch. Also Zyxel ist alle paar Sekunden weg und das Huawei geht bis O5, aber dann kommt beim PPPoE keine Antwort. Auf dem zweiten Mini-PC ist ein pfSense drauf, das verhält sich da identisch.
Edit: Ohne angeschlossene Faser verhält sich das Zyxel genauso. Zeigt komische Werte (Temperatur 255 oder 0, und verschwindet gänzlich aus der Ausgabe von ifconfig -v ix0).
#8
25.7, 25.10 Series / Re: VLANs almost working on te...
Last post by Maurice - January 02, 2026, 08:04:53 PMVLANs should be configured on the VM host (Proxmox), not in the guest (OPNsense). The guest should have a dedicated interface for each VLAN.
Cheers
Maurice
Cheers
Maurice
#9
Tutorials and FAQs / Re: HOWTO - Redirect all DNS R...
Last post by yourfriendarmando - January 02, 2026, 07:53:13 PMAlso, in case it hasn't been reiterated, you might want to additionally prevent devices like Android and IT'S from escaping your DNS and attempting DNS over HTTP.
I recommend using a Floating rule, connected to a URL alias to v4/v6 lists, to keep those devices in check:
https://github.com/crypt0rr/public-doh-servers
https://github.com/oneoffdallas/dohservers/tree/master
https://github.com/dibdot/DoH-IP-blocklists/tree/master
Use a Firewall group to restrict you NAT and the rule above to local Interfaces and not interfere with the Firewall's ability to access DNS resources.
Here is also an older post on the matter:
https://forum.opnsense.org/index.php?topic=33931.0
Watch your Apple users start to hate you haha.
I recommend using a Floating rule, connected to a URL alias to v4/v6 lists, to keep those devices in check:
https://github.com/crypt0rr/public-doh-servers
https://github.com/oneoffdallas/dohservers/tree/master
https://github.com/dibdot/DoH-IP-blocklists/tree/master
Use a Firewall group to restrict you NAT and the rule above to local Interfaces and not interfere with the Firewall's ability to access DNS resources.
Here is also an older post on the matter:
https://forum.opnsense.org/index.php?topic=33931.0
Watch your Apple users start to hate you haha.
#10
German - Deutsch / Re: Glasfaser Plus + Telekom +...
Last post by Maurice - January 02, 2026, 07:49:58 PMHast Du schon die Faser angeschlossen und die Seriennummer registriert?
Das Zyxel meldet ohne aktive Faser "RX loss". Und ist eine Faser angeschlossen aber O5 wird nicht erreicht, dann startet es nach ein paar Minuten neu.
Bei mir läuft es in einem MikroTik-Router, da funktioniert es mit Auto-Negotiation. Mit dem Betrieb in einer Intel-NIC habe ich leider keine Erfahrung.
Das Zyxel meldet ohne aktive Faser "RX loss". Und ist eine Faser angeschlossen aber O5 wird nicht erreicht, dann startet es nach ein paar Minuten neu.
Bei mir läuft es in einem MikroTik-Router, da funktioniert es mit Auto-Negotiation. Mit dem Betrieb in einer Intel-NIC habe ich leider keine Erfahrung.
