Messages

26.1.2 has fixed the issue, thanks a lot

Yes, you're correct — there is a missing reply-to in the diff. However, this system is not using multi-WAN, it's a single-WAN setup.

There were no diff changes immediately after the migration and removal of legacy rules, and OpenVPN continued to operate normally. The problem appeared only after the reboot, at which point OpenVPN stopped working and changes appeared.

Code Select Expand

@@ -3,7 +3,7 @@
 set timeout { adaptive.start 0, adaptive.end 0 }
 set limit states 814700
 set limit src-nodes 814700
-set hostid *redacted*
+set hostid *redacted*

 # User Aliases
 openvpn_port = "{ <PORT> }"
@@ -260,9 +260,9 @@
 pass out log route-to ( vtnet1 *redacted* ) from {(vtnet1)} to {!(vtnet1:network)} keep state allow-opts label "957758128fdf40894358a49b5cf9a956" # let out anything from firewall host itself (force gw)
 pass out log route-to ( vtnet0 *redacted* ) from {(vtnet0)} to {!(vtnet0:network)} keep state allow-opts label "6125cb207f65033775d1069fdf6d0ccf" # let out anything from firewall host itself (force gw)
 # [prio: 400000]
-pass in quick on vtnet0 reply-to ( vtnet0 <IP> ) inet proto tcp from {any} to {(vtnet0)} port $openvpn_port keep state label "90b1793ad1e3aaf69cc63c3a1a95f49e" # Allow access to the OpenVPN server
-pass in quick on vtnet0 reply-to ( vtnet0 <IP> ) inet proto udp from {any} to {(vtnet0)} port $wireguard_port keep state label "71c969a762506cade7a91fff249e3008" # Allow access to the Wireguard server
-pass in quick on vtnet1 reply-to ( vtnet1 <IP> ) inet from {(vtnet1:network)} to {any} label "5e7e2e3b7941f655a66a08b6201f030f" # Default allow LAN to any rule
-pass in quick on vtnet1 inet6 from {(vtnet1:network),fe80::/10} to {any} label "47209b362dadfa154852432dab639539" # Default allow LAN IPv6 to any rule
-pass in quick on ovpns1 inet from {(ovpns1:network)} to {any} keep state label "ca18d9e6ad8e1c5076a3f87df5004a58" # Allow ALL from OpenVPN
-pass in quick on wg0 inet from {(wg0:network)} to {any} keep state label "b2bf440d963b062196da612647148759" # Allow ALL from Wireguard
+pass in quick on vtnet0 inet proto tcp from {any} to {(vtnet0)} port $openvpn_port keep state label "15546a58-4efd-47e7-9c51-15327fa0c305" # Allow access to the OpenVPN server
+pass in quick on vtnet0 inet proto udp from {any} to {(vtnet0)} port $wireguard_port keep state label "61bf03eb-020e-4a56-84db-e7fd93f7c0a4" # Allow access to the Wireguard server
+pass in quick on vtnet1 inet from {(vtnet1:network)} to {any} keep state label "4224f34a-5353-4cff-b149-939b00036c37" # Default allow LAN to any rule
+pass in quick on vtnet1 inet6 from {(vtnet1:network),fe80::/10} to {any} keep state label "d98614bd-208b-45f3-85eb-5a55f3c16325" # Default allow LAN IPv6 to any rule
+pass in quick on ovpns1 inet from {(ovpns1:network)} to {any} keep state label "86029448-ea5d-4c61-8762-a9f9a5f4bd84" # Allow ALL from OpenVPN
+pass in quick on wg0 inet from {(wg0:network)} to {any} keep state label "9b28cc31-d161-4028-a2d6-1415e1ded707" # Allow ALL from Wireguard


I'm experiencing an issue with OpenVPN after upgrading OPNsense from 25.7.11 to 26.1.

My setup is fairly simple: OpenVPN and WireGuard servers.

The upgrade itself completed without any problems, and everything was working correctly until the rules migration step.

After the rules migration:

OpenVPN stopped working completely

WireGuard still works, but the system feels unstable — the dashboard refreshes with noticeable pauses/freezes


To rule out an upgrade issue, I also:

- Installed a clean 26.1
- Imported the configuration
- Performed the rules migration (checked the list of rules, seemed valid)

Unfortunately, the result is exactly the same.

At this point, it clearly looks related to the rules migration process, but I'm not sure where to look or how to fix it.

Has anyone experienced something similar, or can advise what to check or how to resolve this?

Thank you in advance for any help.

Hi everyone,

I've set up a transparent proxy with Squid on OPNsense following several common guides. This includes creating an internal CA in OPNsense and using it in Squid for SSL inspection.

The setup works fine for most clients and browsers. However, on Windows I'm seeing errors when using curl or other applications relying on WinSSL:

Code Select Expand

channel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate

From what I understand, Windows is trying to perform a revocation check (CRL/OCSP) for the intercepted certificate and failing.

Has anyone dealt with this before?

Is there a recommended way to configure OPNsense/Squid to avoid or resolve this issue?

Should I be doing something different with my internal CA or Squid's SSL settings (CRL, OCSP stapling, etc.) to satisfy Windows?

Any advice or example configurations would be greatly appreciated.

Thanks!