Recent posts

#1
Thanks for the suggestion.

I understand the reasoning behind the test, but there are a couple of reasons why I'm hesitant to try it on this particular system.

First, I am not planning to risk any outage, nor am I willing to accept one at this point. While a reboot itself is not a major issue, the proposed test involves changing the microcode loading path and boot behaviour rather than simply observing the existing system state.

Second, the original issue I reported was a packaging problem in FreeBSD. That issue has now been confirmed and fixed upstream. The remaining question is why this specific platform still does not receive a microcode update even though:

- the correct 06-9a-04.80 split file is now present
- IA32_PLATFORM_ID indicates platform ID 7 (0x80)
- newer microcode revisions appear to exist for this CPU family

At this point I'm not yet convinced that the root cause is a timing issue. The current evidence only shows that the microcode is not being applied, not why.

Before testing alternative loading mechanisms, I would prefer feedback from the FreeBSD maintainer of the microcode package. If there is a specific diagnostic procedure recommended from the FreeBSD side, I'll be happy to follow it.

For now I'd rather avoid changing the microcode loading mechanism on a production system and potentially introducing a second variable while the original issue is still under investigation by the maintainer. => See the Bug Report
#2
General Discussion / Re: Is this "no internet acces...
Last post by lmoore - Today at 06:11:56 AM
What you are asking can be achieved.

Which version of OPNsense are you running?

Your block rule appears fine but could be refined by using a negated RFC-1918 network alias as the destination. If you enable logging of this rule you will see when it is used.

You may have other rules which are affecting the flow of traffic in to this interface..
Please provide more information about your set up including other rules you have for this interface as well as any floating rules applied to it.

Rules for WireGuard will need to be created to access the "mediaserver" network or just the servers IP addresses, either for your existing WireGuard instance or with a new instance which only has access to that network, if you prefer.

You may want to include IPv4 Null Routes in OPNsense - see https://forum.opnsense.org/index.php?topic=50678.msg259031#msg259031
#3
General Discussion / Is this "no internet access ne...
Last post by Plus0974 - Today at 03:16:31 AM
I have a homelab that I'll be installing home assistant to on a new virtual machine and want to make sure I made a network where devices on it cannot access the internet but devices on the network can access it and this is my first time messing with firewall settings. This new network would be under the IP range that starts at 192.168.5.1 instead of the default one for example. Also I already have Wireguard to connect to my home network normally but would I be able to connect to servers on this new ip range still even if it's a different network or will I need a new wireguard instance for this new network?
#4
26.1, 26,4 Series / Re: Degraded Speed Ghost
Last post by muchacha_grande - Today at 02:18:21 AM
Hi, your situation reminds me a problem I had with pfSense a long time ago. Of course the speeds were slower at that time.
The solution was, if I can remember well, to set a fixed speed at the WAN interface. I set 100M full-duplex and the problem was solved.
For some reason the auto negotiation was not working as expected.
#5
***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 26.4.1 (amd64) at Sat Jun 20 16:47:18 MDT 2026
Strict TLS 1.3 and CRL checking is enabled.
Fetching subscription information, please wait... done
Fetching changelog information, please wait... done
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: .......... done
Processing entries: .......... done
OPNsense repository update completed. 938 packages processed.
Updating SunnyValley repository catalogue...
pkg: An error occurred while fetching package: Unknown error
pkg: An error occurred while fetching package: Unknown error
Fetching data.tzst: .... done
Processing entries: .. done
SunnyValley repository update completed. 15 packages processed.
All repositories are up to date.
Checking for upgrades (2 candidates): .. done
Processing candidates (2 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***

like i am not sure i ever remember a single zenarmor update without some sort of issue.
#6
26.1, 26,4 Series / Re: Degraded Speed Ghost
Last post by juicemain - June 20, 2026, 11:44:27 PM
Well I have two more frustrating updates:

1. I observed the degraded speed state on the ISP provided router while playing Overwatch.  It is much rarer on the ISP router, and it definitely resolves itself much quicker.  It has never caused disconnects unlike 3rd party routers, but I did observe the degraded speed just now.

2. I tried the Protectli Vault FW2B, and wow.  Not good performance.  I couldn't even get it to hit full gig speeds.  It only performed at around half, ~500m down / ~500m up.  Even with that though, I definitely still noticed the decayed state while testing as it decayed to ~500m down / ~50m up.

Whew.  I feel I've exhausted all of my options, save for contacting the ISP directly.  I did call the ISP customer support line, just to ask if we could check the logs from router and modem.  The representative told me I could check those logs by logging into the Calix U6 through the ip address browser portal.  Unfortunately, that's not the case.  These routers are locked down.  Can't shell into them, and the browser UI options are extremely limited.

If anyone has any clue as to what this could be at this point, anything would be much appreciated.  I have no idea what to check next, and I highly doubt the ISP is going to be willing to help much.  Thanks again for all the help already.
#7
Zenarmor (Sensei) / Re: Dashboard broken after 2.6...
Last post by sy - June 20, 2026, 11:30:55 PM
Hi all,

Thank you for your patience. The issue has been resolved and the repository has been updated. To apply the fix, please run the following command as root in your CLI:

pkg install -fy os-sensei
#8
Zenarmor (Sensei) / Re: Dashboard broken after 2.6...
Last post by RutgerDiehard - June 20, 2026, 11:03:55 PM
I have fixed the problem.

I used the Cloud console link in the UI to register the instance and I was able to get to the UI from the cloud console. I ran through the on-boarding wizard which synchronised the policies and one of them failed. The sync error mentioned an interface "em0". I checked the policy settings and there was no em0 interface. So I deselected the interface that was configured for the policy (igc3 in this case) and then re-selected it again. This allowed the policy synchronisation to succeed. I was curious as to whether this was the local UI issue and after a refresh, the local console UI leaped into life again. Hope this helps others who will be waiting for Zenarmor to respond on Monday.
#9
26.1, 26,4 Series / Re: WireGuard does not start a...
Last post by chemlud - June 20, 2026, 10:50:41 PM
...I see stuff with WG tunnels (non-connecting, stopping randomly, not starting services on reboot) which shows no pattern or is not related to any changes at the endpoints. There is something weird going on.

Sometimes a restart of the service resolves it, sometimes a reboot is needed. On an ancient pfsense I have to re-install (!) the WG plugin (via another, working WG tunnel to another opnsense, really scary if you are remote...) to make a specific tunnel to an opnsense come up again from time to time.
#10
26.1, 26,4 Series / Re: WireGuard does not start a...
Last post by AlPi - June 20, 2026, 09:13:36 PM
I was thinking about opening my own topic but don't want to clutter the forum.
If it turns out our cases are totally not related, I'll open another topic.
Really been pulling my hairs the last couple of days.
Had a perfectly working dual wireguard connection to Torguard in failover mode using a gateway group with separate monitor IPs. (FAR Gateway enabled and Disable routes enabled on the instance)
Currently running OPNsense 26.1.10 (amd64) on a physical box but unsure when the issues started to be honest.

I'm seeing strange issues with my wireguard setup.
With strange I mean:
packet loss with simple pings
ping -c 20 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=5 ttl=116 time=5.76 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=116 time=5.98 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=116 time=8.22 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=116 time=12.6 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=116 time=7.69 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=116 time=7.89 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=116 time=5.56 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=116 time=9.48 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=116 time=6.35 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=116 time=5.65 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=116 time=5.94 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=116 time=6.88 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=116 time=6.69 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=116 time=5.89 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=116 time=5.81 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=116 time=6.22 ms
--- 8.8.8.8 ping statistics ---
20 packets transmitted, 16 received, 20% packet loss, time 19141ms
rtt min/avg/max/mdev = 5.558/7.035/12.573/1.791 ms
I do the test again a few minutes later and I get no ping timeouts.
commands like curl ifconfig.io taking 1 second and 4-5 seconds the next minute or not giving a reply at all.

Things I tried:
- Decreased the priority of the wireguard from 255 to 10

- Changed keepalive to 15

- Changed my dual tunnel setup to a single tunnel and deleted my gateway group..

- doubled checked mtu
ifconfig wg2
wg2: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
        description: TorGuard_WG_Tunnel_00 (opt9)
        options=80000<LINKSTATE>
        inet 10.13.128.145 netmask 0xfffffffe
        groups: wg wireguard
        nd6 options=9<PERFORMNUD,IFDISABLED>
- I'm seeing the issues from a VM that is only allowed access to the outside through wireguard so added firewall rules and outbound NAT rules to place a laptop also behind the VPN and also the same packet loss issue. (up to 70% on the first attempt, 0% on the second attempt,30% on the third attempt)
- Checked github:
maybe somewhat related? https://github.com/opnsense/core/issues/10421
Things I also have that are mentioned in that thread:

UDP "no socket" drops — counter climbing continuously
netstat -s -p udp | grep "no socket"
        6154189 dropped due to no socket

sockstat — socket process ownership shows as unknown
sockstat -4 | grep -E "57011"
?        ?          ?     ?   udp4   *:57011               *:*
netstat -I wg2
Name    Mtu Network           Address           Ipkts Ierrs Idrop     Opkts Oerrs  Coll
wg2    1420 <Link#21>         wg2            12511586     0     0    943160     0     0
wg2       - 10.13.128.144/31  10.13.128.145        16     -     -         0     -     -
I'm now going to try to connect to another ip at the VPN provider to see if that makes any difference.