Topics

I have DSL internet with forced disconnect (access is provided by a DLS modem, not via PPPoE) and get new IPv6 address and prefix after each nightly reconnect. Since an update to 23.1, I am having issues with DHCPv6 PD after a disconnect. The obsolete IPv6 prefix is somehow still delegated, whereas downstream routers get a correct IPv6 address. Downstream clients (behind the downstream router) hence don't get a correct IPv6 address and have no IPv6 connectivity.  In my logs, I can find an error, I don't know if it is related:

Code Select Expand

/usr/local/opnsense/scripts/dhcp/prefixes.php: The command '/sbin/route add -inet6 '2003:d2:2018:f4e1::/60' '2003:d2:2018:f4d1:xxxx:xxxx:xxxx:xxxx'' returned exit code '1', the output was 'route: writing to routing socket: Network is unreachable add net 2003:d2:2018:f4e1::/60: gateway 2003:d2:2018:f4d1:xxxx:xxxx:xxxx:xxxx fib 0: Network is unreachable'

I suspect that OPNsense somehow misses the prefix change.

Restarting the DHCPv6 service doesn't fix the issue. Rebooting OPNsense solves the issue until some unknwon time after the next disconnect.

Other reported issues which might be related:

https://forum.opnsense.org/index.php?topic=32259.0
https://forum.opnsense.org/index.php?topic=32263.0

Anything I can do to help fix this issue?

I have set up OPNsense as the primary router between my DSL modem and a secondary router (OpenWRT with WiFi AP):

DSL Modem -> OPNsense -> LAN1 -> OpenWRT -> LAN2

OPNSense gets a /58 prefix from the DSL modem (dynamic IP). Prefix delegation of /60 ranges is set up in DHCPv6 section of OPNsense. The OpenWRT WAN section gets an IPv6 address and a /60 prefix.

Internet access via IPv6 in LAN1 works without any notable issues.

Internet access via IPv6 works in LAN2 as long as OpenWRT is set up to work as an IPv6 relay. Clients in LAN2 then get an IPv6 from the same range as LAN1 (e. g. 2001:0db8:0:d7c0::/64). However, I then have trouble connecting via IPv6 to some internal servers with static local ULAs in LAN2.

Therefore, I set up OpenWRT as a DHCPv6 server to distribute IPv6 addresses from the delegated range (e.g. 2001:0db8:0:d7d1::/64): I can access the static local ULAs, but then internet access via IPv6 fails. I can see in the OPNsense firewall that the traffic from the client in LAN2 is being blocked ("Default deny / state violation rule").

I would expect that traffic from delegated prefixes is automatically allowed to pass the firewall. Is this expectation wrong? Or am I doing something wrong? Any hints are welcome. If you need more information on my setup, let me know.

Hi,

it seems that I have run into the same issue as https://forum.opnsense.org/index.php?topic=28174.msg136837#msg136837. I have OPNsense running in the latest version (22.1.8_1) as a domU in Xen 4.14.5-pre. Debian Bullseye is running as the dom0. I updated the debian dom0 recently, and today, after restarting the dom0 for the first time since updating it, OPNsense network interfaces are down.

During OPNsense boot, for each virtual network interface, there appears the message "reconfiguring interface due to feature change". After that, the interfaces are down. I can ping my own IP, but no other IPs, error is "interface is down". "ip a" in dom0 shows that the virtual interfaces in dom0 are down. The corresponding network bridge seems to be up. There are no obvious errors in dom0 logs. Other domU networks (Debian, OpenWRT) are working normally. For cross checking reasons, I tried attaching only one virtual interface to OPNsense instead of my original three, but the result was the same.

Exemplary dmesg output in OPNsense:

Code Select Expand


xn0: 2 link states coalesced
xn0: link state changed to UP
lo0: link state changed to UP
xn0: performing interface reset due to feature change
xn0: backend features: feature-sg feature-gso-tcp4
xn0: performing interface reset due to feature change


ifconfig in OPNsens shows for the virtual network interface:

Code Select Expand


xn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: LAN
        ether xx:xx:xx:xx:xx:xx
        inet xxx.xxx.xxx.x netmask 0xffffff00 broadcast xxx.xxx.xxx.xxx
        inet6 xxxx:xxxx:xxxx:xxxx::xxxx prefixlen 64
        inet6 fe80::xxxx:xxxx:xxxx:xxxx%xn0 prefixlen 64 scopeid 0x5
        media: Ethernet manual
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>


ip a in dom0 shows for the virtual interface:

Code Select Expand


64: vif12.0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master xenbr3 state DOWN group default qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever


Besides the "reconfiguring interface due to feature change" message, I have noticed that for each created xen vif, there is one vif.emu visible in the interfaces list on the dom0 for a short time. The .emu interface seems to be connected to PV drivers, but I don't know enough about this topic to be sure if this is related. Also, I don't know if this behavior is completely normal or not.

There are some seemingly related reports on issues with FreeBSD and Xen, but nothing that helped me pinpoint this specific issue. Does anybody have hints on what good next steps for finding the cause for this error could be? I am not very familiar with FreeBSD and xen networking scripts, so I appreciate any tips or links that help me to dig deeper.