Recent posts

#1
26.1, 26,4 Series / Re: glitch Version 26.1.7_2
Last post by franco - Today at 10:55:05 AM
I don't think it was actually restarting but attempting to do so while some process blocked the reboot so whenever you open the page it wants to prepare in the GUI for that (but no action is actually taken as the reboot is queued in the backend).


Cheers,
Franco
#2
26.1, 26,4 Series / Re: KEA is still a mess IMHO
Last post by franco - Today at 10:46:17 AM
Is this about OPNsense core integration or Kea (DHCPv6) in general? I'm unable to tell.


Cheers,
Franco
#3
26.1, 26,4 Series / Re: Partial config wipe after ...
Last post by franco - Today at 10:45:17 AM
System: Configuration: History would shed some light on when and where these parts were removed (by whom).



Cheers,
Franco
#4
That honestly looks more like the Tailscale interface/service restarting itself overnight rather than an actual internet drop. The `tun0 -> tailscale0` rename sequence usually happens when the interface gets recreated, so I'd check cron jobs, gateway monitoring, or anything scheduled around 06:53 that could trigger a service reload. basketball stars
#5
Quote from: vlnc on October 11, 2025, 03:33:35 PMHi everyone,

I'm running this version of OPNSense in a VM ESXi hosted:
OPNsense 25.7.5-amd64-dummies world cup
FreeBSD 14.3-RELEASE-p4
OpenSSL 3.0.18

Since I don't really know when this is happening (I mean since which opnsense update), I got this side effect :
While playing online on a server on my favorite game (squad on pc as an example), I got huge lags for a limited time (dozen of seconds) with effects like no more VOIP, everyone running into walls ect... cause of UDP packets are blocked/not processed by OPNSense. Result is sometimes after the lag and UDP packets transmitted again, I'm disconnected from the server, sometimes I'm not.

My network setup is pretty simple :

My PC : 192.168.2.2/24 using 192.168.2.1/24 (opnsense) as default gateway
Opnsense : using my ISP router as main and only gateway / DNS server (I need to SNAT traffic from/to 192.168.2.0/24 by 192.168.2.1 to my ISP router to access Internet cause I can't setup a static route on my ISP router (which is in 192.168.1.0/24) like "ip route 192.168.2.0/24 via 192.168.2.1/32".

Firewall rules on User interface is : 192.168.2.0/24 any any allow

As drawing is better than writing :



For your understanding of my OPNSense current configuration, list of services (enabled/disabled) :

  • Captive portal -> Disabled
  • DHCRelay -> Disabled
  • Dnsmasq DNS & DHCP -> Disabled
  • Intrusion Detection -> Disabled
  • ISC DHCPv4 -> Enabled
  • ISC DHCPv6 -> Disabled
  • Kea DHCP -> Disabled
  • Monit -> Enabled
  • Network Time -> Enabled
  • OpenDNS -> Disabled
  • Unbound DNS -> Enabled

Start ask chatgpt, redirected me to :
-> bug in opnsense since switching to pf (XD)
-> flush state table (pfctl -F states)
-> UDP State timeout to short
-> Service IDS/IPS suricata (disabled as you seen)
-> Update Bogons / GeoIP (weird cause I shouldn't be able to connect to the game server at the first place no ?)
-> Normalization rules on WAN interface (timeout parameter is missing in GUI)
-> System > Settings > Tunables then add these parameters net.pf.udp_first to 120, net.pf.udp_single to 120 and net.pf.udp_multiple to 180

I don't really know where to look for right now and I don't want to change parameters that I don't really know it will have a good or bad effect without your advices.

Anyone as an idea ? I'm only using GUI, doesn't made in changes via CLI/SSH.

I will investigate if this impact TCP traffic too.

Thanks for your help.

Regards,
vlnc
It sounds like you're experiencing some frustrating lag issues with your OPNsense setup. Given your configuration, it might be worth checking the UDP state timeouts, as you mentioned. Increasing the net.pf.udp_first, net.pf.udp_single, and net.pf.udp_multiple parameters could help alleviate the packet loss during your gaming sessions.
#6
General Discussion / Re: Open CVEs right after upda...
Last post by franco - Today at 10:10:06 AM
Yep, looking at the current open source ecosystem Python isn't going anywhere in many projects. We're also using it in backend scripting.


Cheers,
Franco
#7
26.1, 26,4 Series / Captive Portal Auto Redirect f...
Last post by NorthernNoel - Today at 10:05:40 AM
For Android and iOS redirect is working fine as it reads option 114 from DHCP. However on Windows I believe it doesn't read this and uses a redirect as per: https://docs.opnsense.org/manual/captiveportal.html

However, I can't get an auto redirect to work. If I manually type the address of the portal it gets there. I've tried manually creating the rules to no avail.
#8
26.1, 26,4 Series / Re: High CPU after upgrade fro...
Last post by jonny5 - Today at 10:03:32 AM
Similar problem, my Zenarmor appears to be crashing constantly - high CPU utilization.

pid 14461 (eastpect), jid 0, uid 0: exited on signal 3 (core dumped)
'eastpect' appears to be Zen Armor - I've turned Zen off and it seemed to reset my network stack, but also appears to have significantly lowered my CPU utilization.
#9
General Discussion / Re: MCP Server
Last post by alexop - Today at 09:55:28 AM
Hey you,

Thanks for sharing this, cool stuff! Been a fan of OPNSense for a while myself, and it's nice to see someone make something like your MCP Server.

question: do you think it's stable enough to use in production, or more for testing and experimentation?

Looking forward to poking around the repo and seeing what it can do!
#10
General Discussion / Re: NAT Outbound rules, static...
Last post by liambrown32 - Today at 09:53:23 AM
That matches my understanding too. Static-port NAT and UPnP are solving two different problems, so they generally do not conflict with each other.
Static-port outbound NAT mainly preserves the client's source port during translation, which helps some consoles/games avoid "Strict NAT" detection because the mapping stays predictable. sprunki
UPnP, on the other hand, is mostly about automatically creating inbound port forwards when an application requests them.
So using both together is actually pretty common in gaming-focused networks:
* static-port helps with outbound session consistency
* UPnP handles games/services that explicitly require inbound reachability
Your double-NAT setup probably makes NAT behavior detection even more sensitive, which explains why preserving source ports changed the console status immediately.

Also worth mentioning: modern consoles often test NAT based on endpoint mapping behavior rather than just whether ports are technically reachable, so OPNSense's default source-port randomization can absolutely downgrade the reported NAT type even if gameplay itself mostly works fine.