opnsense
OPNsense Forwards Link-Local Router Advertisements Across Interface
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
- [X ] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
- [ X] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue
Describe the bug
In my network setup, I have an AT&T BGW-320 modem configured in IP Passthrough mode, connected to the WAN interface of OPNsense (version 25.1.6_4-amd64). The BGW-320 sends IPv6 Router Advertisements (RAs) with its link-local address (fe80::ceab:2cff:fe17:2c31) as the default gateway.
The issue arises because OPNsense forwards these link-local RAs from the WAN interface to the LAN interface. Consequently, LAN clients receive RAs that advertise a default gateway (fe80::ceab:2cff:fe17:2c31) which is not reachable from their segment, leading to IPv6 connectivity problems.
Note - I moved to opnsense from PFsense about a year ago. A few months ago I started actively using IPV6, and started running into this issue. Because things "worked" until they "didnt", It was only today that I finally got the time to figure it all out with wireshark. This behaviour has been consistent through multiple versions of opnsense though not knowing until today the origin of the issue I don't know how far back that was.
To Reproduce
Well, I would imagine all you have to do is put some router ahead of pfsense that is sending RAs to the fe80:: local address and watch it magically flow through. You can look at the way the auto-generated rules are structured; there are 5 autogenerated rules labeled IPV6 RFC4890 requirements. The problem is that the first rule is a wildcard rule that satisfies first-match for all ICMP traffic. I suspect the issue is that these autogenerated rules may be in the wrong order, although either way I think this one will need a block rule. I don't know IPv6 ICMP well enough to spell it out, but I think it's pretty obvious that the auto-generated rules are not correct. Specifically however, there is an explicit forward rule allowing ffo2::/16 to fe80::/10 which I believe will forward inappropriate RAs across the segment boundaries (besides the wildcard before it).
Expected behavior
According to RFC 4861, Section 6.1.1:
"Router Advertisements are sent to all nodes on the link (ff02::1) using link-local source addresses... They must not be forwarded across links."
Therefore, OPNsense should not forward RAs received on one interface (WAN) to another interface (LAN).
Impact
This behavior violates IPv6 standards and leads to clients configuring invalid default routes, disrupting IPv6 connectivity across the network.
Describe alternatives you considered
- Creating firewall rules to block RAs from the upstream router on the LAN interface.
- Configuring OPNsense rules to suppress forwarding of unsolicited multicast traffic from WAN to LAN.
Due to auto-generated rules allowing all RAs through and the inability to preempt these rules, these workarounds are ineffective.
Screenshots
Wireshark logging. This is on my Windows PC on the LAN network. Here you can see the correct ones (ending in c5:45), which are coming from opnsense, along with the upstream ones (ending in 2c:31) which are coming from the BGW-320 router. 2714 2025-05-17 15:47:12.061588 fe80::ceab:2cff:fe17:2c31 ff02::1 ICMPv6 190 Router Advertisement from cc:ab:2c:17:2c:31 13901 2025-05-17 15:53:42.606465 fe80::ceab:2cff:fe17:2c31 ff02::1 ICMPv6 190 Router Advertisement from cc:ab:2c:17:2c:31 15010 2025-05-17 15:54:02.806150 fe80::62be:b4ff:fe07:c545 ff02::1 ICMPv6 166 Router Advertisement from 60:be:b4:07:c5:45 21571 2025-05-17 15:57:38.215676 fe80::62be:b4ff:fe07:c545 ff02::1 ICMPv6 166 Router Advertisement from 60:be:b4:07:c5:45
Relevant log files
See wireshark traces above
Additional context
I would think that an auto-generated block rule to disable forwarding of link-local RAs would do it, along with cleaning up the ruleset that seems overly broad.
Environment
OPNsense Version: 25.1.6_4-amd64 Hardware: Intel Celeron N5105 NUC with Intel 4P Gbit chipset Configuration: AT&T BGW-320 modem in IP Passthrough mode connected to OPNsense WAN port. No VLANs configured on OPNsense. Single LAN network with one WireGuard endpoint configuration.
router advertisements aren't forwarded, but when tracking is enabled, a router advertisement daemon is active on the interface in question (which is currently less visible). This is something we will improve in 25.7 (https://github.com/opnsense/core/issues/8528)
router advertisements aren't forwarded, but when tracking is enabled, a router advertisement daemon is active on the interface in question (which is currently less visible). This is something we will improve in 25.7 (#8528)
Interesting that you say they aren't forwarded. Well, not in a NAT sense true, but that's just because IPV6 doesn't normally use/need NAT. As I said in my original submission, not only is there an auto-generated rule that is allowing those to be forwarded, I showed you evidence of the RA coming from my UPSTREAM router THROUGH the opnsense as a link-local RA address. Since the LAN side of the opnsense is on a different subnet than the UPSTREAM, the link local address (2c31 in this case) is not reachable via the LAN subnet and is being incorrectly forwarded by opnsense.
As I read the RFC, RAs are supposed to be forwarded but NOT if they are link-local types. Link-local types tend to be be default gateway RAs which you never want propagated beyond the local subnet - but again, the opnsense behavior is allowing that.
My physical connectivity is INTERNET -> UPSTREAM ROUTER -> OPNSENSE -> LAN so unless you can figure out how those RAs are arriving on my LAN subnet (see wireshark trace above) without coming through OPNSENSE, those RAs are definitely getting passed through opnsense. Maybe not in the sense of a classic NAT forward rule but in the literal sense of "forwarded the packet from one interface to another"
I'm merely explaining you in which direction to look (radvd), IPv6 can be complicated and I have to intention to debug your specific setup (with little relevant details provided). Best use our forum for discussions like these (https://forum.opnsense.org)
This issue has been automatically timed-out (after 180 days of inactivity).
For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.
If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.
