Hi,
i just installed 24.7. It is a new build with a history of only two weeks.
So far the update process was very smooth and the important stuff (my work network) is working.
I see only one thing that seems to behave different to the previous version. On the WAN interface i configured IPv4 using a static IP and IPv6 using DHCPv6.
Both have a gateway that monitors the connection. With version 24.7 the gateway for the DHCPv6 configuration is shown disconnected in the Web-GUI. But if i ssh into the router and ping6 the monitor IP it works.
It seems to have something to do with the priorities of the gateways.
I made a mistake with the priority of the IPv4 gateway on the same interface. I used a differnt (lower) priority there. After adjusting the value to the same as the DHCPv6 gateway both gateways are shown as connected.
I still don't understand the root cause but at least my configuration is slightly more correct now.
After a failover to the secondary WAN which has no IPv6 and switching back to the primary WAN the DHCPv6 gateway is shown as disconnected again.
Somehow it looks like there is a status update missing.
It looks like the "Gateway Monitor" service for the DHCP6 gateway was not running. I missed it because the new dashboard does not show the services in the default configuration.
After a restart of the service the gateway is green again.
I am still not sure why the service was not running from the start. At least before the failover i see no reason because there should have been IPv6 connectivity.
I have a similar problem (https://forum.opnsense.org/index.php?topic=41721.0) and after reading your postings fiddled around with priority of IPv4 and IPv6 gateway. Result: both gateways came up (CF DNS servers as Monitor IPs, because Telekom does filter ICMP on the actual gateways). But after a reboot IPv6 gateway is offline again while IPv4 is up.
Hm, I found something. In my case adding a monitoring IP for IPv6 does NOT lead to a route creation for that respective address through the IPV6 WAN interface while for IPv4 it does. In 1 out of 10 attempts a route was created and voila: the IPv6 gateway was online. After the reboot the route was missing so gw was offline again.
FWIW, I agree that the services widget should be a dashboard default because otherwise this is harder to catch than necessary.
Cheers,
Franco
I just updated to version 24.7_5. Now the DHCP6 gateway monitor service is always off. I can't activate it anymore from the dashboard.
The systen general log shows the following entry:
"Warning opnsense /usr/local/sbin/pluginctl: The required GW_WAN1_DHCP6 IPv6 interface address could not be found, skipping."
After finishing the previous post the gateway monitor was working again. It looks like it just takes some time after a reboot to get active.
Could you please check with a Monitor IP on the Internet (e.g. DNS Servers) and see if the respective Host Routes are put into the routing table for IPv4 and IPv6?
Well. The DHCP6 gateway has a internet monitor IP (2606:4700:4700::1111).
Currently it is working and the routing table contains the following:
ipv6 default <IP6 of my fritzbox as gateway address> UG NaN 1500 igc3 WAN1
ipv6 2606:4700:4700::1111 <IP6 of my fritzbox as gateway address> UGHS NaN 1500 igc3 WAN1
The IPv4 route is also available.
I am a little bit hesitant to reboot the router at the moment. Therefore i can not check the table in case of a problem.
I see. If that second IPv6 route is set automatically (incl. after a reboot) then it's fine. For me that did not work so far while IPv4 Host route was set up just fine.
Quote from: MenschAergereDichNicht on July 26, 2024, 10:51:28 AM
Well. The DHCP6 gateway has a internet monitor IP (2606:4700:4700::1111).
Currently it is working and the routing table contains the following:
ipv6 default <IP6 of my fritzbox as gateway address> UG NaN 1500 igc3 WAN1
ipv6 2606:4700:4700::1111 <IP6 of my fritzbox as gateway address> UGHS NaN 1500 igc3 WAN1
I happen to also use CF DNS for IPv6 gateway check. I just tested after upgrading to version 24.7_5, and the error persists, so no Host Route to 2606:4700:4700::1111 is inserted into the routing table, so as a consequence the gw check fails. IPv4 is fine.
It looks like there is a behaviour change in regard to DHCPv6 handling with version 24.7 .
In my case it seems to be timing related (a few minutes after a reboot i can manually start the gateway monitor).
I don't exactly know the role of the "gateway monitor watcher" but if i go by the name the manual start should not be necessary.
Update: At least i *think* that it is timing related. I also edited the gateway configuration between several tries to start the gateway service (i tried to manually enter the gateway IP6 and than removed it again). I did not check if my editing somehow created the route. I guess i will see it on the next reboot... .
Quote from: MenschAergereDichNicht on July 26, 2024, 11:37:56 AM
It looks like there is a behaviour change in regard to DHCPv6 handling with version 24.7 .
In my case it seems to be timing related (a few minutes after a reboot i can manually start the gateway monitor).
I just noticed you have a point that I can confirm. I noticed that indeed the Gateway Monitor dpinger service for IPv6 was NOT running and I could start it manually after some time. As soon as I did that the IPv6 route was inserted into the routing table. So, my observation was rather a symptom and not the cause!
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 .
Update: I changed my DHCPv6 configuration on the WAN interface to "Request prefix only". Now the dpinger starts right away.
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
@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
@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.
Quote from: tokade on July 26, 2024, 04:25:36 PM
@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 (https://docs.opnsense.org/manual/how-tos/ipv6_dsl.html). The other config had just worked flawlessly until 24.7 but maybe was not valid before that.
Quote from: Chaosphere64 on July 26, 2024, 05:03:25 PM
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.
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
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263986) still exists?
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.
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
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
@Franco
With which IPv6 configuration for the WAN interface should this patch be tested?
- DHCPv6 with or without selected "Request Prefix only"
- PPPOeV6
- SLAAC
The patch is relevant for all functional WAN IPv6 modes except SLAAC.
Cheers,
Franco
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 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
Quote from: franco on July 27, 2024, 10:06:27 AM
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.
inet6 fd9c:85da:835d:8696:92e2:baff:feb0:efeb prefixlen 64 detached autoconf pltime 1800 vltime 1800
Quote from: tokade on July 27, 2024, 08:26:49 PM
One more hint, in CLI the WAN interface doesn't show any IPv6 address at all.
How exactly are you checking? ifconfig? With a common DTAG line the WAN interface is pppoe0.
Hi Franco, hi Patrick,
sorry for the confusing statement. ifconfig shows the automatically assigned and the VIP address in the CLI as described. The automatically assigned one is shown as detached.
What was meant was that after logging on to the CLI, only the IPv4 is displayed in the overview of interfaces for the WAN interface and no IPv6.
Incidentally, the gatway and the monitoring have been running stably since yesterday evening. However, I have not yet rebooted to see if this changes the configuration of the WAN_DHCP6 gateway.
Good morning,
I did a reboot meanwhile, the gateway settings are retained. gateway is shown online and the monitoring works. I'm still not sure, if this workaround with the VIP Ipv6 address in the gateway config is ok or not.
Also no idea why the automatic assigned IPv6 is detached, which maybe the reason that the gateway is offline / monitoring doesn't work.
If I can provide any logs let me know.
Stupid question: Is patch 287c13beb still necessary to apply if one installs 24.7_9?
I've been waiting a bit to upgrade to 24.7, but as I do a fair bit with IPv6, was watching this thread closely. I'll probably be waiting a few more days before doing any installations anyway, but, wasn't sure if this patch is already included in one of the Hotfixes or not.
> Stupid question: Is patch 287c13beb still necessary to apply if one installs 24.7_9?
Not a stupid question. Yes, 287c13beb must be reinstalled, but I'm 95% sure it will be included in 24.7.1.
Since we have some kernel issues with FreeBSD 14.1 as is I'd recommend waiting for 24.7.1 which will ship a new kernel and getting confirmation that the upgrade path points to it as well as that will take a day more than the initial 24.7.1 release announcement and you can't see that from the upgrade changelog for technical reasons.
Cheers,
Franco
Is this still a known issue? I'm on 25.1.8 and have the same problem.
I get a static IPv4 address and IPv6 prefix from my provider.
My WAN settings:
IPv4 Configuration Type: PPPoE
IPv6 Configuration Type: DHCPv6
Request prefix only & Send prefix hint are both checked
Clients are able to connect to websites via IPv6 and my servers are reachable via IPv6 from the internet. Also IPv6 Ping via Interfaces > Diagnotics is working.
But if I want to Enable Gateway Monitoring the gateway is "Offline" and the Gateway monitor isn't starting with this error in the log: /usr/local/etc/rc.syshook.d/monitor/20-recover: The required WAN_DHCP6 IPv6 interface address could not be found, skipping.
Routes are there:
ipv6 default fe80::ded2:fcff:fe24:dd60%pppoe0 UGS NaN 1492 pppoe0 WAN
ipv6 2606:4700:4700::1111 fe80::ded2:fcff:fe24:dd60%pppoe0 UGHS NaN 1492 pppoe0 WAN
I also tried the give the gateway an IPv6 address from within my prefix without luck. If I uncheck "Request prefix only" the gateway still gets an fe80 address.