English Forums > 22.7 Legacy Series

IPv6: Disable EUI64 auto address assignment on WAN from ISP RA?


Hello! I recently switched over to opnsense after leaving pfsense behind at the 2.4.5 release.

Both router distros have had IPv6 issues with my ISP (Google Webpass) since I moved here and started service with them. Don't get me wrong the service is great, but something about their IPv6 configuration just does not cooperate with FreeBSD routers by default.

More specifically, their router always sends me IPv6 RAs with prefix information with L+A flags set. As a result FreeBSD is taking the prefix and auto assigning an EUI64 address from it for the WAN interface; in my case the Router Advertisement looks like this.

Despite the fact that I think opnsense is "technically correct" here; Webpass is sending 2604:5500:30c8::/64 and telling me to autoconfig inside that prefix, Webpass blackholes traffic from the EUI64 auto configured address on the WAN interface (2604:5500:30c8:0:ae1f:6bff:fe83:22f7):

--- Code: ---igb1: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: WAN
        ether ac:1f:6b:83:22:f7
        inet6 fe80::ae1f:6bff:fe83:22f7%igb1 prefixlen 64 scopeid 0x2
        inet6 2604:5500:30c8:0:ae1f:6bff:fe83:22f7 prefixlen 64 autoconf
        inet6 2604:5500:30c8::662 prefixlen 128
        inet netmask 0xfffffc00 broadcast
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active

--- End code ---

I need to find a way to prevent opnsense from assigning that autoconf EUI64 address on the WAN IF or else all IPv6 traffic originating from the firewall itself fails. By default the router is using 2604:5500:30c8:0:ae1f:6bff:fe83:22f7 instead of the DHCPv6 assigned address 2604:5500:30c8::662; all my LAN clients do get an IPv6 address via either SLAAC or DHCPv6 from the valid /56 PD that they serve me, so they all work fine, but stuff like DNS from the router grinds to a halt or barely works at all.

I *think* the fix is to simply remove the ACCEPT_RTADV from the WAN if (igb1) and allow the DHCPv6 client to grab a prefix to pass to the LAN if and a WAN IP for the router to use. I just can't figure out the appropriate place to patch opnsense to ensure that flag is no longer set for my WAN if. (I'm also not really clear if doing so is going to break the IPv6 routing table; maybe I would rather just have radvd ignore the A flag on the RA?)

Thanks for any advice!

Does your ISP support DHCPv6 instead of SLAAC? In that case, you can configure your WAN as DHCPv6, advanced send options: "ia-pd 0, ia-na 0" and prefix delegation on with "id-assoc pd 0" and 56 bits prefix length.

I had just the opposite problem (my ISP hands out prefixes only, but no interface address), so I can confirm that using no IPv6 on the WAN interface works. Using DHVPv6 enables control over this.

I opened another support ticket with Webpass after looking over this again; the gist is that opnsense (really FreeBSD) is diligently and correctly obeying the flags set in the RA which suggests it should grab a SLAAC address in the 2604:5500:30c8::/64 prefix, which it is doing EUI-64 style. Per the advertisment the address is valid and routable, but Webpass is dropping traffic from it claiming it is not assigned or in a valid range.

The fix here is for Webpass to stop flagging L+A and just flag L. The workaround (which I haven't figured out how to accomplish) would be to tell FreeBSD to ignore SLAAC on this IF and just used DHCPv6.

Webpass has escalated to their engineering team to have a look at the configuration, hopefully they'll realize they either need to permit valid SLAAC addresses in the range they are advertising or move to stateful only RAs.

I am already pulling a /56 PD via DHCPv6 and the DHCPv6 server will (optionally) provide my WAN IF with an address. The issue is FreeBSD sees the SLAAC RAs first and generates the EUI-64 address early/with a higher priority metric so local IPV6 traffic from the router itself originates from the EUI-64 address and gets dropped (making things like unbound time out or extremely slow when resolving upstream). This change actually prevents unbound from respecting prefer IPv4 and causes the pitifully slow DNS performance when the router itself doesn't have a valid WAN facing IPv6 assignment.

I would have thought that with there being two settings (SLAAC and DHCPv6) for the WAN interface, SLAAC would be disabled altogether if DHCPv6 was used, but it is not.

You could try to disable accept_rtadv, but maybe that breaks DHCPv6 too (see here). If you want to try, it is possible in the system tunables: net.inet6.ip6.accept_rtadv=0

Vodafone in Germany has been doing the same thing since ~2022-04.

--- Code: ---em0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: WAN
        ether ab:cd:ef:12:34:56
        inet6 fe80::x%em0 prefixlen 64 scopeid 0x1
        inet6 2a02:908::x prefixlen 64 autoconf
        inet6 2a02:3102::x prefixlen 64 detached autoconf
        inet6 2a02:3102::x prefixlen 64 autoconf
        inet6 2a02:908::x prefixlen 128
        inet 84.119.xxx.xxx netmask 0xfffffc00 broadcast
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active

--- End code ---
The /64 autoconf IPs are not routed only the /128 works as a source. Clients using dhcp6 delegated prefixes work fine but local ipv6 requests from opnsense fail.
Currently I use a cronjob based on https://blog.veloc1ty.de/2021/02/28/opnsense-prefer-source-address/ to set the working address as prefer_source:

--- Code: ---#!/bin/sh

INTERFACE=$(ifconfig | grep -B1 'description: WAN' | head -n1 | cut -w -f 1 | tr -d ':,')
IPv6=$(ifconfig "${INTERFACE}" | grep inet6 | grep -v autoconf | grep -v "inet6 fe80" | cut -w -f 3)

/sbin/ifconfig "${INTERFACE}" inet6 prefer_source "${IPv6}"

--- End code ---


[0] Message Index

Go to full version