DS-Lite on 23.7.6+ (23.7.10_1)

[Maurice]

OPNsense has no delegated IPv6 prefix, no DNS servers and a SLAAC WAN address. Are you sure your ISP actually uses DHCPv6? You might want to check the log for dhcp6c.

Btw, the static IPv4 workaround is no longer required, DHCPv6-only WAN is now supported.

[DanAnimal]

OK, I think you're on to something. Thanks again.

If I reconfigure WAN to have IPv4 set to none and IPv6 set to SLAAC we get DNS servers in the Interfaces > Overview > WAN
(Seems really weird though that OpenWRT is set to DHCPv6 and it brings up the IPv6 interface with DNS and the tunnel seemingly without hesitation)

Reconfiguring the interfaces seems to get DS-Lite to come up too.

But if I reboot with SLAAC configured, DS-Lite does not come up and we have no connection (I don't know why IPv6 on it's own doesn't work).

[DanAnimal]

Ah... OpenWRT somehow includes SLAAC for interfaces set as DHCPv6
https://openwrt.org/docs/guide-user/network/ipv6/configuration

So I guess between that and what we saw from OPNsense with WAN set as SLAAC, that my ISP is actually using SLAAC.

Would you agree?

[Maurice]

Some ISPs use SLAAC for letting the router autoconfigure a WAN address. This seems to be the case here. But DHCPv6 is still required for prefix delegation (and autoconfiguring DS-Lite on consumer routers). So it seems unlikely that your ISP doesn't use DHCPv6 at all. I'd increase the dhcp6c log level to see what's actually going on, and / or perform a packet capture.

With your current setup involving the OpenWrt "shim", how did you get IPv6 working in the OPNsense LAN(s)? Does OpenWrt acquire a prefix from your ISP and perform downstream prefix delegation to OPNsense?

[DanAnimal]

Sorry I've been absent Maurice.

I don't use IPv6 inside my LAN so I'm not sure.

I updated my test device to 24.1.2 and while the failure to establish the DS-Lite connection continues resolving it now does not happen by disconnecting the WAN and reconnecting it. But rather by disconnecting the DS-Lite interface  and reconnecting it.

I also noticed that there's something going on with the dhcp6 server seemingly in concert with the DS-Lite tunnel's connection.

I captured a slab of logs from boot through restarting the interfaces until DS-Lite was active in case they can be diagnostic. But this forum will not let me post that much text.

[jbourne]

Adding to this thread since I am trying to do the same thing, but I have a somewhat different issue with the GIF tunnels. I am configuring the GIF tunnel using 192.0.0.1 as remote, 192.0.0.2 as local, but when I save, the logs get the following error:

<13>1 2024-04-23T21:19:35+09:00 opnSense.localdomain.com opnsense-devel 53233 - [meta sequenceId="43"] /usr/local/etc/rc.newwanipv6: Device gif0 missing required local address, skipping now.

Weirdly, if I set it manually using the info from DanAnimal's thread from a couple of years ago,

- 2001:f74 is the IP that is allocated to opnSense by the NEC ONU device (from ifconfig)
- 2001:f60 is the AFTR address of dgw.xpass.jp - the ISP to whom the link goes

Code Select Expand

ifconfig gif0 inet6 tunnel 2001:f74:xxx:xxx:xxx:xxx:xxx:xxx 2001:f60:0:200::1:1 mtu 1460 -accept_rtadv ifdisabled
ifconfig gif0 inet 192.0.0.2 192.0.0.1 netmask 255.255.255.248
route add default -interface gif0


If I do this, it immediately begins working (but, of course, does not survive a reboot).

I did everything else as posted in the above post, but I think I am stuck on this "gif0 missing required local address". Would anyone know what's going on here, or what can I post?

I am on OPNsense 24.7.a_388-amd64.

[Maurice]

As far as I remember, "gif0 missing required local address" means the interface you selected as the parent interface doesn't have a valid IPv6 address. How is 2001:f74:xxx:xxx:xxx:xxx:xxx:xxx assigned to the WAN interface? SLAAC? DHCPv6?

[jbourne]

Ooh, that is interesting. Indeed, I don't have one assigned - the LAN side gets one via Track Interface (and it's actually the same IP that the _WAN_ side was getting when I was running OpenWRT), but for some reason WAN doesn't. It's supposed to be DHCPv6, but as DanAnimal found above, there's some weirdness about how the provider does it - there seems to be SLAAC involved but setting WAN interface to SLAAC makes connectivity fail completely. I currently have it set to DHCPv6, I do _not_ have "request prefix only" checked, and its working - WAN interface is unassigned, LAN interface has the correct IP.. It's almost as if the IP is being assigned to the LAN side _instead_ of WAN. How can I try to fix this?

[Maurice]

DanAnimal did have a SLAAC WAN address, but you don't seem to have a WAN address at all. It's possible that your ISP supports DHCPv6 Prefix Delegation (which is used for the LANs), but doesn't assign a WAN address (no DHCPv6 IA_NA, no SLAAC). Unfortunately, OPNsense can't use the delegated prefix for creating a WAN address - the WAN interface can't track itself. OpenWrt might support this (not sure), this might be the reason why you had a WAN address there.

Does your delegated prefix change frequently? If not, you could add a virtual IP to the WAN interface. What prefix length do you get?
You'll really have to dig deeper there. Check the DHCPv6 logs, perform a packet capture, look at RAs. Very few people here (if any) will have a deeper understanding of how Japanese ISPs do things. You could try the Japanese forum, but it's essentially dead.

[jbourne]

Sadly, you're quite right - nobody really knows how things are done in Japan (believe me, not just ISPs :D). My /56 never changes - I'm sure it's "dynamic" but it's quite sticky. I don't mind assigning an IP manually even if I have to put a PostIt note to "in case of outage, check subnet" - but is it a question of just setting to static IP from the same /56, or assigning a fake one, or what should I try?

[Maurice]

Most ISPs require you to frequently renew your Prefix Delegation via DHCPv6, even if it rarely or never changes. If you don't, it eventually expires. So the WAN interface should be set to DHCPv6.

If you get a /56 which (almost) never changes, but don't get a WAN interface address at all, try this:

Let's say your delegated prefix is 2001:db8:abcd:ef00::/56.
Go to Interfaces: Virtual IPs: Settings, add an address, interface WAN, address 2001:db8:abcd:ef00::1/128.

If one of your LAN interfaces uses the IPv6 Prefix ID 0 and you don't want to change this, you can use a different one for the WAN, like 2001:db8:abcd:efff::1/128.

[jbourne]

Thanks very much. Tried this, and it did configure an IP for my ix0 WAN side:

Code Select Expand


ix0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1460
        description: WAN (wan)
        options=4803828<VLAN_MTU,JUMBO_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC,NOMAP>
        ether ac:bd:ca:fe:de:ad
        inet 127.0.0.2 netmask 0xffffffff broadcast 127.0.0.2
        inet6 fe80::9e69:b4ff:fe63:6437%ix0 prefixlen 64 scopeid 0x2
        inet6 2001:f74:xxxx:yyyy:zzzz:aaaa:dead:cafe prefixlen 128
        media: Ethernet autoselect (10Gbase-T <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>



But sadly, gif0 did not come up - even tried rebooting, but still got the same error about missing required local address. Went back to the settings and tried to save, and same error.

Is there any way to stuff the gif0 script into /usr/local/etc/rc.syshook.d/start/ or something? I don't mind hacking this in a less-than-beautiful way as long as it works (I do have an ipsec tunnel that needs to come up, though - and currently, because gif0 doesn't come up, ipsec is forever idle, so if I do a manual hack, it would need to be in the boot process after ix0 comes up but before ipsec does).

[Maurice]

It's possible that we don't allow the gif source address to be an IP alias, not sure. I'll try to find out and will report back. If so, we might want to fix this.

But the best solution would still be to allow a WAN interface to track itself. This has been requested and discussed before, but turned out to be harder than expected (as far as I remember). Since "PD only" doesn't seem to be that rare and a WAN interface without a GUA is such a pita, this might deserve another attempt.

By the way, the dummy IPv4 address shouldn't be required anymore, "none" is fine. The bug that made this necessary has long been fixed.

[jbourne]

Understood, thanks. I'm going to guess that with all the stuff yall have to do, pandering to weird Japanese setups isn't going to be _too_ high on the list, hehe ... Is there anything I can do in the meantime as far as a manual hack goes? I suppose I could write some kind of a script that runs as a cron job or something, but ideally I want to just patch into the boot process somewhere.

[edit] browsing through forums, I came across a, what I think, was a similar issue:
https://forum.opnsense.org/index.php?topic=35876.0

and there was a patch issued,
https://github.com/opnsense/core/commit/315153a07

Was this ever deployed into subsequent releases? I looked through src/etc/inc/interfaces.inc and I don't think I see the code referenced in that patch, and it's for an older version, so I don't know if I should risk it or not.

[edit] one more edit. i managed to make it come up on boot by editing 10-newwanip, adding a sleep timer of 30 seconds (to allow WAN to come up), doing the gif config, and then adding a new script all the way at the end of the boot, doing another 10 second sleep, and adding a configctl service restart strongswan to restart the IPSec tunnel. This survived the last two reboots, so it might be an OK hack at the moment. :)

[franco]

The code on master branch was changed slightly, but 24.1.x still has the adjusted code from that commit. And the master branch changes are cosmetic just for the MVC/API conversion of the GUI parts of GIF and GRE.

I'll note again that SLAAC is problematic being stateless which also means nothing tracks its state in the system so addresses come and go at no notice and finding a trigger here is difficult. Netlink may provide help here but it would still require a daemon or cron job to be executed figuring all this out what to do (reload, flush stale addresses, which interfaces to look at even).


Cheers,
Franco