"Recent posts
#1
26.7 Series / Re: How to enable/disable webg...
Last post by Greelan - Today at 05:52:46 AMQuote from: (MARLOO) on October 23, 2026, 11:54:03 PMBut A user can use both VPN and SSH: the VPN gives secure network access, while SSH provides a remote shell for diagnostics, logs, configuration changes and recovery. The VPN alone lets them reach the WebGUI, but SSH is what gives them terminal access.I didn't say otherwise xD
#2
26.7 Series / Re: Boot stuck for 1-2 min aft...
Last post by oc - Today at 02:30:37 AM #3
26.7 Series / Re: Wireguard vs. DNS resoluti...
Last post by oc - Today at 02:28:06 AMHallo meyergru - just wanted to follow up on this one as it's been a while. Perhaps my solution will help someone who experienced the same issue (slow boot due to Wireguard being bogged down by DNS resolution when setting up outbound wireguard connections to URLs rather than IPs - and when that happened, inbound Wireguard clients dialing into the opnsense had issues with DNS resolution). This behavior has been reported by others, and various LLMs agreed that it's a known issue, offering just some clunky workarounds (e.g., scripted delayed wireguard). I decided not to go that way.
What I ended up doing was using an external Wireguard router (a Flint 2) which takes care of all outbound Wireguard connections (segregated by VLANs and different igb NIC connections). I have also left the inbound Wireguard instances to opensense, from both another remote Flint 2 carrying quite a bit of traffic, and various mobile devices (such as phones tunneling all traffic through opnsense/zenarmour) - and all works well with just inbound Wireguard. The opnsense is booting fast and external Wireguard clients have no issue connecting to it and getting good DNS resolution.
I still have a (much smaller) issue, also documented - dpinger is giving up if thinking a gateway is down at boot time, and fails to add the respective (already defined) static route to the remote network connected via Wireguard to opnsense's routing table. When that happens, I cannot reach the affected remote network, and have to restart the gateway in question (but once I do that, traffic resumes right away - and I can do it either locally or connected to the opnsense over VPN so no super-big biggie, but it's still annoying in a setup that attempts to be as enterprise-y as possible). Online research suggests this behavior is freebsd-specific. In my case this happens due to a chicken-and-egg situation between opnsense and the Flint2 - because the Flint2 is going online through the opnsense - so obviously while the opnsense is rebooting there's no connectivity - and if the opnsense checks the gateways going through the Flint2 while booting - sometimes they are unavailable and thus the vicious circle. But, like I said, this only happens occasionally, and the fix is one click away, and can be done remotely. But while it works it's a quite cool setup, because the Flint2 does both inbound/outbound VPN, with various levels of Kill switches, and its own traffic and internet access is protected by opnsense/zenarmor/crowdsec.
Thank you meyergru for the steady assistance. I really appreciate it!
Have a great weekend, opnsense community!
OC
What I ended up doing was using an external Wireguard router (a Flint 2) which takes care of all outbound Wireguard connections (segregated by VLANs and different igb NIC connections). I have also left the inbound Wireguard instances to opensense, from both another remote Flint 2 carrying quite a bit of traffic, and various mobile devices (such as phones tunneling all traffic through opnsense/zenarmour) - and all works well with just inbound Wireguard. The opnsense is booting fast and external Wireguard clients have no issue connecting to it and getting good DNS resolution.
I still have a (much smaller) issue, also documented - dpinger is giving up if thinking a gateway is down at boot time, and fails to add the respective (already defined) static route to the remote network connected via Wireguard to opnsense's routing table. When that happens, I cannot reach the affected remote network, and have to restart the gateway in question (but once I do that, traffic resumes right away - and I can do it either locally or connected to the opnsense over VPN so no super-big biggie, but it's still annoying in a setup that attempts to be as enterprise-y as possible). Online research suggests this behavior is freebsd-specific. In my case this happens due to a chicken-and-egg situation between opnsense and the Flint2 - because the Flint2 is going online through the opnsense - so obviously while the opnsense is rebooting there's no connectivity - and if the opnsense checks the gateways going through the Flint2 while booting - sometimes they are unavailable and thus the vicious circle. But, like I said, this only happens occasionally, and the fix is one click away, and can be done remotely. But while it works it's a quite cool setup, because the Flint2 does both inbound/outbound VPN, with various levels of Kill switches, and its own traffic and internet access is protected by opnsense/zenarmor/crowdsec.
Thank you meyergru for the steady assistance. I really appreciate it!
Have a great weekend, opnsense community!
OC
#4
26.7 Series / Re: SSD drive died - I disable...
Last post by oc - Today at 02:04:01 AMThank you all. I thought I'll provide an update of what I've done to (hopefully) get more life out of the new SSD - maybe this will help anyone:
1. reduced the logging volume and retention time in Zenarmor, and focused on the interfaces of the networks I actually want to protect against ZA's core abilities. This greatly reduced the # of entries/24h. Over a week the "full vs empty" drive appears stable (1% of a 512GB SSD)
2. reduced the volume of ntopng logging (e.g., timeseries), and decided I'll keep ntopng disabled until such time when I need it to troubleshoot something (or to present the system to someone)
3. disabled hostwatch
4. disabled netflow
5. under Firewall/Settings/Advanced, disabled Default pass - Log packets matched from the default pass rules
6. enabled /var/log and /tmp RAM disks (this was done before, and while it didn't prevent my former SSD from dying, it likely delayed its demise).
All the best,
OC
1. reduced the logging volume and retention time in Zenarmor, and focused on the interfaces of the networks I actually want to protect against ZA's core abilities. This greatly reduced the # of entries/24h. Over a week the "full vs empty" drive appears stable (1% of a 512GB SSD)
2. reduced the volume of ntopng logging (e.g., timeseries), and decided I'll keep ntopng disabled until such time when I need it to troubleshoot something (or to present the system to someone)
3. disabled hostwatch
4. disabled netflow
5. under Firewall/Settings/Advanced, disabled Default pass - Log packets matched from the default pass rules
6. enabled /var/log and /tmp RAM disks (this was done before, and while it didn't prevent my former SSD from dying, it likely delayed its demise).
All the best,
OC
#5
26.1, 26,4 Series / Re: PHP2Shell security fix for...
Last post by tracker - Today at 01:24:06 AMThank you Franco for the effort. Much appreciated, as we normally treat the "closed" version as "stable", despite the possible security issues, which are treated individually when possible. Updating dozens of remote routes is not a trivial process.
On the other hand, user newsense can piss right off with this attitude... if you don't have a solution, just don't say anything instead of compounding on an already stressful issue with this passive-aggressive nonsense.
On the other hand, user newsense can piss right off with this attitude... if you don't have a solution, just don't say anything instead of compounding on an already stressful issue with this passive-aggressive nonsense.
#6
Tutorials and FAQs / [HowTo] OPNsense Boot Loader U...
Last post by nero355 - Today at 01:04:33 AMDear fellow OPNsense users,
I have written a complete document about the OPNsense Boot Loader Upgrade procedure based on what is already written in many topics here on the forum.
However all the information is extracted mainly from the following two :
- https://forum.opnsense.org/index.php?topic=48145.0
- https://forum.opnsense.org/index.php?topic=52579.0
And a lot of that information came from the posts made by Patrick M. Hausen :)
Instead of just Copy->Pasting everything I have done my best to also explain what you are actually doing during the process and which commands do what exactly or how the partitioning layout looks and things like that...
You can read the whole document at GitHUB : https://github.com/nero355/OPNsense---Boot-Loader-Upgrade-Summarized
Any comments or questions are welcome ofcourse! ;)
I had some weird issue after switching it to Public so I hope that issue won't return, but if it ever does please send me a PM/DM via the forum instead of posting it here in the topic! Thnx!
I have written a complete document about the OPNsense Boot Loader Upgrade procedure based on what is already written in many topics here on the forum.
However all the information is extracted mainly from the following two :
- https://forum.opnsense.org/index.php?topic=48145.0
- https://forum.opnsense.org/index.php?topic=52579.0
And a lot of that information came from the posts made by Patrick M. Hausen :)
Instead of just Copy->Pasting everything I have done my best to also explain what you are actually doing during the process and which commands do what exactly or how the partitioning layout looks and things like that...
You can read the whole document at GitHUB : https://github.com/nero355/OPNsense---Boot-Loader-Upgrade-Summarized
Any comments or questions are welcome ofcourse! ;)
I had some weird issue after switching it to Public so I hope that issue won't return, but if it ever does please send me a PM/DM via the forum instead of posting it here in the topic! Thnx!
#7
26.7 Series / Re: How to enable/disable webg...
Last post by (MARLOO) - October 23, 2026, 11:54:03 PMQuote from: Greelan on October 23, 2026, 11:29:23 PMIf a VPN is configured, an SSH tunnel is not needed. Just access the GUI directly over the VPN.
You're right. If the WebGUI is reachable over the VPN, no SSH tunnel is needed.
But A user can use both VPN and SSH: the VPN gives secure network access, while SSH provides a remote shell for diagnostics, logs, configuration changes and recovery. The VPN alone lets them reach the WebGUI, but SSH is what gives them terminal access.
I saw your repository and it looks interesting. I'll test it soon to receive notifications on Telegram
Regards,
MARLOO
#8
26.7 Series / Re: How to enable/disable webg...
Last post by Greelan - October 23, 2026, 11:29:23 PMQuote from: (MARLOO) on October 23, 2026, 07:01:21 PMSSH needs to be reachable only through a secure management path, for example WireGuard, Tailscale, or another VPN. Then create a local tunnel
If a VPN is configured, an SSH tunnel is not needed. Just access the GUI directly over the VPN.
#9
General Discussion / Re: Problem - Asymmetric routi...
Last post by HatalaTitla48 - October 23, 2026, 11:19:45 PMI found out that it was mistake in switch vlans config and ports connecting those two boxes. Its resolved now.
Thx guys for input.
Thx guys for input.
#10
Hardware and Performance / Re: OPNsense on Sophos XGS: dr...
Last post by abdelmonem - October 23, 2026, 11:08:13 PMHi Sergio,
A follow-up, since you asked the right question: the two work together now, since 0.1.0-alpha.5.6.
XGS: Settings has "Inspect, then hardware", off by default. With it on, each new connection goes to OPNsense's own Intrusion Detection in IPS mode, through an interface the driver makes for it, oxips0, until Suricata has let its first megabyte through. That's Suricata's own default stream depth. After that the coprocessor carries the rest, and a stream that a drop rule names never gets through at all.
Measured through the Intrusion Detection service on both boxes: a new TCP stream alerted on, then carried in hardware at 3.98 Gbit/s on the XGS 3300 and 941 Mbit/s on the XGS 136, its link full; a UDP stream with a drop rule, nothing let through.
https://npuforge.org/docs/measurements/inspect-2026-10-23/
So the honest limit now is the depth: past the first megabyte of a connection, Suricata sees nothing more of it.
Thanks again for pushing on this. It's a better project for it.
Abdelmonem
A follow-up, since you asked the right question: the two work together now, since 0.1.0-alpha.5.6.
XGS: Settings has "Inspect, then hardware", off by default. With it on, each new connection goes to OPNsense's own Intrusion Detection in IPS mode, through an interface the driver makes for it, oxips0, until Suricata has let its first megabyte through. That's Suricata's own default stream depth. After that the coprocessor carries the rest, and a stream that a drop rule names never gets through at all.
Measured through the Intrusion Detection service on both boxes: a new TCP stream alerted on, then carried in hardware at 3.98 Gbit/s on the XGS 3300 and 941 Mbit/s on the XGS 136, its link full; a UDP stream with a drop rule, nothing let through.
https://npuforge.org/docs/measurements/inspect-2026-10-23/
So the honest limit now is the depth: past the first megabyte of a connection, Suricata sees nothing more of it.
Thanks again for pushing on this. It's a better project for it.
Abdelmonem
