Recent posts

#1

General Discussion / Re: Please Make a Donation to ...

Last post by unixpgmr - Today at 03:43:38 AM

Why do I have to create a Paypal account to make a monthly donation via credit card?

To safe the OPNsense Team some money that would otherwise be lost on having a subscription with a company that handles Credit Card Payments I am guessing... ?! :)

However, if I make a single donation, I don't have to create a paypal account. It only applies to a recurring donation.

#2

26.7, 26.10 Series / Re: No link with Intel E810 on...

Last post by redge - Today at 01:26:54 AM

I don't have any further insight or experience to contribute at this stage, but what module coding and link partners have been tested? We don't have a non-production DEC appliance, but we do have DACs, AOCs, and SR/LR SFP28 modules on hand that we can recode at will, so if there's a specific combination that hasn't been tested (or needs validation) I might be able to provide another test case.

This seems to be the culprit: https://github.com/opnsense/src/commit/27ffeba0e6b5b8d8ebb8eec9d2566f56421ee946

There's a test kernel available if you want to give it a go:

# opnsense-update -zkr 26.7.8-next

Reboot afterwards, link should come up immediately on boot without the tunable.

Yup, that seems to have done the trick! Updated the kernel, removed the FEC tunables from ice0/ice1, rebooted, and the link came up with no intervention, exactly as expected.

Code Select Expand

[1] ice0: Link is up, 25 Gbps Full Duplex, Requested FEC: RS-FEC, Negotiated FEC: FC-FEC/BASE-R, Autoneg: False, Flow Control: None
...
[3] ice1: Link is up, 25 Gbps Full Duplex, Requested FEC: RS-FEC, Negotiated FEC: FC-FEC/BASE-R, Autoneg: False, Flow Control: None

Skimming dmesg, I did notice a few VLAN errors on those NICs (which I also saw in @paoba's post #31), but I couldn't tell you whether these existed prior to either 26.10 or this patched kernel, so I just thought I'd mention it.

Code Select Expand

[48] ice0: Failed to add VLAN filters:
[48] ice0: - vlan 1011, status -14
[48] ice0: Failure adding VLAN 1011 to main VSI, err ICE_ERR_ALREADY_EXISTS aq_err OK
[48] ice1: Failed to add VLAN filters:
[48] ice1: - vlan 1011, status -14
[48] ice1: Failure adding VLAN 1011 to main VSI, err ICE_ERR_ALREADY_EXISTS aq_err OK
[48] ice0: Failed to add VLAN filters:
[48] ice0: - vlan 1010, status -14
[48] ice0: Failure adding VLAN 1010 to main VSI, err ICE_ERR_ALREADY_EXISTS aq_err OK
[48] ice1: Failed to add VLAN filters:
[48] ice1: - vlan 1010, status -14
[48] ice1: Failure adding VLAN 1010 to main VSI, err ICE_ERR_ALREADY_EXISTS aq_err OK


#3

26.7, 26.10 Series / Re: Gradual Internet Performan...

Last post by pfry - Today at 12:58:07 AM

[...]none of those things changes anything to a Android/Apple/Linux/Windows Client ofcourse ;)

Ha! I forgot about those entirely. Trapped in my bubble (even though I'm using Win10).

[...]At this point, I'm wondering why the state table grows so large[...]

What protocol/service? TCP sessions tend to hang around; I usually have a bunch of TCP DNS sessions in TIME_WAIT, as DNS can be a spew. My old Fortigate had granular control of session timeouts, one of its few advantages. Not a functional issue, really - I mostly cut UDP DNS timeouts to reduce clutter when browsing the state table. I don't bother with OPNsense.

I'd expect sessions to be more of a memory issue than processor, and I wouldn't expect a problem with 16GB. Those session spikes may be more of a symptom than a cause - the protocol may be revealing. (I have static IPs and servers; I average a few hundred sessions, but lots of bots/scrapers/whatever can put that up to 5000 or so for hours or days. That doesn't even account for the constant stream of blocked packets.)

[Drop issues]

#4

Hardware and Performance / Intel E610 / ix: link drops at...

Last post by -pletch- - Today at 12:27:23 AM

I recently moved my OPNsense box (26.7, VM on Proxmox with the NIC passed through) to an Intel E610-XT2. I was seeing sporadic link drops and during investigation identified an upstream bug associated with setting EEE via sysctl when attempting to turn disable.

I noticed setting the EEE sysctl on a running ix interface never returns. The sysctl process hangs in an uninterruptible state, and the interface's broadcast address pointer gets corrupted (broadcasts on that interface go to ff:ff:00:00:00:00 until a reboot). The cause is a wrong argument in the driver's EEE handler, if_init(ifp, ifp).

• It's not only E610-specific: any ix adapter that exposes eee_state goes through the same code. Besides the E610, that's the ports built into Xeon D-1500 (10G KR) and Atom C3000 (1G copper, common in small firewall boxes) chips. Plain X550-T1/T2 cards, X540 and 82599 don't have the setting, so they're not affected. If running "sysctl dev.ix.0.eee_state" shows a value on your box, you're exposed. I've only tested on the E610 but the driver code suggests this will happen in these other configurations as well.
• Putting dev.ix.N.eee_state=0 under System > Settings > Tunables runs the same code at boot. I haven't tried it, but expect it to hang there too.
• EEE is on by default on the E610 and the driver has no loader tunable for it, so on a stock kernel this sysctl is the only way to turn it off from the FreeBSD side. Otherwise you have to turn it off on the switch.

I filed an upstream bug report with a patch: FreeBSD PR 300670. I'm running a kernel with the patch, and the sysctl now returns immediately and EEE really turns off.

Drop issues

• WAN port (to my Fiber ONT) dropped twice for a few seconds while linked at 10G. I locked it to 2.5G (my service is 2 Gbit anyway) and it stopped, while EEE was still on, so on that link it seems to be the 10G connection rather than EEE but I haven't investigated further to confirm. It hasn't dropped since.
• LAN port (to a Netgear MS305E 2.5G switch) dropped twice in a day for a few seconds, both times when the network was quiet. Each one was a link down/up with the NIC counting "local faults", and no CRC or other errors.
• The firmware reports EEE as enabled and active on the LAN link (both ends agreed to use it). I read that from the driver with DTrace, since nothing displays it. The dev.ix.N.eee.*_lpi_count counters stayed at 0 even while EEE was active, so don't rely on them to tell whether EEE is in use.
• With EEE off, the LAN port has gone a little over two days without a drop. Fingers crossed that this fixes it and it is reflective of some incompatibility between the E610 and my switch and how they handle EEE transitions.

Figured I'd share here for the benefit of others that might be playing with the Intel E610 cards.  There doesn't seem to be too many reports out there as they are pretty new, a little $$, and not many in the wild thus far.

#5

Virtual private networks / Re: Noob trying to get Wiregua...

Last post by BoNetTech - November 10, 2026, 11:46:47 PM

Great, these screenshots help a lot.

Good news: your laptop is using the firewall's DNS only (192.168.20.1 on the wired link, wlan0 has no DNS scope). The 127.0.0.53 you saw earlier is just the laptop's local stub. Firefox DoH is off, so the browser follows the system DNS. IPv6 addresses in a DNS answer are normal: the DNS knows about them even if your network doesn't use IPv6.

A small command fix: with dig the server needs an @: dig @192.168.20.1 example.com. Without it, dig also looked up "192.168.20.1" as a name, which gives the NXDOMAIN you saw. Harmless.

DHCP: your PERSONAL20, XBOXS10 and GUEST30 ranges look right. The MGNT99 row has a start address of 192.168.99.10 and no end. That is exactly your laptop's static IP. Either delete that row (you use static IPs there) or set the range to 192.168.99.100–192.168.99.200 so DHCP can never offer .10.

What is still open: where the firewall's own DNS queries go. Please run dnsleaktest again (the extended test) and post the table with the ISP column readable, blurring only the IP column. If the ISP names are your own provider, the firewall's queries leave through the WAN. If they are Quad9 or the operators that serve it, it's fine.

And for the Xbox: please do the test with 1.1.1.1 set manually on the Xbox first (DNS vs tunnel MTU), as described before.

Sergio

#6

Development and Code Review / Re: netflector available as pl...

Last post by UnicronHD - November 10, 2026, 11:20:41 PM

Nice!
Currently I run mdns repeater and ssdpreflector between my lan and iot vlan.

If I am correct I can drop these packages for this single package? :D

It would seem so, yes. Let me know if you need help with the configuration. If you will want to enable dial - you will probably require some firewall adjustments (for input chain to accept DIAL responses from IOT VLAN). If everything works for you now though - you will probably only need mdns and ssdp set to true. Dial is for things like my stupid LG TV that does not accept DIAL connections from other networks even after successful SSDP discovery.

#7

26.7, 26.10 Series / Re: Gradual Internet Performan...

Last post by tonys - November 10, 2026, 10:56:45 PM

Update: The aforementioned removal of all IPV6 enables helped for a while but last night, the network began stalling again, mostly on streaming services like SiriusXM, Facebook, and Youtube. So I reenabled the external VPN on my phone and the streaming services worked again. Before reenabling the VPN, I checked the Unbound logs and found no blocks occurring at all so I don't think these streaming stalls are related to DNS. I also noted that when the VPN is on, I don't see any transactions from the device I'm using in the firewall logs - turning the VPN off does show transactions and they're all going through. All this really says is that the use of external VPNs allows packets to sail through the firewall rules as well as DNS.

This morning, all my devices were laggy or unavailable on the internet... I couldn't even retrieve my email. Also, on my Mac, I was unable to log into this board so I reenabled the VPN on both the phone and the Mac. Checking the current the OPNSense state list:

# pfctl -s states | wc -l
    1299

1299 states? Really? Yesterday, the state count was hovering around 300 earlier in the day. Next, I checked the WAIT states:

# pfctl -s states | grep "_WAIT" | wc -l
      49

Not too bad but this doesn't explain where all the other states are coming from after an overnight of very little activity. Looking in the state table for each VLAN (IoT and Guest), I see about 25 states each, not bad at all. Looking at the state table for the LAN however, I see 1226 established states! Past experience with 26.7.x has shown that a large state table really slows down all the LAN/VLANs so on the surface, it seems that these established states may be preventing me from turning off the VPN on my Mac and phone. Note that I don't use any state tracking other than "Keep State" - there are no sloppy states defined in any of my LAN/VLANs.

My experiment just now was to clear the LAN state table completely. Now I see:

# pfctl -s states | wc -l
     143
# pfctl -s states | grep "_WAIT" | wc -l
      77

This is very typical during daytime activity and I don't need to turn the VPN on. The 77 _WAIT states are all on the LAN. Most notable is that after reseting the LAN states, all my streaming services are back up and running without having to turn on the VPN.

At this point, I'm wondering why the state table grows so large over the course of a day, mostly in the evening and overnight. I'm fairly certain that the growing state table ovwe 12-15 hours (both established and _WAIT states), is the cause of my network stalls and streaming service blockages. I have no idea why, I'm simply correlating the size of the state table vs ability to access the internet. The larger the state table grows, the slower my internet access gets and eventually nearly comes to a complete halt without an external VPN enabled.

Going back to disabling IPV6 yesterday - the OPNSense GUI is now responsive again, all the time, even when the state table is huge. So there's a direct correlation between disabling IPV6 and usability of the web gui. Also, I did (and still do) have "prefer IPV4 over IPV6" turned on but that didn't help at all when IPV6 was still enabled in the WAN gateway. Simply disabling IPV6 in the gateway was all it took to get the OPNSense GUI responsive again, so this goes back to OPNSense 26.7.x and my ISP not playing nice together regarding IPV6. OPNSense 21.x had no problems getting an IPV6 address from my ISP... why can't 26.7.x?

Back in the 21.x days, I always had both an IPV4 and IPV6 address with my ISP and I never saw any of these OPNSense GUI stalls/extreme slowness. I have to wonder whether the IPV6 state bug was resolved since I can't get an IPV6 address from my ISP afte4r upgrading to 26.7. The one time I did get an IPV6 address was during numerous debug cycles and reboots and that IPV6 address didn't survive the following reboot. For now, I need to focus on why my state table is growing during the day and gets very large at night. Tonight, I'll clear the LAN state table as soon as SiriusXM and Youtube refuse to load without the VPN, and see if doing just this alone restores the streaming services again.

#8

26.7, 26.10 Series / Re: PPPoE over an unassigned V...

Last post by johndoeuser - November 10, 2026, 10:07:50 PM

Will have a go at it asap. You're the best, tnx.

#9

Development and Code Review / Re: netflector available as pl...

Last post by vicking - November 10, 2026, 08:48:28 PM

Nice!
Currently I run mdns repeater and ssdpreflector between my lan and iot vlan.

If I am correct I can drop these packages for this single package? :D

#10

26.7, 26.10 Series / Re: Is sloppy state tracking a...

Last post by FlyveHest - November 10, 2026, 08:27:49 PM

Do you use MACVLAN for your Docker Network ?

If not : You should! :)

I don't no, but the fix was pretty easy, I just had to add another PBR rule for the Docker network bridge and now everything works as it should.

Once again, thanks a bunch for the great help, now that the basic setup is done, I can get into the fun stuff and the main reason I chose to run OPNSense.