Recent posts

#91

Hardware and Performance / Re: [solved] Intel i226 Firmwa...

Last post by BrandyWine - January 21, 2026, 09:59:57 PM

I find EFI version on NVM tool easier to use. Simply grab eeupdate64e.efi form Intel driver pack, boot into EFI shell and run command like:

Code Select Expand

eeupdate64e.efi /nic=1 /d=FXVL_125C_V_1MB_2.32.bin
You only specify nic number and name of NVM file to flash. No need to worry about configuration file.

What about doing a backup before it flashes, or just wanting to get NIC info, or create a log file. Does efi method do that?

#92

25.1, 25.4 Series / Re: Wireguard issue(s)

Last post by Dark-Sider - January 21, 2026, 09:56:50 PM

Thanks for your replies thus far! However it's not that simple (see below)

If your connection via wireguard is inbound, it means that your devices resolve the DNS entry. On your OPNsense, I would not expect any hostname in the configuration, wireguard just binds to all interfaces (* 51820).

So I assume your clients resolve the wrong IP address and send packets to the wrong destination.

It's not a road-warrior-only setup. The wg0 instance has also one outbound connection which resolves a dynamic hostname. My clients don't have any issues with the dns resolution of my wg-server, as I can just restart the service on my clients, reboot them or whatever. Usually it immediately starts to work, once I rest wireguard on the server. The issue I observed most recently was, that according to the wg-status-page in opnsense it was listening on a port 33### while the tunnel configuraton shows port 51820.

I wrote the stale connection job and of course, it only does half of the job...

Thanks Uwe for contributing to the project - didn't realize you were the author of this little helper :-)

In your scenario, with a road warrior, the cron job on the "server" side does not help at all, because the road warrior peer has to initiate a new connection. If he fails to notice the stale connection, it will never restart and thus the DynDNS update will go unnoticed.

Yes I fully get that, and that is not my issue tbh, since I just could restart a road-warrior-client while travelling. However restarting the server without a "dial-in" option is not possible. More on my analysis below.

Luckily, for M-Net, there is a fix to that: They usually do not change their IPv6 prefix on reconnection, much unlike the IPv4. Thus, if you use IPv6 only or IPv6 and IPv4 in your DynDNS, it will effectively work as if you have a fixed IP(v6). In that case, your roadwarrior clients will regain contact within the same Wireguard session.

I know they say they only change the IPv6 prefix after a set amount of "offline" time. A simple restart of my opnsense VM, only lasting <60sec triggers a new IPv6 prefix. But that's also fine, since reconnects don't happen that often...

Call me any time if you have questions, you have my number!

Yeah we can have a chat on the weekend, I'm very busy until friday (business trip).


As mentioned above, I did a bit more tinkering and thinking last night. As you all have mentioned, the road-warriors shouldn't have an issue connecting to the server as they have their own DNS-resolution. However the problem was not that the clients couldn't resolve my server (packets were arriving, checked with packed capture) but nothig was sent back. As described earlier, the wg-status page reported wg to run on port 33### which is not what is configured and I don't know where it pulled that port from. After restarting the wg-tunnel on the server everything worked fine, clients were online immediatly.

So I went ahead and restarted my opnSense VM (multiple times) - the result was always the same: wireguard worked fine for the roadwarriors, the other site2site box also connected after some offline time and with the help of the stale cron job. So, problem solved? Not quite.

It still bugged me why the wg service "failed" after the reboot a couple of days ago... Then it occured to me that I rebooted the opnSense VM because of issues with my DNS resolution. DHCP offers opnSense as DNS, and Unbound on opnSense uses my local pihole as an upstream host. I initially thought Unbound failed (which it does once a year or so) but the restart did NOT fix my DNS issue this time. It actually came down to pihole needing an update and restart.

So opnsense was rebooted without having a working DNS reachable, as opnSense exclusively uses my pihole for all its queries.

Since my local wg0 instance also has an outbound site2site connection which uses a dynamic hostname as the target it was not able to resolve that hostname after the system booted. In some other thread I read, that if wg DNS fails during startup the service might get stuck. Without having tested this further, I beleive that this is what happened to me. The hung service also does not accept any inbound connections, as the peers were not shown on the status page and wg0 was listening on the wrong port. When I'm back home I'll simulate this with a missing DNS server after rebooting opnSense and see if I run into the same issue.

TL;DR
- Clients never were an issue, they can easily be restarted to "update" any outdated hostnames, but server was not responding
- opnSense was rebooted without any DNS available, maybe wg didn't fully initialize, which als didn't allow clients to connect
- Stale connection script was successfully tested with my site2site connection, after running the script, the connection came back up.

#93

Hardware and Performance / Re: (Solved) Internet speeds r...

Last post by BrandyWine - January 21, 2026, 09:53:06 PM

So, I did a little more testing and replaced the Xfinity XB8 gateway with a Hitron CODA56. I'm not a fan of running ISP equipment especially Xfinity.

Well, perhaps you know or don't know, Xfinity hardware (cable boxes, extra outlet boxes) is transitioning to wifi6, later to wifi7, but they require the Xfinity wifi-modem to work. They use their own wifi-modem device to mux the wifi to cable, all in an effort to remove the requirement to have RG coax in every location and wired/split/amp'd correctly. They no longer offer the mini outlet box with RG (F) connection, it's now fully a 4kHD via wifi only. It's a brilliant idea, except for the reliance to use their wifi-modem.

#94

25.7, 25.10 Series / Re: Intel Thermal Sensor Virtu...

Last post by meyergru - January 21, 2026, 09:29:17 PM

None/ACPI means "ACPI only" - but ACPI is included on top of both the AMD and Intel core temp sensors, so if there is nothing shown with either one enabled, there will still be nothing with None/ACPI.

#95

25.7, 25.10 Series / Re: GeoIP list no more correct...

Last post by IPinfo - January 21, 2026, 08:56:32 PM

Our CSV database is RFC 4180 complaint and can be read using standard CSV parsing methods. We also provide NDJSON and Parquet formats. All formats are available to everyone for free.

If the ASN value is missing, it means the IP range is not announced in BGP tables and is not publicly accessible.


https://community.ipinfo.io/t/why-some-ip-addresses-dont-have-asn-data/7195

— Abdullah | DevRel, IPinfo

#96

25.7, 25.10 Series / Re: GeoIP list no more correct...

Last post by IPinfo - January 21, 2026, 08:50:06 PM

Hi,


I am following up here. I saw one ticket related to this thread in our support portal.

The data on our website is available directly in IPinfo Lite and in all our geolocation databases.

Since the user shared their home IP address, I cannot publicly go through the discovery process here. But we have been geolocating that IP address in Brussels since 2023.

First, check our website:

- ipinfo.io/<ip>
- Then you can also check our IPinfo Lite API service which enitrely built on top of the IPinfo Lite database: api.ipinfo.io/lookup/<ip>?token=<token>

Each row represents a block unaggregatable of the CIDR representation of IP address data.

https://community.ipinfo.io/t/understanding-range-aggregation-in-ipinfos-ip-databases/6528

Please, if you can share some IPs that I can look into to verify, that will be incredible. I am always happy to help.


— Abdullah | DevRel, IPinfo

#97

Hardware and Performance / Multi Threaded PPPOE For Multi...

Last post by jacknife - January 21, 2026, 07:49:21 PM

Hello I know about the ways to get PPPOE multi gig speeds with a VM of OPNsense, but I do not want that extra layer.

Is there a way I can do a feature request, or donate or something to help get this feature?

Absolutely love OPNsense, have a ton of servers relying on it.

#98

25.7, 25.10 Series / Re: Intel Thermal Sensor Virtu...

Last post by pfry - January 21, 2026, 07:45:13 PM

"None/ACPI" may be worth a try. I have a Gigabyte board that exports a bunch of sensors via ACPI, including some from add-in cards; my Asrock boards do not.

#99

General Discussion / Re: Can’t get the shaper on OP...

Last post by Seimus - January 21, 2026, 07:23:14 PM

I'm guessing that physical bandwidth below pipe bandwidth may mess with the scheduling.

You are correct. You can not shape BW you do not have.

Imagine for example where you have an ISP contracted WAN throughput of 10Mbit/s.
You set your Pipe to 10Mbit/s and split it using WFQ, you give 5Mbit/s to one Queue and 5 Mbit/s to other.

Now lets say the ISP given BW us highly variable and drops to 5Mbit/s. If one of those Queues goes full it technically eats all the real available BW at the time causing a partial starvation on the other. Because services like DNS are UDP based, packets are dropped without any mechanism to recover it. Thus you may get timeout for DNS.

Regards,
S.

#100

General Discussion / Re: Can’t get the shaper on OP...

Last post by mooh - January 21, 2026, 07:11:53 PM

Thanks guys, your discussion adds valuable information that helped me get my setup running (finally). But while experimenting with the settings I noticed something:

At a site with limited upload capacity, traffic from one network needs to be de-prioritised when other traffic is present. So, I added an upload pipe with the full nominal bandwidth to the ISP, added two weighted queues and the rules (great to have interface pairs in rules!). Generally, everything works as expected. Occasionally however, I get DNS resolution failures on the hi-prio networks while the low-prio network is uploading at full speed. This has not been observed before using traffic shaping. I'm not 100% sure what is going on. Shifting queue weights doesn't seem to do much to solve the issue. Latest test is to lower the pipe bandwidth to a few Mbits below the nominal bandwidth because the connection is via VDSL and the actual bandwidth is fluctuating somewhat. I'm guessing that physical bandwidth below pipe bandwidth may mess with the scheduling.

Since the DNS timeouts occur only sporadically, I can't be sure if this really fixes the issue. Has anyone else seen this and is there a know solution?