Messages

I just did some packet capture and found the upstream DHCPv6 server was indeed advertising /62 for some reasons not explained even when looking at the capture in high detail, although OPNsense was requesting whatever prefix I asked (/61 in this case).

After some further inspection on the OpenWrt side of I noticed that the specific port I dedicated for OPNsense had the same MAC address as the rest of the LAN ports, even though I separated that port from the default bridge (br-lan) which combined LAN ports and Wi-Fi as a single interface.

This router actually uses DSA to configure individual LAN/WAN ports instead of VLAN which was the old usual way that's still used in a good amount of devices. I then altered the MAC address of that port to a slightly different one from others just in case. However, this kind of broke the connectivity due to ARP still remembering the old address so I had to disconnect the cable and reboot both sides to make them forget.

Even so, OpenWrt still advertised /62 to OPNsense so the ports having the same MAC address was not the real cause of the issue. OpenWrt's firewall appeared to have handled the zones correctly so even with ports having the same MAC address -- the OPNsense port was correctly isolated from the rest of the router LAN ports.

I ended up changing the configuration like this:
- Make the rest of the router (br-lan) get a /64 (which is enough as the router itself needs only a single subnet).
- Make the OPNsense port get a /61.

And to my surprise, OpenWrt finally advertised /61 to OPNsense and everything's working as expected for the time being. I'll continue monitoring the status on my devices just to be sure it'll stay this way even after some maintenance, like system/FW updates once in a while.

On the OpenWrt side I can assign the whole /60 to a single interface or dividing the prefix into two /61s. All I need to do is choose IPv6 prefix assignment length there.

In the former case OPNsense can claim the whole /60 (or /61), but not the whole /61 in the latter case (instead it gets /62). The interfaces on OpenWrt also have their own IPv6 addresses and this does not interfere with prefix delegation. Choosing to "request IPv6 prefix only" on OPNsense side makes no difference, either.

Will see if I can install or configure some utilities on OPNsense to conduct a packet capture and have a look at the DHCPv6 interactions between OPNsense WAN and OpenWrt.

The original post I made was here while OPNsense was still 23.1. As 23.1 entered legacy and my device is currently running 23.7 I decided not to bump that thread and made some edits there instead while I continued the experiment.

Context: Quite a while ago I was struggling to get my OPNsense device to get a /61 IPv6 prefix so I could let all 6 individual LAN interfaces on the device track WAN for IPv6. Originally I thought I had solved the problem with IPv6 prefix allocation, however, turned out I was wrong.

The OPNsense device is connected to an OpenWrt router which connects to the ISP router (providing a /60 prefix). Ideally I'd like to evenly split the ISP-provided prefix (that would be /61 each) for both OpenWrt LAN and OPNsense WAN (which connects to a dedicated port on the OpenWrt router configured to be isolated from the rest). As I currently have 6 individual LAN interfaces on my OPNsense device, to enable IPv6 on all of them I need at least /61.

Originally I split the prefix on the OpenWrt side into two /61 (one for the rest of OpenWrt router LAN/WiFi, the other for OPNsense WAN). However, in this way, no matter how hard I try OPNsense WAN can only get a /62 prefix, which means I can only enable IPv6 on 4 out of 6 LAN interfaces on the OPNsense side.

When I allocated the entire /60 (from ISP router) to the interface dedicated to OPNsense WAN on my OpenWrt router, however, OPNsense can obtain the entire /60 on WAN after a reset (release DHCPv6, reboot without renewing/reloading). I can also set it to obtain just /61 under this circumstance, but this means the rest of the OpenWrt router (LAN/WiFi) will not have proper IPv6 capability so it's still not the most ideal scenario.

In the end, my problem turned out to be still not fully solved. Is there any way to diagnose DHCPv6 on OPNsense so I can find out why the device is only getting a /62 instead of /61 as I expected?

> All directly connected ethernet like interfaces must use /64 in IPv6.

I'm aware. All interfaces on the device, including WAN itself (which connects directly to the specific port on my OpenWrt router), have a /64 address for its own usage.

The problem is the prefix delegation. I don't know if it's even possible to let the WAN interface claim the entire /61 block I assigned on the OpenWrt side (which is half of the /60 given by the ISP), so I could then get eight /64 ranges.

So far I can only make the OPNsense device's WAN get a /62 prefix range which means I have only four /64 ranges. Attempts to let it get a /61 prefix have so far failed. As such, I can only enable IPv6 on four of all my interfaces (which track against WAN).

(PS: I've six LAN interfaces on the OPNsense device, which consists of five ethernet ports and one wireless adapter in AP mode. Each LAN interface has its own subnet, and I've necessary firewall rules to manage cross-subnet accesses.)

Not to mention the Track Interface function is rather fragile. If something happens on the WAN side or the upstream (OpenWrt side), dhcpd6 would go down and requires a manual reload of WAN before I could bring up dhcpd6 again (in order to restore IPv6 connectivity).

[LATE EDIT:]

I only started using OPNsense recently, and I'm having some IPv6 related questions...

1. The maximum possible prefix problem
My OPNsense device is connected to another OpenWrt-powered router that is connected directly to internet, with an IPv4 address and a /60 IPv6 prefix given. On the OpenWrt side I've configured the port on which the OPNsense device is connected as a separate, isolated interface, and gave both the port for OPNsense and the rest of the LAN each a /61 prefix.

However, on OPNsense side I can only at best configure the interface that would be used as WAN to get a /62 prefix when configured this way. Trying to let it get the whole /61 prefix was not successful. I wonder if it's even possible to hand over the entire prefix to a single device per respective IPv6 specifications...

My IPv6 addresses and prefixes are dynamic, so there's no way I could use static configurations...

2. Problems with dhcpd6 and Track Interface
I've made 4 of my 6 LAN interfaces of the OPNsense device set to Track Interface against WAN (since I can only make WAN get a /62).

However, it seems with this configuration, dhcpd6 would go down whenever something wrong happens on the upstream router or the WAN side of the OPNsense device (usually due to a change to the dynamic IPv6 addresses and prefixes), and I cannot bring it back up without doing a manual reload of WAN interface.

Although the loss of IPv6 connectivity does not completely disable my systems from accessing the Internet, it can affect stability to some extent, as in my place, IPv6 is more stable than IPv4. I wonder if it's possible to make a trigger that whenever dhcpd6 goes down (or fails to start), force WAN to reload (preferrably only the IPv6 address), and repeat this once in a while until dhcpd6 is brought back up successfully, so the issue can be handled all by itself.

LATE EDIT: I'm updating my OPNsense device's system software as time goes. It's currently running 23.7 but so far everything remained the same as when I was writing this thread. To avoid bumping this thread (as 23.1 is now EOL) I'm editing this directly and will be starting a new thread on the 23.7 forum for more questions.

The 1st question (regarding maximum prefix) may not be valid as I noticed something odd when I tinkered the settings on the OpenWrt side, that I've now given the entire /60 to the interface connecting to the OPNsense device (the rest of the LAN on the OpenWrt side will no longer have IPv6 as a result).

I then tried modifying the OPNsense device to let it get /61 and set the interfaces that previously had its IPv6 turned off to Track Interface, but it did not work -- The WAN is still getting /62, even after rebooting both this device and the upstream OpenWrt router several times, as well as releasing/reloading/renewing the WAN DHCP several times. Eventually, I released the WAN DHCP, rebooted OPNsence without renewing (so that WAN was still down), and now it finally gets a /61 as desired, and all my interfaces can obtain IPv6.

Maybe it was always possible to let my device get /61 prefix with the upstream OpenWrt IPv6 having either /60 or /61. It was just the lingering memories of the previously delegated /62 prefix that was preventing it when I initially tried changing the setting on the OPNsense side from /62 to /61.

As for the fragile dhcpd6 "Track Interface" issue... it's still there across all the versions. I'm not sure if the "Prevent Release" option would help somehow. I've just turned it on and see how it looks for the next few days. There's no fixed pattern on when and how dhcpd6 would go down -- sometimes everything could be fine for several days, while other times it would not last for even a single hour.

ANOTHER LATE EDIT: I was wrong. While I was able to manage to get /60 or /61 when I allocated the entire /60 on the OpenWrt side, I simply can only get up to /62 when I split the prefix as two /61s. I wonder if there's a way to diagnose why I'm not getting the desired prefix length...