"Recent posts
#21
25.7, 25.10 Series / Re: High CPU on Dashboard
Last post by JimmyLostOne - November 21, 2025, 11:01:29 PMI'm seeing something similar since upgrading to 25.7. Same CPU spikes on dashboard loads, same errors in the logs, but I also see some of the widgets failing to load. I'm curious if this has to do with the number of widgets and types? Seems like a bunch of connections being opened for each widget?
My specs:
J4125 Intel
32G DDR4
Msata 128G drive
6x I226v7
My specs:
J4125 Intel
32G DDR4
Msata 128G drive
6x I226v7
#22
25.7, 25.10 Series / [Solved] Monitoring gateway st...
Last post by julsssark - November 21, 2025, 10:36:10 PMI am trying to monitor the status of my WAN gateway using Uptime Kuma and the OPNsense API. Despite my best efforts and google skills, I cannot get it to work and would appreciate any help. The monitor is showing red/down continually and there are no errors in the Uptime Kuma messages area. I am pretty sure it is an error in the way I am configuring Uptime Kuma. Here's what I have done:
1) Setup a new user, with access to the Gateways and generated the key/secret
2) Used CURL -k -u "<key>":"<secret>" https://myIP/api/routes/gateway/status from the Uptime Kuma console and I get the expected response
3) Configured Uptime Kuma as follows:
I've tried various combinations of putting the authorization into the header/body, encoding the key/secret into base64, checking/unchecking the "ignore TLS/SSL errors". I'm probably just not using the right combination of things.
1) Setup a new user, with access to the Gateways and generated the key/secret
2) Used CURL -k -u "<key>":"<secret>" https://myIP/api/routes/gateway/status from the Uptime Kuma console and I get the expected response
3) Configured Uptime Kuma as follows:
- Monitor type = HTTP(s)-Json Query and the URL is the same as in step #2
- Json Query expression and associated fields are set to $.status == ok
- Method is GET, body encoding is JSON and body/header fields are blank
- Authentication is set to basic auth and I put the key/secret into the username/password fields
I've tried various combinations of putting the authorization into the header/body, encoding the key/secret into base64, checking/unchecking the "ignore TLS/SSL errors". I'm probably just not using the right combination of things.
#23
General Discussion / Re: Rule confusion between sep...
Last post by meyergru - November 21, 2025, 09:29:45 PMUsually, you will want an "in" rule like "allow any to any" for normal LANs and there is such a default rule for the first LAN.
However, this is generally too broad, because it allows access to any other (V)LAN when applied to all (V)LANs. The general recommendation is to use a "block any to RFC1918" rules before the "allow any to any" rule, with RFC1918 created as an alias for all RFC1918 ranges.
You can achieve the same effect if you deny access for specific destination interfaces.
Usually, you will have one or more (V)LANs that really have the permission to allow access to all other (V)LANs, like your main LAN or a Management VLAN. Only for those, you will not define a block rule.
However, this is generally too broad, because it allows access to any other (V)LAN when applied to all (V)LANs. The general recommendation is to use a "block any to RFC1918" rules before the "allow any to any" rule, with RFC1918 created as an alias for all RFC1918 ranges.
You can achieve the same effect if you deny access for specific destination interfaces.
Usually, you will have one or more (V)LANs that really have the permission to allow access to all other (V)LANs, like your main LAN or a Management VLAN. Only for those, you will not define a block rule.
#24
High availability / Re: HA setup is flapping betwe...
Last post by Tanker_UA - November 21, 2025, 09:25:06 PMI just completely removed the backup firewall/router from my network, and all is working correctly. Until I get this resolved, I will not connect the backup unit to my network. It is amazing how little help I got from these forums! I wonder if I paid for a license (which I'm inclined to do so there are no excuses for lack of support), I would get the same treatment from the pricey support.
Thank you all,
Martin M. Mune
US Army Combat Veteran
Operation Iraqi Freedom
Volunteer Soldier
International Legion for the Defense of Ukraine
Слава Україні!
Героям Слава!
Thank you all,
Martin M. Mune
US Army Combat Veteran
Operation Iraqi Freedom
Volunteer Soldier
International Legion for the Defense of Ukraine
Слава Україні!
Героям Слава!
#25
General Discussion / Rule confusion between separat...
Last post by brigmaticlaw - November 21, 2025, 08:59:17 PMHi everyone! I was hoping you may be able to point me in the right direction on this small obstacle I've been hitting.I am not at all ruling out gross ignorance here so please accept my apologies in advance.
I am attempting to have two physically separate networks both going through my OPNsense box. One is my main home network with several VLANS (Lab, Main, Guest, etc) all trunked to my main switch on a 10Gbe NIC, ix0. The second is plugged into a 4 port NIC on em2 (em1 is WAN) and is intended to be an internet access only mini-LAN for all work-owned devices to connect to. This hardware is nothing more than a 5 port unmanaged switch connected to an older Linksys router set to Bridge Mode with a static IP and its own SSID.
Other than the auto-generated rules, the only rule I have on the "Work" interface is to allow internet. At first I thought the segmentation was working but I have discovered that is not actually the case. I tried setting a rule on the Work interface to block all outbound traffic from Work net to all other interfaces in my trusted network. However, using my work laptop connected hardwire and WiFi, I am still able to access all of my resources running on my Lab VLAN on the trusted network.
I also tried setting a rule on the Lab interface to block all incoming traffic from Work net but that also didn't seem to work.
It doesn't seem to matter whether I'm using the IP of the service or the local FQDN I have set up through Nginx Reverse Proxy Manager.
I feel like one of these rules should work but, again, I could just be incredibly ignorant.
Any ideas of what I'm doing wrong? I appreciate any direction you may be able to provide.
I am attempting to have two physically separate networks both going through my OPNsense box. One is my main home network with several VLANS (Lab, Main, Guest, etc) all trunked to my main switch on a 10Gbe NIC, ix0. The second is plugged into a 4 port NIC on em2 (em1 is WAN) and is intended to be an internet access only mini-LAN for all work-owned devices to connect to. This hardware is nothing more than a 5 port unmanaged switch connected to an older Linksys router set to Bridge Mode with a static IP and its own SSID.
Other than the auto-generated rules, the only rule I have on the "Work" interface is to allow internet. At first I thought the segmentation was working but I have discovered that is not actually the case. I tried setting a rule on the Work interface to block all outbound traffic from Work net to all other interfaces in my trusted network. However, using my work laptop connected hardwire and WiFi, I am still able to access all of my resources running on my Lab VLAN on the trusted network.
I also tried setting a rule on the Lab interface to block all incoming traffic from Work net but that also didn't seem to work.
It doesn't seem to matter whether I'm using the IP of the service or the local FQDN I have set up through Nginx Reverse Proxy Manager.
I feel like one of these rules should work but, again, I could just be incredibly ignorant.
Any ideas of what I'm doing wrong? I appreciate any direction you may be able to provide.
#26
Zenarmor (Sensei) / Re: Provide firm date on multi...
Last post by PietPiraat - November 21, 2025, 08:00:28 PMQuote from: Seimus on November 01, 2025, 12:21:01 AMQuote from: jclendineng on October 31, 2025, 10:37:05 PMI have all 10Gb+ internally and ZA just did not work at all.
And this is exactly what I am all the time pointing out. The problem that is caused by not having multicore >Quote"InterVLAN" throughput is due to ZA bottle-necked.
Regards,
S.
Thank you for creating this thread and prevent me from stepping on this landmine. Putting multicore processing behind a business paywall that is out of reach for home users is ridiculous. It is not groundbreaking new technology.
#27
25.7, 25.10 Series / Re: High CPU on Dashboard
Last post by cyberfarer - November 21, 2025, 07:48:37 PMIt does exist and the permissions match similar file types.
Code Select
srwxr-x--- 1 root wheel 0 Nov 20 15:53 php-fastcgi.socket-0
srwxr-x--- 1 root wheel 0 Nov 20 15:53 php-fastcgi.socket-1
srwxr-x--- 1 root wheel 0 Nov 20 15:53 php-fastcgi.socket-2
srwxr-x--- 1 root wheel 0 Nov 20 15:53 php-fastcgi.socket-3
#28
Italian - Italiano / VPN IPsec con Nat Before IPsec
Last post by TDSOTB - November 21, 2025, 07:33:39 PMCiao a tutti,
Più che una richiesta di aiuto volevo condividere un HowTo e contribuire alla community italiana di questo fantastico prodotto nella speranza che possa semplificare il lavoro e spingere anche nuova gente ad adottare questo firewall.
Sulla documentazione ufficiale si trova tutto, ma online non ho trovato una guida passo a passo for dummies (per chi ad esempio viene dal mondo pfsense, ce ne sono moltissime) e volevo semplificare l'operazione per coloro che non sono espertissimi, visto che, per capire il meccanismo è necessario conosce in maniera un po' più approfondita le fasi dell'IPsec.
Entriamo nel dettaglio: parto prima con lo spiegone ma in coda metto tutti gli screenshot con i vari passaggi step by step per chi fosse pigro.
Come suggerisce l'oggetto mi rivolgo a chi usa l'opnsense soprattutto come vpn concentrator poiché riguarda il setup di una VPN ipsec policy based con una sovrapposizione delle due reti locali e quindi che necessita di un NAT/BINAT (in questo caso la sovrapposizione della 10.0.0.0/24)
Quindi bisogna scegliere due reti di servizio da impostare nel tunnel ( la 10.10.10.0/24 e la 10.10.11.0/24)
Per chi viene dal mondo pfsense è una operazione semplice, quasi banale che si fa durante il setup delle varie fasi 2.
Su Opnsense come anticipato va conosciuto più nel dettaglio il meccanismo in cui funziona L'IPsec e come instaura i tunnel e sceglie i pacchetti da convogliare dentro di essi. Ma una volta capito il metodo risulta molto più chiaro, lineare e granulare.
Il concetto principale è quello di Security Policy Database (SPD). Una volta che arriva un pacchetto sull'interfaccia di lan, per decidere dove ruotarlo il firewall controlla il suo SPD, se è presente una policy allora viene girato nel tunnel VPN utilizzando le informazioni delle Security Association Database (SAD).
Il SPD viene generato in automatico sulla base delle regole settate nelle Children Security Association (Fasi 2) settate nelle varie ipsec configurate in Connections
Il punto è che il traffico che deve essere intercettato e ruotato è quello proveniente dalla 10.0.0.0/24. Ma se si imposta la 10.0.0.0/24 nelle Child_SA del tunnel, nell'handshaking viene negoziata questa rete e fallisce. Quindi vanno messe la 10.10.10.0/24(10.10.11.0/24) e di conseguenza vengono generate in automatico le policy corrispondenti nell'SPD.
Per permettere al firewall di ruotare anche i pacchetti provenienti della 10.0.0.0/24 bisogna creare una policy manuale nel spd e associarla alla corrispettiva Child_SA.
Una volta fatto va detto al Firewall di tradurre gli ip della 10.0.0.0/24 in 10.10.10.0/24(10.10.11.0/24) altrimenti vengono rigettati dall'apparato remoto.
Vanno create poi tutte le regole Firewall sia per mettere in sicurezza l'apparato dalla WAN permettendogli di comunicare solo ed esclusivamente con gli ip pubblici che vogliamo, sia per sbloccare le reti o meglio ancora i singoli host sulle singole porte che vogliamo che comunichino con la rete remota tramite la VPN.
Non ho preso in considerazione l'elemento di routing, ma se necessario vanno anche aggiunte rotte statiche per il raggiungimento delle reti locali e remote, e la configurazione va anche ripetuta speculare per l'apparato remoto.
Ovviamente se ci sono imprecisioni o inesattezze liberi di correggerle e qualsiasi arricchimento e aggiunta è ben accetta.
Spero che possa esservi utile.
Ecco di seguito i vari screenshot.
Più che una richiesta di aiuto volevo condividere un HowTo e contribuire alla community italiana di questo fantastico prodotto nella speranza che possa semplificare il lavoro e spingere anche nuova gente ad adottare questo firewall.
Sulla documentazione ufficiale si trova tutto, ma online non ho trovato una guida passo a passo for dummies (per chi ad esempio viene dal mondo pfsense, ce ne sono moltissime) e volevo semplificare l'operazione per coloro che non sono espertissimi, visto che, per capire il meccanismo è necessario conosce in maniera un po' più approfondita le fasi dell'IPsec.
Entriamo nel dettaglio: parto prima con lo spiegone ma in coda metto tutti gli screenshot con i vari passaggi step by step per chi fosse pigro.
Come suggerisce l'oggetto mi rivolgo a chi usa l'opnsense soprattutto come vpn concentrator poiché riguarda il setup di una VPN ipsec policy based con una sovrapposizione delle due reti locali e quindi che necessita di un NAT/BINAT (in questo caso la sovrapposizione della 10.0.0.0/24)
Quindi bisogna scegliere due reti di servizio da impostare nel tunnel ( la 10.10.10.0/24 e la 10.10.11.0/24)
Per chi viene dal mondo pfsense è una operazione semplice, quasi banale che si fa durante il setup delle varie fasi 2.
Su Opnsense come anticipato va conosciuto più nel dettaglio il meccanismo in cui funziona L'IPsec e come instaura i tunnel e sceglie i pacchetti da convogliare dentro di essi. Ma una volta capito il metodo risulta molto più chiaro, lineare e granulare.
Il concetto principale è quello di Security Policy Database (SPD). Una volta che arriva un pacchetto sull'interfaccia di lan, per decidere dove ruotarlo il firewall controlla il suo SPD, se è presente una policy allora viene girato nel tunnel VPN utilizzando le informazioni delle Security Association Database (SAD).
Il SPD viene generato in automatico sulla base delle regole settate nelle Children Security Association (Fasi 2) settate nelle varie ipsec configurate in Connections
Il punto è che il traffico che deve essere intercettato e ruotato è quello proveniente dalla 10.0.0.0/24. Ma se si imposta la 10.0.0.0/24 nelle Child_SA del tunnel, nell'handshaking viene negoziata questa rete e fallisce. Quindi vanno messe la 10.10.10.0/24(10.10.11.0/24) e di conseguenza vengono generate in automatico le policy corrispondenti nell'SPD.
Per permettere al firewall di ruotare anche i pacchetti provenienti della 10.0.0.0/24 bisogna creare una policy manuale nel spd e associarla alla corrispettiva Child_SA.
Una volta fatto va detto al Firewall di tradurre gli ip della 10.0.0.0/24 in 10.10.10.0/24(10.10.11.0/24) altrimenti vengono rigettati dall'apparato remoto.
Vanno create poi tutte le regole Firewall sia per mettere in sicurezza l'apparato dalla WAN permettendogli di comunicare solo ed esclusivamente con gli ip pubblici che vogliamo, sia per sbloccare le reti o meglio ancora i singoli host sulle singole porte che vogliamo che comunichino con la rete remota tramite la VPN.
Non ho preso in considerazione l'elemento di routing, ma se necessario vanno anche aggiunte rotte statiche per il raggiungimento delle reti locali e remote, e la configurazione va anche ripetuta speculare per l'apparato remoto.
Ovviamente se ci sono imprecisioni o inesattezze liberi di correggerle e qualsiasi arricchimento e aggiunta è ben accetta.
Spero che possa esservi utile.
Ecco di seguito i vari screenshot.
#29
General Discussion / Re: OPNsense insists that DHCP...
Last post by hhabroad - November 21, 2025, 07:06:17 PMQuote from: Submerge009 on July 31, 2025, 07:26:40 PMSeems like the issue has been present since at least OPNsense 25.1.9_2 based on https://github.com/opnsense/core/issues/8838Thank you! I was pulling my hair out trying to disable IPv6 on the LAN interface...
The solution is more like enable ISC DHCPv6, then disable "Track Interface" and that is it because after setting Interfaces->[LAN] "IPv6 Configuration Type" to "None", [LAN] under Services->ISC DHCPv6 no longer exists, so no way to disable the flag. Maybe that is by design? Since DHCPv6 server is not running according to the GUI.
Although the XML configuration stays the same as if DHCPv6 was enabled.
#30
25.7, 25.10 Series / Decoding "detailed rule info" ...
Last post by TJL - November 21, 2025, 05:48:34 PMI am attempting to use a Watchguard SSL VPN client to connect remotely. Clarification: I am using a computer behind a OPNsense firewall connecting to a computer behind a Watchguard firewall. I didn't get a clean copy before I upgraded to 27.7.7_4. The vpn client worked before the latest upgrade. As I read the online instructions, I found the "rid" link on the "detailed rule info" screen should point to the rule of why my vpn connection is being blocked. On a rule that "worked" (unrelated to this issue), I click on the rid link and it brings be Firewall:Rules:Advance screen. I don't see why I go to this screen since there are no rules. In my case, I click on the rid link, OPNsense opens a new window (like the one that works), but then immediately closes the window.
Here is a copy of the rule info screen:
__timestamp__ 2025-11-20T21:54:22-06:00
ack 897488549
action [block]
anchorname
datalen 0
dir [in]
dst external IP
dsthostname
dstport 443
ecn
id 48471
interface vtnet0
ipflags DF
ipversion 4
label Default deny / state violation rule
length 40
offset 0
protoname tcp
protonum 6
reason match
rid 02f4bab031b57d1e30553ce08e0ec131
rulenr 11
seq 431912277
src internal IP
srchostname
srcport 64022
status 2
subrulenr
tcpflags RA
tcpopts
tos 0x0
ttl 128
urp 0
I think I sanitized the screenshot. I first thought the rulenr was the rule number, but the rules that allow access show a value of 94, but I don't think I have that many rules, unless they are counting all rules for all interfaces. As far as I can tell, going to other HTTPS sites are working as expected.
Will someone explain how to read this page to see what rule is causing the vpn to fail?
Thanks.
Here is a copy of the rule info screen:
__timestamp__ 2025-11-20T21:54:22-06:00
ack 897488549
action [block]
anchorname
datalen 0
dir [in]
dst external IP
dsthostname
dstport 443
ecn
id 48471
interface vtnet0
ipflags DF
ipversion 4
label Default deny / state violation rule
length 40
offset 0
protoname tcp
protonum 6
reason match
rid 02f4bab031b57d1e30553ce08e0ec131
rulenr 11
seq 431912277
src internal IP
srchostname
srcport 64022
status 2
subrulenr
tcpflags RA
tcpopts
tos 0x0
ttl 128
urp 0
I think I sanitized the screenshot. I first thought the rulenr was the rule number, but the rules that allow access show a value of 94, but I don't think I have that many rules, unless they are counting all rules for all interfaces. As far as I can tell, going to other HTTPS sites are working as expected.
Will someone explain how to read this page to see what rule is causing the vpn to fail?
Thanks.
