WAN_DHCP6 learns OPNsense LAN link-local address as IPv6 gateway instead of FBox

Started by noclue68, November 03, 2026, 08:32:46 PM

Previous topic - Next topic
Hello,

I'm facing a very strange IPv6 issue and after extensive troubleshooting I cannot explain the behaviour anymore.

Topology:

Internet
  |
FRITZ!Box
  |
OPNsense WAN
  |
OPNsense LAN
  |
GS308E Switch
  |
Clients

Environment:

- OPNsense running as VM on Proxmox
- WAN and LAN are on separate virtual NICs
- WAN and LAN are connected to separate Proxmox bridges
- FRITZ!Box configured with Exposed Host
- DHCPv6-PD enabled

OPNsense NICs:

LAN:
MAC BC:24:11:89:92:3C

WAN:
MAC BC:24:11:E3:15:CE

FRITZ!Box:

MAC B4:FC:7D:50:16:A5

Problem:

System > Gateways shows:

WAN_DHCP6 (active)

Gateway:
fe80::be24:11ff:fe89:923c

However, fe80::be24:11ff:fe89:923c belongs to the LAN interface of OPNsense itself.

NDP confirms:

OPNsense LAN:
fe80::be24:11ff:fe89:923c
MAC bc:24:11:89:92:3c

FRITZ!Box:
fe80::b6fc:7dff:fe50:16a5
MAC b4:fc:7d:50:16:a5

The FRITZ!Box is visible and reachable via NDP, but OPNsense still installs its own LAN link-local address as the active WAN_DHCP6 gateway.

Additional log message:

RA with a lower CurHopLimit sent from
fe80::be24:11ff:fe89:923c
(current = 255, received = 64)
Ignored.

Already tested:

- Fresh OPNsense installation
- GS308E factory reset
- Same behaviour after reinstall
- WAN and LAN are separated
- FRITZ!Box link-local address visible in NDP
- Issue reproducible

Expected gateway:

fe80::b6fc:7dff:fe50:16a5

Actual gateway:

fe80::be24:11ff:fe89:923c

Has anyone seen OPNsense learning its own LAN link-local address as WAN_DHCP6 gateway before?

I would appreciate any ideas regarding DHCPv6-PD, Router Advertisements or gateway discovery in this setup.

Thanks.


That was my first suspicion.

However, WAN and LAN are on separate NICs and separate Proxmox bridges. I also factory-reset the managed switch and reproduced the issue on a fresh OPNsense installation.

NDP correctly discovers the FRITZ!Box:

fe80::b6fc:7dff:fe50:16a5
MAC b4:fc:7d:50:16:a5

but WAN_DHCP6 still installs

fe80::be24:11ff:fe89:923c

which belongs to the OPNsense LAN interface.

Could a layer-2 loop still explain this behaviour?

Use a packet trace and look for router advertisements or DHCPv6 on the WAN interface.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Its most of the time a vlan trunk misconfiguration. If untagged and tagged frames are mixed, some weird stuff can happen, like leaking router advertisements between vlans.

https://docs.opnsense.org/manual/how-tos/vlan_and_lagg.html

Read this.
Hardware:
DEC740

The more interesting observation is that the LAN link-local address (fe80::be24:11ff:fe89:923c) appears in the NDP cache of the WAN interface (vtnet1) with the LAN MAC address (bc:24:11:89:92:3c).

If WAN and LAN are completely separated, how can the WAN interface learn the LAN link-local address via NDP at all?

Could this indicate an issue in Proxmox bridge handling, VirtIO networking or Neighbor Discovery processing rather than DHCPv6-PD itself?


Additional findings:

The Fritz!Box sees both OPNsense interfaces separately:

WAN:
MAC BC:24:11:E3:15:CE
IPv4 192.168.121.200

LAN:
MAC BC:24:11:89:92:3C
IPv4 192.168.1.1

However, the Fritz!Box also associates IPv6 addresses derived from both MAC addresses with both entries.

Packet captures on WAN repeatedly show NDP traffic between:

fe80::be24:11ff:fee3:15ce (WAN)
and
fe80::be24:11ff:fe89:923c (LAN)

The LAN link-local address appears in the WAN NDP table and is reachable.

At this point the issue seems less related to DHCPv6-PD itself and more related to how link-local addresses and neighbor discovery are handled between interfaces.

The correct Fritz!Box link-local address (fe80::b6fc:7dff:fe50:16a5) remains visible and reachable at all times.


Netgear GS308E works as regular switch - current factory settings


You almost certainly have the two networks not quite as separated as you think they are.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

At this point, I believe the best approach is either to rebuild the setup from scratch or to go through the network configuration step by step again to identify what may have been missed.

Thank you very much for your support so far. I appreciate your help and will keep you informed of the results after I have completed the review.