Messages

Please have a look here: https://forum.opnsense.org/index.php?topic=36139.0

There's a microcode update needed for the N100 CPUs running FreeBSD.

# pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg

Reboot and try again.

Cheers,
Franco

24hrs uptime here and still keeping the WAN IP6 lease after applying the fix to 24.1.9_4. Thanks @franco and team!

Here are mine, it appears to grab an address and then almost immediately release it for WAN. It does hold on to the prefix delegation and that doesn't change even though the WAN IP6 doesn't seem to stick.

The logs are too large to paste here in the thread so I'm just attaching them for review. I've segmented them in to the initial bootup log, and the first renewal attempt.

I'm on 24.1.9_3 and am also seeing this behavior for my WAN IPv6, it loses its IPv6 lease a few hours after a reboot.

The LAN still maintains its IPv6 address and is still handing out working IPv6 leases to my LAN clients. Prior to 24.1.9 I used WAN Track interface and had solid IPv6 for years on my LAN and the WAN interface always had its own IPv6 assigned from the ISP. I'm happy to also provide logs but I'm not sure which ones?

Screenshot attached showing the lack of a WAN IPv6 address but LAN still has it.

I find the list in the video odd and frankly, half hearted at best. It seems selected to bias a result rather than an open ended look at what each solution offers.

Once OPNsense updates to 14.x most of the stuff in his video will be moot anyway and that's just a few weeks away. Meanwhile Tom is failing to mention that OPNsense went to FreeBSD 13.x YEARS ago while pfSense was stuck on 12.x. Where were all the videos then when it was pfSense being the laggard and OPNsense using the modern base?

Also there's no mention of the features that pfSense just flat out can't do. pfSense has a long standing bug (~10 years old) that won't allow DHCP leases to register their DNS records without completely restarting Unbound and flushing all of the DNS cache. OPNsense has had this resolved for a long time now. pfSense just keeps perpetually kicking it down the road. https://redmine.pfsense.org/issues/5413

OPNsense Unbound reporting is freaking awesome! I use it constantly and its a great troubleshooting tool, plus another nice way to see what clients on the network are trying to resolve in realtime. Its quickly turned in to one of those nice to haves that I can't live without. I can't find this function built in to any other open source firewall solution out there.

OPNsense also had local Insight (netflow) reporting for years. Having this data stored and graphed locally on the firewall itself without having to setup a separate netflow receiver and graphing server is super handy to have. I'm not aware of any other firewall solution that does this out of the box with minimal setup, basically check a few boxes and you've got netflow graphing.

Stuff like this is why OPNsense is such an obvious choice for most folks. The nicer community and lack of internet shenanigans is just a bonus as far as I'm concerned.

Nice work finding the cause and yes, this is what I was talking about in reference to HP servers. They allow their lights out functions (remote management) to move around the physical integrated NICs and sometimes this causes confusion. Seems Asrock has this feature as well.

That all seems logical and correct.

The phantom MAC that is stealing the WAN IP, does that MAC coincide with the IPMI interface? I'd want to be extra sure that isn't somehow popping up on the NIC that proxmox is using for the WAN bridge and causing all kinds of issues. I know this is apples/oranges but some newer HP server hardware allows the lights out functionality "move" around to different NICs, so I'm not sure if Asrock has a similar function or not?

The other odd issue that might be worth checking is newer mainboard BIOS' have the option for "install drivers" or some such feature. This usually involves the BIOS UEFI firmware pulling an IP address and trying to stage drivers through to the OS. If your mainboard has such a feature I would suggest turning it off and see if this may also be using that ENO1 NIC for those attempts. This is a long shot but I'm just thinking out loud here trying to help narrow down possibilities.

How is proxmox configured for the OPNsense NICs? Are you using direct hardware passthrough or is there a virtual switch with virtual interfaces assigned to the OPNsense VM?

If it's using a virtual switch, is there another device on the OPNsense WAN side that is 'stealing' the DHCP address?

What do the logs say? This seems like a DHCP lease expiring on WAN and not renewing until the interface is force reloaded.

Is there anything in System/Log Files/General around the timeframe that the WAN link becomes unresponsive?

There was a fix in Unbound 1.20.0 for a restart-related issue reported to them by a community member. It's in today's 24.1.7.


Cheers,
Franco

Thanks Franco!

i noticed this as well running quad 9 in DOT.

i went back to just unbound for a few days and have not had any issues.

i am on business so i guess ill get the patch a little later .

reports are not the end of the world for me

I forgot to mention this above but I tried switching from Quad9 DoT to CloudFlare DoT, and it was still randomly stopping for me. However I did not try to fall back on standard unencrypted DNS.

I've used the DNS Reporting feature since it launched in OPNsense. Awesome feature!

However I've noticed with the latest update it is now randomly stopping for me. Anywhere between 24 to 72hrs the reporting will just cease to have any new results. I don't see anything in the Unbound log or system log that correlates to the time when the Unbound reporting stops. Is anyone else seeing this behavior?

Information on my use case:
I am not using any DNS blocklists.
I am using Quad9 DNS with DoT

Steps I've tried so far:
Restarting Unbound service, this temporarily restores reporting but it will stop again randomly
Disabling, resetting, and then re-enabling the Unbound reporting function

I do have shared forwarding enabled.

I've noticed something similar with my fiber provider. I think the issue is the provider's PD doesn't have a valid monitor address or has high packet loss. For instance, if I leave gateway monitoring enabled for my IPV6 WAN route I can see a high level of packet loss come and go just on the fe80% IP that gets discovered during the ISP handing out the PD.

This resolved my issue and resulted in stable IPv6. Again I'll caution that these settings might not be for everyone but this is what fixed my issue with some trial/error.

First you'll need to go to system/gateways/configuration and edit the WAN DHCP6 gateway. By default OPNsense has gateway monitoring disabled, enable it and you'll want to set a known good WAN IPv6 IP address. I like to use DNS servers like CloudFlare, Google, or Quad9 since they are anycast and always reachable if the WAN is up. I've attached a screenshot showing how I've configured my IPv6 WAN gateway.

I would also recommend doing something similar with your WAN_DHCP ipv4 gateway if you haven't already. It's okay to leave that IP to the ISP assigned WAN gateway (leave it blank and it will use the ISP gateway) as that usually always works. Enabling gateway monitoring for both of these will give you the "quality" graphs under Reporting/Health/Quality. Not only will you be able to see your average ping time across both gateways but you'll also be able to check if you're getting packet loss, which is quite handy.

Try these and see if your ipv6 stabilizes.

Based on the dmesg it looks like igc0 is up/down quite a bit? Is that interface negotiating at the right speed? Maybe worth double checking the cable there just to rule out a physical issue?

Screenshot for the gateway monitor