IPv6 router advertisements problems in 24.7/24.1.x

Started by himpie, November 21, 2024, 09:14:05 PM

Previous topic - Next topic
November 21, 2024, 09:14:05 PM Last Edit: November 21, 2024, 09:28:08 PM by himpie
Hi,

After years working with pfsense CE/Plus on bare metal box, I finally migrated to OPNsense on the same bare metal box (with 1 NIC configured with multiple VLANs and connected to a switch).
Migration is successfully but have 1 issue. Router Advertisment (RA) on the OPNsense box....
The box is exact the same I used with pfsense CE/Plus.


In pfsense CE and OPNsense 24.1-amd64 everything works fine.
Yesterday I upgraded from OPNsense 24.1-amd64 to OPNsense 24.1.10
After the upgrade from OPNsense 24.1-amd64 to OPNsense 24.1.10 my LAN and WLAN clients don't receive a IPv6 address with Router Advertisement (on OPNsense box) to my FreeBSD DHCP box.

On my FreeBSD DHCP server I see correct RA message from pfsense CE/OPNsense 24.1 from normal IPv6:
Nov 20 18:12:10 <local7.info> apollo dhcpd[79271]: Relay-forward message from 2001:xxxx:yyyy:10::1 port 547, link address 2001:xxxx:yyyy:30::1, peer address fe80::6353:288f:4b6c:e182
Nov 20 18:12:10 <local7.info> apollo dhcpd[79271]: Advertise NA: address 2001:xxxx:yyyy:30:1::13 to client with duid 00:01:00:01:2e:7c:34:90:d0:bf:9c:18:43:f3 iaid = 215007132 static
Nov 20 18:12:10 <local7.info> apollo dhcpd[79271]: Sending Relay-reply to 2001:xxxx:yyyy:10::1 port 547
Nov 20 18:12:10 <local7.info> apollo dhcpd[79271]: Added new forward map from sirens.foo.baar to 2001:xxxx:yyyy:30:1::13
Nov 20 18:12:10 <local7.info> apollo dhcpd[79271]: Added reverse map from 3.1.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.3.0.0.y.y.y.y.x.x.x.x.1.0.0.2.ip6.arpa. to sirens.foo.bar.
Nov 20 18:12:10 <local7.info> apollo dhcpd[79271]: Relay-forward message from 2001:xxxx:yyyy:10::1 port 547, link address 2001:xxxx:yyyy:30::1, peer address fe80::6353:288f:4b6c:e182
Nov 20 18:12:10 <local7.info> apollo dhcpd[79271]: Reply NA: address 2001:xxxx:yyyy:30:1::13 to client with duid 00:01:00:01:2e:7c:34:90:d0:bf:9c:18:43:f3 iaid = 215007132 static
Nov 20 18:12:10 <local7.info> apollo dhcpd[79271]: Sending Relay-reply to 2001:xxxx:yyyy:10::1 port 547
Nov 20 18:12:11 <local7.info> apollo dhcpd[79271]: Added new forward map from sirens.foo.bar. to 2001:xxxx:yyyy:30:1::13
Nov 20 18:12:11 <local7.info> apollo dhcpd[79271]: Added reverse map from 3.1.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.3.0.0.y.y.y.y.x.x.x.x.1.0.0.2.ip6.arpa. to sirens.foo.bar.



On my FreeBSD DHCP server I see incorrect RA message from OPNsense 24.1.10 coming from link-local OPNsense instead of normal IPv6:


Nov 21 16:16:09 <local7.info> apollo dhcpd[79271]: Relay-forward message from 2001:xxxx:yyyy:10::1 port 547, link address fe80::28c:faff:fed6:f01d, peer address fe80::6353:288f:4b6c:e182
Nov 21 16:16:09 <local7.info> apollo dhcpd[79271]: [L2 Relay] No link address in relay packet assuming L2 relay and using receiving interface
Nov 21 16:16:09 <local7.debug> apollo dhcpd[79271]: Picking pool address fe80::31dd
Nov 21 16:16:09 <local7.info> apollo dhcpd[79271]: Advertise NA: address fe80::31dd to client with duid 00:01:00:01:2e:7c:34:90:d0:bf:9c:18:43:f3 iaid = 215007132 valid for 43200 seconds
Nov 21 16:16:09 <local7.info> apollo dhcpd[79271]: Sending Relay-reply to 2001:xxxx:yyyy:10::1 port 547
Nov 21 16:16:09 <local7.info> apollo dhcpd[79271]: Relay-forward message from 2001:xxxx:yyyy:10::1 port 547, link address fe80::28c:faff:fed6:f01d, peer address fe80::6353:288f:4b6c:e182
Nov 21 16:16:09 <local7.info> apollo dhcpd[79271]: [L2 Relay] No link address in relay packet assuming L2 relay and using receiving interface
Nov 21 16:16:09 <local7.debug> apollo dhcpd[79271]: Picking pool address fe80::31dd
Nov 21 16:16:09 <local7.info> apollo dhcpd[79271]: Advertise NA: address fe80::31dd to client with duid 00:01:00:01:2e:7c:34:90:d0:bf:9c:18:43:f3 iaid = 215007132 valid for 43200 seconds
Nov 21 16:16:09 <local7.info> apollo dhcpd[79271]: Sending Relay-reply to 2001:xxxx:yyyy:10::1 port 547
Nov 21 16:16:09 <local7.info> apollo dhcpd[79271]: Relay-forward message from 2001:xxxx:yyyy:10::1 port 547, link address fe80::28c:faff:fed6:f01d, peer address fe80::6353:288f:4b6c:e182
Nov 21 16:16:09 <local7.info> apollo dhcpd[79271]: [L2 Relay] No link address in relay packet assuming L2 relay and using receiving interface
Nov 21 16:16:09 <local7.debug> apollo dhcpd[79271]: Picking pool address fe80::31dd
Nov 21 16:16:09 <local7.info> apollo dhcpd[79271]: Advertise NA: address fe80::31dd to client with duid 00:01:00:01:2e:7c:34:90:d0:bf:9c:18:43:f3 iaid = 215007132 valid for 43200 seconds
Nov 21 16:16:09 <local7.info> apollo dhcpd[79271]: Sending Relay-reply to 2001:xxxx:yyyy:10::1 port 547
Nov 21 16:16:09 <local7.info> apollo dhcpd[79271]: Relay-forward message from 2001:xxxx:yyyy:10::1 port 547, link address fe80::28c:faff:fed6:f01d, peer address fe80::6353:288f:4b6c:e182
Nov 21 16:16:09 <local7.info> apollo dhcpd[79271]: [L2 Relay] No link address in relay packet assuming L2 relay and using receiving interface
Nov 21 16:16:09 <local7.debug> apollo dhcpd[79271]: Picking pool address fe80::31dd
Nov 21 16:16:09 <local7.info> apollo dhcpd[79271]: Advertise NA: address fe80::31dd to client with duid 00:01:00:01:2e:7c:34:90:d0:bf:9c:18:43:f3 iaid = 215007132 valid for 43200 seconds

VLANs on NIC on the OPNsense box:

re0_vlan10: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        description: re0_0010_DMZSERVERS (opt1)
        options=80000<LINKSTATE>
        ether 00:8c:fa:d6:f0:1d
        inet 10.0.1.1 netmask 0xfffffff0 broadcast 10.0.1.15
        inet6 fe80::28c:faff:fed6:f01d%re0_vlan10 prefixlen 64 scopeid 0x6
        inet6 2001:xxxx:yyyy:10::1 prefixlen 64
        groups: vlan
        vlan: 10 vlanproto: 802.1q vlanpcp: 0 parent interface: re0
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=121<PERFORMNUD,AUTO_LINKLOCAL,NO_DAD>

re0_vlan30: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        description: re0_0030_LANCLIENTS (lan)
        options=80000<LINKSTATE>
        ether 00:8c:fa:d6:f0:1d
        inet 192.168.0.1 netmask 0xffffffe0 broadcast 192.168.0.31
        inet6 fe80::28c:faff:fed6:f01d%re0_vlan30 prefixlen 64 scopeid 0xb
        inet6 2001:xxxx:yyyy:30::1 prefixlen 64
        groups: vlan
        vlan: 30 vlanproto: 802.1q vlanpcp: 0 parent interface: re0
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=121<PERFORMNUD,AUTO_LINKLOCAL,NO_DAD>


On the router advertisment page on my OPNsense GUI, I see from 24.1.10 a field source address with a drop-down box where Automatic is selected. But in the drop-down box I see only Automatic but no other options.
The field "source address" was not implemented in OPnsense 24.1 (or earlier).

When I change my SSD in the box with the old pfsense or OPNsense 24.1 router advertisement works like a charm.

I think the problem is with the source address on automatic option I see on 24.1.10 (and also in OPNsense 24.7.8/24.7.9).
How can I disable that box so that it works like 24.1 (or erlier)?
Or how can I a more options than only Automatic in the drop down box?

Can somebody help me?

Kind regards,

Himpie


Hi,

Why is the link-address changed from the normal IPv6 to the link local in versions after 24.1 in OPNsense?

I think it's not possible in my setup. I work with 1 NIC in my OPNsense box, all link-locals are the same ...

re0_vlan10: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        description: re0_0010_DMZSERVERS (opt1)
        options=80000<LINKSTATE>
        ether 00:8c:fa:d6:f0:1d
        inet 10.0.1.1 netmask 0xfffffff0 broadcast 10.0.1.15
        inet6 fe80::28c:faff:fed6:f01d%re0_vlan10 prefixlen 64 scopeid 0x6

re0_vlan30: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        description: re0_0030_LANCLIENTS (lan)
        options=80000<LINKSTATE>
        ether 00:8c:fa:d6:f0:1d
        inet 192.168.0.1 netmask 0xffffffe0 broadcast 192.168.0.31
        inet6 fe80::28c:faff:fed6:f01d%re0_vlan30 prefixlen 64 scopeid 0xb

It worked for the last 12 years on pfsense and opnsense before 24.1.x update (on 24.1 it works like in pfsense)

A link local is local to the scope of the interface.

You could have fe80::1/64 on each vlan.

thats why there is a % with the interface name behind each link local address.
Hardware:
DEC740

The subject on this post might be a little bit misleading, as I see it.

We recently migrated most of our branch offices from Cisco ASA to OPNsense (DEC3800 and DEC4200 series). Since the migration, we have struggled with managed IPv6 using ISC DHCP server. The reason for this is, that the OPNsense software puts the link local address into the link-address field in the relay-forward packet. Cisco and apparantly also pfSense however puts their globally scoped unicast address of the receiving interface into the link-address field. This is what both himpie and I are struggling with.

According to RFC 8415 section 19.1.1 it is always recommended, that the relay agent uses the GUA/ULA address of the receiving interface into the link-address field of the relay-forward packet, so that the DHCP server can easily do subnet selection.

There seems to be an alternative to this, if the relay agent adds option 18 (interface-id) to the relay-forward packet. OPNsense does that, but we didn't manage to get this to work with ISC DHCP server, that EOL'ed in 2022. Then we were very happy to see, that - according to the documentation - the ISC Kea DHCP server should be able to do subnet selection using the interface-id information from the relay-forward packet. Unfortunately, we haven't managed to get this to work either.

So it seems, we are left with two options here:

  • We could file a feature request for OPNsense.
  • We could start a support subscription for Kea at ISC and ask them for suggestions.

If anyone reading this have experience with OPNsense / Kea and are willing to share excerpts from a kea-dhcp6.conf with working subnet selection using the interface-id field, I would be very grateful.

Best regards
Ernst Mikkelsen

November 29, 2024, 01:15:33 PM #5 Last Edit: November 29, 2024, 01:39:30 PM by bimbar
NM, have you selected the "Agent Information" option? If so, try without it.

Configurability of dhcrelay is unfortunately limited, so opnsense mostly has to depend on it doing the right thing:

The options are as follows:

-d
Do not daemonize. If this option is specified, dhcrelay6 will run in the foreground and log to stderr.
-E enterprise-number
Choose the enterprise-number that will be used by the Remote-ID option (this only has effect when using -R).
-I interface-id
The interface-id relay agent information option value that dhcrelay6 should use on relayed packets. If this option is not specified, it will use the interface name by default.
Avoid using this option when using Lightweight DHCPv6 Relay Mode (layer 2 relay), otherwise dhcrelay6 will always send replies back to the client interface, which will break networks with multiple DHCPv6 layer 2 relay agents.

-i interface
The name of the network interface which will receive client DHCPv6 requests. For layer 3 mode at least one IPv6 local, site or global address has to be configured on this interface.
-l
Use the Lightweight DHCPv6 Relay Agent mode (layer 2 relaying).
-o
Add the Interface-ID option. This option is activated by default when using layer 2 relaying.
-R remote-id
Enable and add the specified Relay Agent remote-id to identify this relay segment.
-v
Debug mode. This option will make dhcrelay6 run in the foreground, log to stderr and show verbose messages.

If you need to solve this in KEA, it can be done via client classes like so:

"Dhcp6": {
    "client-classes": [
        {
            "name": "Client_enterprise",
            "test": "substring(option[1].hex,0,6) == 0x0002AABBCCDD",


You can test on pretty much any content of the packet: https://kea.readthedocs.io/en/kea-2.2.0/arm/classify.html

Hello bimbar

Thank you very much for your suggestions and sorry for not getting back before. It seems I do not get notifications on updates to this post.

The "Agent Information" only affects whether option 18 is added to the relay forward packet or not.

According to the key log, I have been able to make Client Classification to work by using a test like this "substring(relay6[-1].option[18].hex,0,9) == 0x766C616E302E313530"

However, I still haven't figured how to make the subnet selection part work, as I get a "Server could not select subnet for this client" error from kea.

I'll get back as soon as I have a new updates on this.

Best regards
Ernst Mikkelsen

So this is really about dhcrelay from OpenBSD not sending the correct agent information or client ID or whatever?


Cheers,
Franco