OPNsense Forum
English Forums => 23.7 Legacy Series => Topic started by: lss4 on October 30, 2023, 03:10:35 pm
-
The original post I made was here (https://forum.opnsense.org/index.php?topic=33094.msg160055#msg160055) 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?
-
You could trace the DHCPv6 packets and analyse them with Wireshark.
However, if you specify to get a /61 prefix in DHCPv6 on OpnSense and do not get it, then probably OpenWRT does not provide as much. I know that for DHCPv6, both a prefix and an address can be requested.
That is what OpnSense's "request IPv6 prefix only" flag is for - BTW: my ISP does not provide an IPv6 for my router, but only a /56 prefix. Thus, my OpnSense WAN interface does not have an IPv6 GUA. This is no problem, since the LAN interface gets one from the prefix range, so my OpnSense can well communicate via IPv6.
If OpenWRT chooses to also request an IPv6 for itself in addition to the prefix, then probably you do not really get the whole /60 for prefixes handed down, which could explain why a smaller prefix is given to your OpnSense. If this is the case, you will have to find a way to disable it (on OpenWRT).
-
Delegating a /61 from one OPNsense to another OPNsense works fine in my test environment, so I'm pretty confident this is an OpenWrt issue. Some of their features have a little bit too much automagic for my taste...
Cheers
Maurice
-
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.
-
I meant to use the "request an IPv6 prefix only" equivalent on OpenWRT - if it exists, not on OpnSense.
As Maurice verified, OpnSense clearly can delegate and request specific prefix lengths, so it must be OpenWRT that does not hand out the full /61 for whatever reason. I bet you will see that in the DHCPv6 exchange.
-
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.
No need to install anything for packet capture. Interfaces > Diagnostics > Packet Capture
-
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.