OpenVPN server not working after rules migration

[buridi]

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.

[Monviech (Cedrik)]

Before the migration, create a copy of /tmp/rules.debug

After the migration after all legacy tules are removed and you applied the new rules, do another copy of /tmp/rules.debug

Compare the two (eg via "diff -u /old /new) and look for an exact difference in the openvpn rule.

[buridi]

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


[Monviech (Cedrik)]

I guess you have multi WAN and there is a missing reply-to in the differences here if I see correctly?

If it's related to this issue, can you post your details in there?
https://github.com/opnsense/core/issues/9702

[buridi]

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.

[Monviech (Cedrik)]

Hmm that is interesting, for a single gateway reply-to shouldn't be necessary, as the response packets should always leave the default gateway.

[Patrick M. Hausen]

[...] as the response packets should always leave the default gateway.

Unless you are accessing the service from a system connected to a broadcast network (Ethernet) WAN. In which case reply-to is the most frequent cause for people to come to the forum and ask about port forwards not working ;-)