search

opnsense / core

OPNsense GUI, API and systems backend
https://opnsense.org/
BSD 2-Clause "Simplified" License
3.28k stars 729 forks source link

LAN interface tracking with manual adjustment and SLAAC-only WAN interface #7552

Open kevinchalet opened 3 months ago

kevinchalet commented 3 months ago

Hey everyone 👋🏻

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

Describe the bug

I have a scenario where my ISP (a mobile carrier) doesn't delegate a prefix via DHCPv6 (no IA-NA or IA-PD is returned even if you ask politely 🤣 ):

image

It does, however, announce a prefix in its RAs (well, two actually: one global and one local):

image

Configuring the WAN interface to use SLAAC (or DHCPv6) works fine and an address is correctly attached:

image

Unfortunately, using interface tracking on my LAN interface doesn't work correctly as no address is assigned:

image

image

(and since no address is attached to the LAN interface, the radvd configuration doesn't include the prefix announced in the RA:)

# Automatically generated, do not edit
# Generated RADVD config for manual assignment on lan
interface hn0 {
        AdvSendAdvert on;
        MinRtrAdvInterval 200;
        MaxRtrAdvInterval 600;
        AdvLinkMTU 1500;
        AdvDefaultPreference low;
        AdvManagedFlag off;
        AdvOtherConfigFlag on;
        DNSSL localdomain {
        };
};

While it's likely not a widespread scenario (I'd expect most ISPs to use IA-PD), it is my understanding after reading https://github.com/opnsense/core/issues/2394 that it should be supported by OPNsense. That said, that thread was opened 6 years ago and the related code has since changed quite a lot, so it's hard to determine whether something has regressed or if I'm just being stupid 😄

To Reproduce

Steps to reproduce the behavior:

  1. Configure a WAN interface to use SLAAC.
  2. Configure a LAN interface to use WAN interface tracking.

Environment

Software version used and hardware type if relevant, e.g.:

OPNsense 24.1.9_4-amd64 FreeBSD 13.2-RELEASE-p11 OpenSSL 3.0.14

Important note: it's a test machine that uses the vanilla 24.1.9_4 bits so it's unrelated to the (fantastic) changes made by @fichtner for https://github.com/opnsense/core/issues/5630.

kevinchalet commented 3 months ago

Interestingly, it works if I leave the Allow manual adjustment of DHCPv6 and Router Advertisements box unchecked (both the global and the local prefixes announced via ICMPv6 are attached and are added to radvd's config).

Sadly, this won't work for my scenario, as I need to able to override the default radvd settings (I need to use low as the priority 😄)

I'll update the title to reflect that.

fichtner commented 3 months ago

The SLAAC tracking was devised for a fringe use case with an Israeli ISP if I remember correctly. It’s possible to work on this again, but not before 24.7 is out.

Cheers, Franco

kevinchalet commented 3 months ago

Interestingly, it works if I leave the Allow manual adjustment of DHCPv6 and Router Advertisements box unchecked (both the global and the local prefixes announced via ICMPv6 are attached and are added to radvd's config).

I was a bit optimistic when I said it was working: an IPv6 address was indeed correctly assigned to the LAN interface and the machines on the LAN subnet were able to assign themselves an IPv6 GUA via SLAAC... but no communication using that prefix was possible: trying to ping an IPv6 server on Internet from a machine located in the LAN subnet would simply result in a timeout error.

Unfortunately, there's a "small" (🤣) detail I forgot: this scenario requires proxying neighbor advertisements for IPv6 packets to be correctly routed back to the sender... and it's not something OPNsense supports (as confirmed by https://forum.opnsense.org/index.php?topic=21795.msg105213#msg105213).

While it's likely not a widespread scenario (I'd expect most ISPs to use IA-PD), it is my understanding after reading https://github.com/opnsense/core/issues/2394 that it should be supported by OPNsense.

Amusingly, this is actually more common than I originally thought as it's the magic sauce used to make all tethering/mobile phone connection sharing scenarios work. And it's a standard thing: Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link (aka RFC7278).

The SLAAC tracking was devised for a fringe use case with an Israeli ISP if I remember correctly. It’s possible to work on this again, but not before 24.7 is out.

I don't want to discourage you from working on that post-24.7, but it seems much less trivial to implement than I anticipated, since fixing the address assignment would only be a tiny part of the story: it still wouldn't work without an NDP proxy/relay.

For completeness, RFC7278 doesn't seem to be supported by systemd-networkd - at least I wasn't able to make it work - but it works flawlessly on OpenWrt (I tested on both a VM and an ASUS TUF AX6000). For those interested, you only need to configure two things:

You need to update your WAN interface to set extendprefix to 1 (which basically treats the IPv6 prefix returned via ICMPv6 as a classical DHCPv6-delegated prefix you can assign to your LAN interfaces): ``` config interface 'lan' option device 'br-lan' option proto 'static' option ipaddr '10.1.150.5' option netmask '255.0.0.0' option ip6assign '64' option ip6ifaceid 'random' config interface 'wan' option proto 'dhcpv6' option device 'eth1' option extendprefix '1' option reqaddress 'try' option reqprefix 'auto' ``` You need to update your DHCP configuration to enable the NDP relay between the WAN and the LAN interfaces: ``` config dhcp 'lan' option interface 'lan' option start '100' option limit '150' option leasetime '12h' option dhcpv4 'server' option ra 'server' option ndp 'relay' option ndproxy_slave 1 option dhcpv6 'server' config dhcp 'wan' option interface 'wan' option ignore '1' option ndp 'relay' option master '1' ```

@fichtner since it's a mobile-first feature, maybe it's not a great fit for OPNsense. If you think so, please don't hesitate to close this ticket 😃

Skywalker-11 commented 3 months ago

Please correct me if I'm wrong but the Prefix Information (ICMPv6 Code 3) in your screenshot should only be used for on link traffic. That means devices that are directly connected to each other without a router in between. So your OPNsense should not be able to use that prefix on the LAN side.

If your ISP only provides a single public /64 prefix the 2a04.... prefix in your case the only viable solution might be to do IPv6-natting