[SOLVED] DHCP6 Gateway is shown as disconnected in 24.7

[MenschAergereDichNicht]

It seems that the behaviour i was seeing was produced by a configuration failure that surfaced with the new version.

I was preparing the switch to a different primary WAN interface (WAN0; a Vlan on the same interface as my current primary WAN) which is about to replace my current primary WAN (WAN1).
After the configuration i deactivated the interface to ensure that it does not interfere with my current setup.
My only IPv6 capable interface WLAN is configured to use "track interface". And as a tracking target i use the current WAN interface.  At that time it was WAN0. After the deactivation of WAN0 the WLAN tracking interface was not changed to WAN1.

Long story short. After changing the tracking interface in the WLAN configuration the gateway check seems to work even after a reboot.

This bug in my configuration did not show up in the previous OPNsense version. I really like this improvement and feel even more confident using OPNsense 24.7 .

[guest34985]

Update: I changed my DHCPv6 configuration on the WAN interface to "Request prefix only". Now the dpinger starts right away.

[franco]

Might be related to giving SLAAC addresses lower priority making them disappear for an arbitrary amount of time before returning: https://github.com/opnsense/core/issues/7400#issuecomment-2252297505

Then again these SLAAC addresses were never really reliable in DHCPv6 mode.


Cheers,
Franco

[tokade]

@Chaosphere64
Does your WAN interface get an IPv6 assigned automatically with your configuration or do you set an address manually, which is used for dpinger?

@Franco
I can't agree that the SLAAC addresses were never really reliable in DHCPv6 mode. At least not for my ISP Deutsche Telekom business with a static IP and till release 24.1.9

[franco]

@tokade

When I say not reliabe I mean for the people who have severe issues with it. There's no way to detect when this is wrong so we need to find a solution that fits everyone and this was it. Maybe not perfect yet, but if we don't anything we never get better at that.

[guest34985]

@Chaosphere64
Does your WAN interface get an IPv6 assigned automatically with your configuration or do you set an address manually, which is used for dpinger?

The WAN interface had instantly gotten a separate IPv6 (meaning outside the delegated IPv6 prefix) when "Request prefix only" was unselected, like you would expect. dpinger would not work right away but could be started after a certain amount of time.
After selecting the option dpinger starts instantly while the interface has just its fe80::/10 address. After some time the interface also holds a GUA, which again is outside the delegated IPv6 prefix.

I would have guessed that the interface generates an address from within the prefix but that's not how it works with Telekom FTTH. Meanwhile I have learned that my current configuration is exactly what the OPNsense documentation suggests for my provider. The other config had just worked flawlessly until 24.7 but maybe was not valid before that.

[tokade]

After selecting the option dpinger starts instantly while the interface has just its fe80::/10 address. After some time the interface also holds a GUA, which again is outside the delegated IPv6 prefix.

I will try that configuration, maybe I was too impatient waiting for a GUA.

For Telekom you find in the "Business Kundencenter" following:
IPv6 (Öffentlich/WAN):2003:000a:XXXX:ff1f:0000:0000:0000:0000/64   
IPv6 (Kundennetz/LAN):2003:000a:XXXX:1f00:0000:0000:0000:0000/56

So the delegated IPv6 should be an address out of the WAN/64, which is true for my installation.

[tokade]

Even after almost 5 hours the IPv6 address on my WAN interface is still detached and dpinger doesn't work.
Might this bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263986
still exists?

[MenschAergereDichNicht]

I have a setup with a Fritzbox (german internet+wlan router) in front of a OPNsense box.

I also use an ULA.

And here the gateway monitor is working. So i guess there is no general problem with 2 routers.

[RedVortex]

I use 2 providers for IPv6

Starlink (DHCPv6) and Hurricane Electric (GIF tunnel).

After reboot, I have an IPv6 on both interface but gateway monitoring (dpinger) is not enabled on any of the ipv6 interfaces so both interfaces are marked as down. All IPv4 gateways are ok and dpinger is running for them, only IPv6 are affected.

I can manually start dpinger on both gatways and then they get marked as up and dpinger continues to run.

If I reboot, the same situation happens again. It also happens if I go on the interface of Starlink and click save to refresh IPs. Seems dpinger gets disabled while the interface flaps but it never gets re-enabled automatically unless I manually start it.

This is a new behaviour since I upgraded to 24.7, this was working fine in 24.1

[franco]

Maybe this also:

https://github.com/opnsense/core/commit/287c13beb

# opnsense-patch 287c13beb

I find it ironic that I can't trust my native IPv6 setup anymore when working on IPv6 as it shows no oddities but in the real world all sorts of strange things are happening.


Cheers,
Franco

[tokade]

@Franco
With which IPv6 configuration for the WAN interface should this patch be tested?
- DHCPv6 with or without selected "Request Prefix only"
- PPPOeV6
- SLAAC

[franco]

The patch is relevant for all functional WAN IPv6 modes except SLAAC.


Cheers,
Franco

[tokade]

Hi Franco,

I did further tests after applying the patch and a reboot. There is nothing better and nothing worth in my installation (Deutsche Telelkom business static IP). Everything with IPv6 is working only the gateway monitoring still didn't work.

Using DHCPv6 without selecting "Request Prefix only" results in
- WAN getting assigned an IPv6 address from my WAN net (/64) automatically, but still showed as detached in CLI
- WAN getting assigned the configured VIP IPv6 from my WAN net (/64) and shown in the GUI
- WAN_DHCP6 gateway is generated automatically with the automatically assigned gateway (fe80...) and it shows in the GUI offline (monitoring activated). Restarting dpinger, saving the gateway with changed selections etc. doesn't change anything
- LAN and other interfaces get there static IPv6
- IPv6 traffic works (pings to outside, my website is reachable via IPv6,...)

In CLI I can ping the IPv6 address used for gateway monitoring only via the VIP. Using the automatically assigned but detached IPv6 as source results in an error message

Code: [Select]

ping: bind: Can't assign requested address
This brought me to the idea to change the automatically assigned IP address for the gateway in the configuration to the VIP I configured for the WAN interface. And after saving the monitoring works as expected and the gateway is shown as online. 

One more hint, in CLI the WAN interface doesn't show any IPv6 address at all.

I dont't know if this kind of gateway configuration is completely bullshit, but maybe this information will help you to find out what is missing or maybe need some configuration changes.

If it is better to open a new post, let me know

Torsten

[RedVortex]

https://github.com/opnsense/core/commit/287c13beb

# opnsense-patch 287c13beb

That seems to have helped for Starlink, problem remains to Hurricane Electric GIF tunnel.

I patched, and rebooted 2 times and both times the dpinger for Starlink was up and monitoring. I removed the patch, rebooted a 3rd time and I saw dpinger started on startup and then stopped and did not restart by itself. I then proceeded to enable manually and it remained up.

I wonder if this could also be related to a problem I started having on 24.1 in the very latest updates. After reboot I see a weird IPv6 assigned to the interface (ULA fd9c:xxxxxxxx) where I have my Google Homes. As if the interface would get itself an IPv6 from somewhere. The IPv6 configuration on the interface is "None" so I would not expect the interface to end up having an IPv6 in any way, ever. I wonder if something like SLAAC is enabled at all times now or something like that even though IPv6 is not enabled on the interface.

I need to manually remove the ULA IPv6 from the interface or put the interface in DHCPv6, save/apply, then go back to None and save/apply to get rid of the IPv6 address on the interface. This situation also prevents Unbound from starting, it remains off until I get rid of this IPv6 or remove the interface from the Unbound list of bounded interfaces.

I know this sounds like outside this thread but since it affects IPv6 only and we're talking about weird SLAAC issues, I prefer to let you know about this as well in case it is related or it helps.

EDIT1: Added info to specify that the weird IPv6 I'm getting in an interface is FD9C:xxx which is a ULA IPv6, probably some device created its own ipv6 network and is broadcasting it. Not sure why OpnSense uses it though since I have IPV6 configured to none on the interface. But this definitely prevents Unbound from starting.

EDIT2: It really seems like it is a RA coming from my Google Home devices or Unifi AP maybe and opnsense picks it up by autoconf. Something must have changed recently (likely kernel) that now autoconf ipv6 even if disabled.

Code: [Select]

inet6 fd9c:85da:835d:8696:92e2:baff:feb0:efeb prefixlen 64 detached autoconf pltime 1800 vltime 1800