opnsense
After reboot OPNsense 25.7, WireGuard stops working (connection don't work)
*** Tested and verified the issue in versions 25.1.10 and 25.7 *** *** Tested in bare metal and virtual machine with the same issue on both ***
After rebooting OPNsense WireGuard stops working, clients connect, everything looks normal, WireGuard status show client handshake, connection ports are ok, client can send data but wireguard don't send data back to client.
Routes are also correct, firewall rules are ok
The solution found is restarting the service from the Lobby->Dashboard or from CLI using the command: /usr/local/sbin/pluginctl -s wireguard restart
For some reason on boot WireGuard isn't properly configured and need a service restart after the system completely boots
Found another fix to the issue: creating a manual NAT outbound rule:
Firewall->NAT->Outbound Change to Hybrid outbound NAT Create a new manual rule Source: WG_VPN (the wireguard interface net) Source Port: * Destination: * Destination Port: * NAT Address: Interface address NAT Port: * Static Port: NO Add a description and Save->Apply
If you have servers with public IP address behind the firewall using NAT One-to-One in Destination put !RFC1918 (invert RFC1918) where RFC1918 it's an Alias with the three RFC1918 subnets (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or if you want use an alias with your subnets behind the firewall. Source: WG_VPN (the wireguard interface net) Source Port: * Destination: !RFC1918 Destination Port: * NAT Address: Interface address NAT Port: * Static Port: NO
Tested several times after reboot and Wireguard keeps working in versions 25.1.10 and 25.7.
This issue need urgent investigation from development team.
OPNsense 25.7 (amd64). Intel® Xeon™ D-2123IT 2.20Ghz Quad Core Network Intel® I350-AM4
Same here - WireGuard has problems with 25.7.1.
I had an interface assignment for WireGuard: wg1 to opt9. If I look at /tmp/rules.debug I see, that the rules for wg1 are added behind the rules for "wireguard". In 25.1 the rules for assigned interfaces like wg1 were added before the rules for "wireguard".
Short workaround on my side until this is fixed: moving the rules temporary from the assigned wireguard interface to wireguard group.
nothing to fix here, see also https://docs.opnsense.org/manual/firewall.html#processing-order for defined ordering.
Hi Ad.
Thanks for that quick reply. You are definitely right, a look at the order explained everything.
Allow me to ask one more quick question: Has anything changed in this regard? Related to WireGuard? All that's been done to the firewall has been updates. The rules themselves haven't changed for months. So this must have happened somewhere between 24.7.x and 25.7.x. I wouldn't have noticed anything about it in the changelog.
Could be 25.1.5 when the automation GUI was revamped when the problem of the wireguard group not properly registered was found and fixed for tangential reasons.
Commit with code change in question https://github.com/opnsense/core/commit/af5e9fcbf8806a966d0a955608f9f422491f238f#diff-272824023fc944200a274e93a299b5c67acb3cb0f7d7db2ffe60f9bdf0da4be9R55-R59 (GroupField.php)
Hi Franco.
That sounds plausible, and that's it. Thanks for clarifying. I will fix my rules to the correct way.
My part is fixed, thanks for your quick replies.
It doesn't seem to be a firewall order rules between rules on the interface or rules in the Wireguard Group, because upon restart wireguard service on the dashboard the issue is corrected. Nevertheless Firewall Rules should work in the interface and don't be dependent of the global Wireguard Group. It's something on boot that don't correctly configure the wireguard, or in the Outbound NAT or internally in the firewall rules.
We can keep this open. Feel free to provide additional data, test and confirm old versions that worked for you and let us know.
I'm seeing the same problem and after a reboot simply restarting the wireshark services (i have two wireshark instances fixes the problem. I'm not entirely sure I understand how the processing order would apply. My WireGuard group has no rules and thus only contains the automatically generated and floating groups none of which contain any blocks or allows. The two Wireguard instances each have block rules (to prevent traffic to interfaces the respective wireguard instance should be allowed to) and then general allow rules for internet traffic.
If i'm reading the order correctly the wireshark group does take precedence but i don't think there are any rules matches. If I add a "allow any to any" rule in the group it fixes the issue but that then takes precendence over the block rules on the individual instnace interfaces.
Am i misunderstanding https://github.com/opnsense/core/issues/9017#issuecomment-3159759141?
I was travelling two weeks ago before upgrading to 25.7 and my wireguard clients were working fine but I don't remember what specific version I was one before.
This is the current easiest fix and corrects the issue until further investigation by the OPNsense development team. Create a manual NAT outbound rule, because the issue, as far as I could see, it's with the return traffic :
Firewall->NAT->Outbound Change to Hybrid outbound NAT Create a new manual rule Source: WG_VPN (the wireguard interface net) Source Port: * Destination: * Destination Port: * NAT Address: Interface address NAT Port: * Static Port: NO Add a description and Save->Apply
If you have servers with public IP address behind the firewall using NAT One-to-One in Destination put !RFC1918 (invert RFC1918) where RFC1918 it's an Alias with the three RFC1918 subnets (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or if you want use an alias with your subnets behind the firewall. Source: WG_VPN (the wireguard interface net) Source Port: * Destination: !RFC1918 Destination Port: * NAT Address: Interface address NAT Port: * Static Port: NO
Since no one has updated this since August, I thought I'd leave a comment to confirm that this is still an issue on 25.7.8. Not able to connect to wireguard after rebooting the Opnsense machine. Restarting the wireguard service fixes the issue (until next reboot, i guess). I have not tried the solution proposed by @vicedriver .
No issues until now with the proposed fix, everything working fine after reboot
