Hi together,
just updated to 24.1.2 and noticed that wireguard will stop receiving traffic after initial handshake.
Logs on Debug sadly do not spit anything specific out:
2024-02-20T18:24:59 Notice wireguard /usr/local/opnsense/scripts/Wireguard/wg-service-control.php: ROUTING: entering configure using 'opt3'
2024-02-20T18:24:59 Notice wireguard wireguard instance vpn.fwh02.local (wg1) started
2024-02-20T18:24:59 Notice wireguard wireguard instance vpn.fwh02.local (wg1) stopped
2024-02-20T18:24:59 Notice wireguard wireguard instance vpn.fwh02.local (wg1) can not reconfigure without stopping it first.
2024-02-20T18:24:52 Notice wireguard /usr/local/opnsense/scripts/Wireguard/wg-service-control.php: ROUTING: entering configure using 'opt3'
2024-02-20T18:24:52 Notice wireguard wireguard instance vpn.fwh02.local (wg1) started
2024-02-20T18:24:51 Notice wireguard wireguard instance vpn.fwh02.local (wg1) stopped
2024-02-20T18:24:51 Notice wireguard wireguard instance vpn.fwh02.local (wg1) can not reconfigure without stopping it first.
Looking into the system logs I see an issue with the CARP ip. Disabled and Removing this does not help:
2024-02-20T17:54:11 Error opnsense /usr/local/opnsense/scripts/interfaces/carp_set_status.php: The command '/sbin/ifconfig wg1 '10.0.1.1'/'24' alias vhid '3'' returned exit code '1', the output was 'ifconfig: SIOCGVH: Operation not supported'
2024-02-20T17:54:11 Error opnsense /usr/local/opnsense/scripts/interfaces/carp_set_status.php: The command '/sbin/ifconfig wg1 vhid '3' advskew '0' advbase '1' pass '**PASSWORD**'' returned exit code '1', the output was 'ifconfig: SIOCGVH: Operation not supported'
Does anyone face the same issue?
Same here
Did not look into the log files. Wireguard is needed here urgently. Rolled back to snapshot before the upgrade.
I could the the client beeing connected in the OPNsense web gui. But no traffic went through.
Faced wireguard errors and not connecting.
Looks like the new code cannot handle dns resolutions and requires ip address for Endpoint address.
My problem was that I could not connect to the wireguard server on the opnsense.
Client was my mobile phone.
I saw the connection in the opnsense webinterface but no data was transmitted.
I also have a tunnel to an external vpn provider for selective routing. At least the gateway of the provider showed up green in the opnsense interface. However did not try if actually data is transmitted.
All a bit strange. Is this perhaps a kernel issue?
# opnsense-update -kr 24.1
# opnsense-shell reboot
Cheers,
Franco
Quote from: franco on February 20, 2024, 08:11:23 PM
All a bit strange. Is this perhaps a kernel issue?
# opnsense-update -kr 24.1
# opnsense-shell reboot
Cheers,
Franco
Tested this, still not working (sadly).
Within my android client i see:
"WireGuard/GoBackend/vpn: peer(hash) - Receiving keepalive packet."
Still nothing within the wireguard logs on opnsense
Quote from: franco on February 20, 2024, 08:11:23 PM
All a bit strange. Is this perhaps a kernel issue?
Assuming the only difference between between 24.1.1_14 and 24.1.2 is the if_re EEPROM patch hen I've seen no regressions and WG tunnels are working everywhere, both server/clients and clients to upstream GWs
Unsure if I'm missing something in between 24.1.1_38 and 24.1.2.
This is very unsubstantial indeed. Could the reboot have killed it having broken the box setup without noticing some time before?
The thing is this would have turned up at least in reddit by now, but everyone is happy over there.
Cheers,
Franco
I will try again tonight or tomorrow and then report here.
Not problems with 24.1.2 updates
I updated 4 systems to 24.1.2, all with WireGuard site-to-site links between the systems.
Updates when smoothly and WireGuard connected without any problems
Johan
I updated again and did some testing.
Outgoing Wireguard works. So selective routing to an external VPN provider.
Incoming Wireguard does not work. I see the connection in the OPNsense WebGui, but no data is transferred.
Then I disabled Wireguard and enabled it again. After this everything works normally.
When I reboot, it is broken again until I restart Wireguard.
One strange thing: I have two tunnel configurations. A full and a split tunnel.
Full tunnel allowed IPs: 0.0.0.0/0,::/0
Split tunnel allowed IPS: 10.21.0.0/16
After the reboot, the full tunnel does not work. From my Android phone and my iPad I cannot access an external site and also nothing of my private 10.21... network.
However with the split tunnel, I can access my private network.
Another thing:
I rebooted a few times. It ended up with the following behaviour:
"Starting Unbound DNS" took several seconds.
If this is happening, the boot completely hangs with "Configuring Wireguard VPN..."
See attached screenshot.
I rolled back again to 24.1.1 and no problems.
I was a little hesitant updating while reading about the possible wireguard problems, but with no complaints at reddit i decided to give it a shot. All went well and smooth. Everything is running, including Wireguard. thnx!
Analyzed further on my end and noticed that wireguard on my backup fw was still working (even after upgrading).
Inspected firewall rules and noticed that all rules for the wireguard interface went missing.
re-created the rules, now wireguard is exchanging traffic again and working.
Now only CARP for wireguard is not working.
I have issues with my wireguard side-to-side too. I cannot figure out how to debug the troubles. I found this thread: https://forum.opnsense.org/index.php?topic=14279.0 mentioning to use:
/usr/local/etc/rc.d/wireguard start
This does not seem to work under 24.1.2
How can I get the debug logs from wireguard? The Interface does not print all of the logs =(
I also experienced issues after update - Wireguard tunnel works, but routes to other subnets fail (VLANs) - running OPNSense as virtual machine under Proxmox - always take a snapshot before an update - so rolled back to previous version and everything back to normal!! So something is affecting the Wireguard tunnels and routing . . .
Replying here because I also have a couple of pre-existing Wireguard tunnels.
In my case, upgrading from 24.1.1 --> 24.1.2 went smoothly, without errors, and the WG tunnels continue to work as-normal post upgrade.
My overall setup is 2 SOHO networks at different sites, each with a bare-metal OPNsense install on PCengines APU2E4 box, connected to a separate VLAN-capable switch. One site has WAPs running OpenWRT, the other with Unifi firmware. (Running as pure access points, no routing, firewalling, or services on the WAPs.)
One site also has 4 VLANs and 3 different wifi SSIDs associated w/ 3 of the VLANs. Everything seems to continue to work fine.
You could try reverting this one:
https://github.com/opnsense/core/commit/3340a32473
But it's basically a can of worms because it fixes a non-operational issue on the surface, which points to lack of proper setup if it causes breakage... perhaps meddling with VIPs or a left-over interface IPv4 configuration (this has been discontinued but some old configs may still have it) which is not optimal at the moment.
# opnsense-patch 340a32473
Cheers,
Franco
with multi gateway setup, wg clients, wg servers, vlans.. no problem. i've had vpn stuck at boot only if dns race condition was a problem (e.g. adguard as a main dns; unbound can't resolve if not routed to wan).
Quotei've had vpn stuck at boot only if dns race condition was a problem (e.g. adguard as a main dns; unbound can't resolve if not routed to wan).
I think this could also be the problem for my hang during boot.
However also only with 24.1.2.
I just have unbound, howver with "DNS over TLS" resolving to Cloudflare enabled.
Any way to dive into this? Do I just have to wait for a certain timeout? It seemd to completely stuck at "Configuring Wireguard VPN..." and I was not able to start OPNsense at all...
Quote from: franco on February 21, 2024, 02:15:36 PM
You could try reverting this one:
https://github.com/opnsense/core/commit/3340a32473
But it's basically a can of worms because it fixes a non-operational issue on the surface, which points to lack of proper setup if it causes breakage... perhaps meddling with VIPs or a left-over interface IPv4 configuration (this has been discontinued but some old configs may still have it) which is not optimal at the moment.
# opnsense-patch 3340a32473
Cheers,
Franco
I just created the 24.1.1 installation.
I was running OPNsense on bare metal and now switched to Proxmox.
I described the way I did it in this post https://forum.opnsense.org/index.php?topic=38942.msg190682#msg190682 (https://forum.opnsense.org/index.php?topic=38942.msg190682#msg190682).
Anything I can check in my config that could be a potential problem?
> Anything I can check in my config that could be a potential problem?
Just revert the patch as stated above. That's enough to diagnose the issue on 24.1.2.
> # opnsense-patch 3340a32473
Cheers,
Franco
# opnsense-patch 340a32473
or
# opnsense-patch 3340a32473
I guess it is the second to fit to the Github link correct? Just to be double-safe....
Yeah, the one that works is preferable. :) Sorry for the typo.
OK. Following behaviour:
1. Updated again to 24.1.2 -> Wireguard did not work.
2. Applied the patch and rebooted. -> Wireguard did not work
3. Restarted Wireguard -> Wireguard worked
4. Reboot again -> Wireguard works
Until now. Everything was checked with my Android phone.
5. Reboot again -> Wireguard does not work on Android. However, iPad works.
A few connects and disconnects with both, Android and iPad. Suddenly both of them are working.
I tested Wireguard with the mobile LTE network but also out of my WLAN. Both showed the same behaviour.
Either both work, or both do not work.
Also both of my tunnes, split and full, showed the same behaviour.
This is difficult to nail down...
Anything that I could test now with the patched 24.1.2 installation?
Otherwise I would revert back to 24.1.1, reinstall 24.1.2 and continue testing to see if it is the same unstable behaviour....
Well it already sounds like a configuration instability. The following bullet points would be helpful:
(1) Do you use DNS entries as endpoint addresses?
(2) Do you use tunnel addresses on your instances?
(3) Do you have allowed IPs on your peers?
(4) Do you have the instances assigned as interfaces?
(5) If yes for (4) do you have an IPv4/IPv6 mode set in the interface?
(6) If yes for (4) do you have VIPs assigned to these interfaces?
Cheers,
Franco
Hello,
I also have some strange problems after the update. I don't want to hijack this thread, but I think it might be the same origin that manifests differently for everyone.
OPNSense A:
Update and direct reboot
Everything seemed to work fine, but later today (day after update) I received error messages that some servers were not reachable - cause a DNS problem. According to the GUI, Unbound was not running - BUT the Internet via browser on the clients was working, so part of the DNS server must have been running. A reboot of OPNSense seemed to have fixed the problem - but I'll have to wait and see tomorrow.
OPNSense B:
Update and direct reboot
- A device can no longer connect to its cloud server.
I can address the device within my internal network (several VLANs routed via OPNSense), so the routing must basically work
- Internet access on my test client worked, websites could be loaded
- a "ping google.de" on the same test client shows no connection
- a "tracert google.de" stops at the OPNSense
- DNS worked, as both of the above commands were able to resolve an IP. I tried it with 3 different hosts, always the same behavior
- a restart of Unbound brought no change
- I checked to see if there was another update available on the OPNSense - the update routine could not connect to the update server either
After rebooting the OPNSense, everything seemed to work again (device had cloud connection, ping worked again, tracert worked again) - I did no other changes!
P.S. My Wireguard worked at least after the second reboot, before that I don't know.
Both OPNSense machines have been running for several years, nothing was changed in the configurations before the update. So it seems that something is sporadically unstable.
Quote(1) Do you use DNS entries as endpoint addresses?
Yes, I have a dynamic IP, so I have a dyndns domain pointing to my OPNsense router.
Quote(2) Do you use tunnel addresses on your instances?
Yes, this is the entry for the respective instance: 10.21.4.1/24,fd21:04::01/64
And allowed IPs for the peers. For example: 10.21.4.4/32,fd21:04::04/128
This addresses are then in the interface section of the client.
Quote(3) Do you have allowed IPs on your peers?
Yes, different for split and full tunnel:
Full tunnel allowed IPs: 0.0.0.0/0,::/0
Split tunnel allowed IPS: 10.21.0.0/16
Quote(4) Do you have the instances assigned as interfaces?
Yes
Quote(5) If yes for (4) do you have an IPv4/IPv6 mode set in the interface?
IPv4 and IPv6 Configuration Type set to "none"
Quote(6) If yes for (4) do you have VIPs assigned to these interfaces?
No
Reading the questions:
I just realized that I completely forgot about the DynDNS. I mean the time it needs to update.
I was super quick with testing. What a shame, if this would be the reason..... :-[
So I just rolled back to 24.1.1, updated again to 24.1.2 (without the patch).
I will now test again and having a look at the DynDNS topic....
This is potentially a side-effect of something else: A while ago, there were reports of services not starting after a reboot. Franco suspected a race condition.
I experienced something to this extent after upgrading 4 instances on one of them: HAproxy did not start correctly.
This could be fixed by "Reload all services" from the console, a full reboot was not necessary.
In my case, this may have been caused by a slow IPv6 DHCP on my ISPs side on a DS-Lite connection.
QuoteReading the questions:
I just realized that I completely forgot about the DynDNS. I mean the time it needs to update.
I was super quick with testing. What a shame, if this would be the reason..... :-[
So I just rolled back to 24.1.1, updated again to 24.1.2 (without the patch).
I will now test again and having a look at the DynDNS topic....
So...
After a clean update to 24.1.2, a few minutes of just waiting and doing nothing, everyhting works nicely... :)
So DynDNS could be an explanation....
However, there might have also been something else. Especialle because I was not able to start OPNsense yesterday at all.... no idea....
Thanks for the great support!
Just made a litte PayPal donation the the OPNsense project.
I am on 24.1.2 and i am experiencing wireguard trouble. about twice a day my wireguard stops working. i am using the android app and pass everything through to my opnsense box. once it stops working i have to go into the opnsense gui and restart the wireguard service. it then starts working for about another half a day or so.
i am not sure what other info is needed to help me diagnose/fix so please let me know and i will provide.
thank you all!
I'm wondering if this might be related to the issues I've been seeing with Suricata 7:
https://forum.opnsense.org/index.php?topic=38989.0
For people who are having trouble with Wireguard since the 24.1.2 update, can you SSH into your OPNSense box and check /var/log/suricata/eve.json to see if Suricata is dropping your Wireguard traffic?
i can give this a try. what am i looking for?
Quote from: apoorva on February 22, 2024, 04:47:27 PM
I am on 24.1.2 and i am experiencing wireguard trouble. about twice a day my wireguard stops working. i am using the android app and pass everything through to my opnsense box. once it stops working i have to go into the opnsense gui and restart the wireguard service. it then starts working for about another half a day or so.
i am not sure what other info is needed to help me diagnose/fix so please let me know and i will provide.
thank you all!
Did you try disconnecting/reconnecting the phone's WG app instead - without touching the FW ?
Quote from: apoorva on February 23, 2024, 05:30:20 AM
i can give this a try. what am i looking for?
Just disable Suricata if you have it enabled and look what happens :)
Quote from: newsense on February 23, 2024, 07:08:55 AM
Quote from: apoorva on February 22, 2024, 04:47:27 PM
I am on 24.1.2 and i am experiencing wireguard trouble. about twice a day my wireguard stops working. i am using the android app and pass everything through to my opnsense box. once it stops working i have to go into the opnsense gui and restart the wireguard service. it then starts working for about another half a day or so.
i am not sure what other info is needed to help me diagnose/fix so please let me know and i will provide.
thank you all!
Did you try disconnecting/reconnecting the phone's WG app instead - without touching the FW ?
yes. toggling that on the phone wireguard app does not work. i have had to restart the service in opnsense.
I think this could not be related to this opnsense/wireguard version. I have had this months ago.
I solved this by adding in VPN-Wireguard-Settings-Peers:
Keepalive interval = 25
hope that helps in your situation also.
Having the same wireguard issues with too.
Also having wg issues here but only with my single site-to-site tunnel.
No issues immediately after the upgrade, the next day intermittent connection loss that progressively got worse. Initiated a reboot at the remote site and now the tunnel just won't establish at all.
My wg road warrior setup seems to be functioning ok though...
It looks like different issues and configurations are discussed in this thread. Can anybody tell me whether wireguard is stable in Opnsense 24.1.2_1?
I have three firewalls with various WireGuard tunnels running 24.1.2_1. All are working perfectly fine.
That does not in any way guarantee that your experience won't be different, though. Also I am running neither Suricata nor Zenarmor.
Strangely, my issue seems to have resolved itself after a power outage. I assume the reboot is what fixed it... I had already tried a full reboot though and no config changes have been made.
Quote from: Patrick M. Hausen on February 26, 2024, 06:17:09 PM
I have three firewalls with various WireGuard tunnels running 24.1.2_1. All are working perfectly fine.
That does not in any way guarantee that your experience won't be different, though. Also I am running neither Suricata nor Zenarmor.
Thanks for your report. I have upgraded to Opnsense 24.1.2_1 this morning. No issues with wireguard till now (I am also not using Suricata or Zenarmor).
Hello everyone,
since the update to 24.1.2 I have also had some problems.
Wireguard connection is established, I can access the Opnsense network with my cell phone.
The connection to the remote firebox is still established, but I can't access any devices.
The Wireguard app is also faulty in the extensions.
The 3cx telephone system also has DNS problems.
Does anyone have a solution?
How to get back to firmware 23?
Wireguard is part of the base system now. Got to System > Firmware > Status and pick "reset all local conflicts" or some such from the menu in the bottom right.
Does something else have to be set?
The OPNsense cannot find the remote network.
QuoteC:\Users\Alexander>tracert 192.168.45.254
Routenverfolgung zu 192.168.45.254 über maximal 30 Hops
1 * 1 ms 1 ms OPNsense [192.168.40.254]
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
5 * * * Zeitüberschreitung der Anforderung.
6 * * * Zeitüberschreitung der Anforderung.
7 * * * Zeitüberschreitung der Anforderung.
8 * * * Zeitüberschreitung der Anforderung.
9 * * * Zeitüberschreitung der Anforderung.
10 ^C
C:\Users\Alexander>
Hallo every1
Same here i got issues with WireGuard. After upgrading to 24.1.3 i can not get handshake. I reinstalled 24.1 and everything works again.
I hope this issue could be fixed
Add me to the no problems with wireguard list. I'm on 24.1.2_1.
(1) Do you use DNS entries as endpoint addresses?
I use a dynamic DNS entry for the server endpoint.
(2) Do you use tunnel addresses on your instances?
I have a /24 tunnel address set on my server instance and a /32 on my client.
(3) Do you have allowed IPs on your peers?
I have my clients configured as peers on the server instance and 0.0.0.0/0 for my client allowed peers.
(4) Do you have the instances assigned as interfaces?
I have my server instance assigned as an interface.
(5) If yes for (4) do you have an IPv4/IPv6 mode set in the interface?
Both IPv4 and IPv6 are set to None on my interface. Also, I don't use IPv6 for my dynamic DNS entry.
(6) If yes for (4) do you have VIPs assigned to these interfaces?
N/A
Hope this helps, and I'm happy to try and provide more info for comparison/troubleshooting.
Hi,
I also had a problem with Wireguard after the upgrade, I solved the problem:
1)
Firewall > NAT > Outbound:
Changed: Automatic outbound NAT rule generation
(no manual rules can be used) >>> Hybrid outbound NAT rule generation
(automatically generated rules are applied after manual rules)
2) Added rule for Wireguard ip pool.
@Valentinas
What rule did u add to the wireguard ip pool? Can post a pic or provide details?
Quote from: valentinas on March 10, 2024, 09:57:52 AM
Hi,
I also had a problem with Wireguard after the upgrade, I solved the problem:
1)
Firewall > NAT > Outbound:
Changed: Automatic outbound NAT rule generation
(no manual rules can be used) >>> Hybrid outbound NAT rule generation
(automatically generated rules are applied after manual rules)
2) Added rule for Wireguard ip pool.
Hallo friend
I used hybrid iin my configuration still issues after the update. My surfshark stopped creating handshake. I went back to version 24.1.
If u have any other tip please let me know
(https://i.postimg.cc/G8Mk01k5/IMG-3258.jpg) (https://postimg.cc/G8Mk01k5)
Hi,
I have been running Opnsense in production about 1 week now. It has been working fine, the latest version
which is today available (i cant see the version anymore but something 24 cos I do not have opnsense anymore).
So every time when I tried to use WireGuard the opnsense goes in a state
where I am not able to fix it, only by restoring old version from snapshot without WireGuard installed.
So I am not able to use Opnsense in production untill wireguard works.
Every time when I have tried to install Wireguard, it lets me to got to point where I can make tunnel from my laptop to opnsense, so I can ping it and access the web console from my laptop browser with IP 10.0.0.2.
It works usually for awhile, but then suddenly all traffic flow stops. Websites goes down and tunnel does not work, also web console does not work. Only connection is cloud provider console straight to opnsense, but I dont have experience to fix anything there yet.
I am not sure is it a configuration problem, but this is already second time restoring Opnsense from snapshot.
Now I took it totally away from my cloud setup, cant run it anymore if wireguard is messing everything.
Maybe I will try some day some other VPN.
I've resolved my initial wireguard problems. Adding my experience to what seems like a variety of issues. Without any hard evidence, mine
seems to have been related to old config information that I was able to clear out.
I upgraded to 24.1_3 from 23.7 and immediately experience wireguard problems. No connections worked, no handshake. My wireguard logs showed this entry whenever I restarted the service.
/usr/local/opnsense/scripts/Wireguard/wg-service-control.php: The command '/sbin/route -q -n add -'inet' '/' -interface 'wg1'' returned exit code '68', the output was 'route: bad address:'My steps to resolve, some may be related, some probably not:
- deleted and rebuilt my wg instance from scratch. This moved the interface from wg1 to wg0. No change. Same log entries.
- Realized I needed reassign the new wg0 interface in Interfaces --> Assignments. Above error log entries went away and changed to
2024-03-17T21:57:03-07:00 Notice wireguard wireguard instance main (wg0) started
2024-03-17T21:57:03-07:00 Notice wireguard /usr/local/opnsense/scripts/Wireguard/wg-service-control.php: ROUTING: entering configure using 'opt7'
2024-03-17T21:57:03-07:00 Notice wireguard wireguard instance main (wg0) can not reconfigure without stopping it first.- rebuilt all peer entries from scratch. No change. Wireguard port connections were allowed through the firewall and the handshake occurred, but no traffic, LAN or Outside.
- I've got all DNS running through PiHole and noticed all DNS traffic was being denied through the wireguard interface despite being allowed in the interface rules.
- I temporarily allowed all through the interface and traffic started flowing, including all the earlier rules. I turned off the allow all rule, and everything continues to work.
Based on the above, it seems like some conflicting/bad config info got cleared out. My setup is similar to CJ's which he noted earlier.
Quote from: CJ on March 09, 2024, 03:38:47 PM
Add me to the no problems with wireguard list. I'm on 24.1.2_1.
(1) Do you use DNS entries as endpoint addresses?
I use a dynamic DNS entry for the server endpoint.
(2) Do you use tunnel addresses on your instances?
I have a /24 tunnel address set on my server instance and a /32 on my client.
(3) Do you have allowed IPs on your peers?
I have my clients configured as peers on the server instance and 0.0.0.0/0 for my client allowed peers.
(4) Do you have the instances assigned as interfaces?
I have my server instance assigned as an interface.
(5) If yes for (4) do you have an IPv4/IPv6 mode set in the interface?
Both IPv4 and IPv6 are set to None on my interface. Also, I don't use IPv6 for my dynamic DNS entry.
(6) If yes for (4) do you have VIPs assigned to these interfaces?
N/A
Hope this helps, and I'm happy to try and provide more info for comparison/troubleshooting.
Quote from: zzyzx on March 18, 2024, 05:16:42 PM
I upgraded to 24.1_3 from 23.7 and immediately experience wireguard problems. No connections worked, no handshake. My wireguard logs showed this entry whenever I restarted the service.
I'm having an issue where after an update I am able to get handshakes but no traffic routes. I hadn't changed configuration, so I assume the update broke something.
It appears that wireguard traffic from opnsense to client is severely curtailed for some reason. e.g., I see 156 bytes transferred from opnsense to client, but much more (and it ticks upward) from client to opnsense. The trick from early in the thread to restart the wireguard process did not change that behavior for me.
Looking through the firewall rules, I don't see anything specifically referencing either the wireguard IP pool nor the interface, so I suspect that there was some automatically-generated rule that is no longer being automatically generated.
I solved my issue by deleting the wg0 interface, disabling wireguard, edited the configuration file to set the wireguard instance from 0 to 1, and reassigning a new wg1 interface. I think there may have been an interface group definition problem such that wg0 was not part of the group, and therefore the floating firewall rule that allowed access to/from that interface didn't properly apply.
Any news here?
I upgraded from 24.1.1 to 24.1.5_3 and my wireguard got broken too.
I can made a handshake but no traffic will be routed.
After a rollback to 24.1.1 all works fine.
...updated some OPNsenses to latest just now and all WG tunnels are doing just fine.
I noticed that my wg0 interface was missing after the upgrade. When I created a new interface a got a new interface (wg1 in my case) but I can't set a static ip address for that...
So I rolled back and all is working (and the wg0 is found)
EDIT: I run another attempt to upgrade to 24.1.6 and it worked. My wg0 interface is still there (I have to remove the static IP). But it takes me several attempts to get the update successfull with wg0. The update process dies 2 times (in each approach) and I have a dependency problem in one of them. In one approach (that I must throw away and restore the backup) I have every time when I search for an update an exception...
can someone explain what exactly needs to be done to get wireguard running fine again?
I have a site2site VPN that is not working after upgrade anymore (to mobile clients is working).
I tried a lot but don't get it solved.
Currently I am getting:
/usr/local/opnsense/scripts/Wireguard/wg-service-control.php: The command '/sbin/ifconfig 'wg2' inet '192.168.200.1'/'24' alias ' returned exit code '1', the output was 'ifconfig: ioctl (SIOCAIFADDR): File exists'
Update: that was due to VIP that I tried to set as I saw something in some threads.
When I am creating a gateway and activating a route I am not getting any error but it's still not working....
If I roll back to old config I am getting:
/usr/local/opnsense/scripts/Wireguard/wg-service-control.php: ROUTING: gateway IP could not be found for 192.168.200.0/24
Thanks,
Tobi
I am experiencing the same issue. After updating to OPNsense 24.1.6, my WireGuard setup stopped working. I have multiple sites, and I'm concerned because some sites work, while others do not.
The error message I'm getting on both sites is:
/usr/local/opnsense/scripts/Wireguard/wg-service-control.php: ROUTING: not a valid opt3 interface
Did you open new threads and posted config? Too many different problems here
Hi all,
Has a fix been determined?
I've just upgraded (If one can call it that), from 23.7.12 to 24.1.6 - Same issue as identified, wireguard achieves a handshake but does not pass data through, despite having all the same settings that worked in 23.7.12.
In my case, I'm using wireguard for general policy routed nord VPN (Have used this setup for about 1.5 years without problems at gigabit speeds).
One thing I have noticed, which could be contributing to the problem:
My previous WG interface, I tried changing the MSS value, and it provides an error message "Cannot assign an IP configuration type to a tunnel interface" - Which is interesting as this was not an issue in 23.7.12. After seeing this, I checked my DHCPv4 for the WG tunnel, and noticed this is not enabled due to not having an IP range. Not sure if this is the root of the problem or not, but thought I'd mention it here if it helps.
I can confirm all the following are in tact:
Gateway
WG interface
WG peer
WG instance
WG handshake
FW rules
NAT rules
Cheers
[EDIT: Major breakthrough, I changed my WG interface to IPV4 configuration type to NONE and the tunnel started working immediately]
I recently found out my wireguard does not work anymore. I only use it rarely. The android client log shows handshake not completed.
I went through every step of the Road Warrior Setup and it all seems to be fine except that normalization rule was missing. Didn't help to add this.
Updated to 24.4 Business last week from the 23 branch. Late to the party a bit. Wireguard not working for me as well. At this point I'm going to delete the WG interface, instances and redo WireGuard from scratch as I've seen others say that's what they had to do. My Clients connect and start sending data but data not received. I tried to fix the current config by ensuring it was aligned with the road warrior docs but that didn't fix it.
UPDATE:
So... I'm an idiot. My issue was the OPNSense DynDNS client wasn't working and had reverted to native backend instead of ddclient. Firewall IP resolution from the client was wrong. WireGuard working now.
I managed to resolve this issue. Most of the S2S VPN connections were using the DNS name of the peer instead of the IP address. I am using DNS over TLS, which somehow didn't resolve these two VPN sites correctly. I changed their DNS names to IP addresses, and they started working. I thought I'd share my resolution here.
Yup, after the upgrade DOT DNS couldn't resolve in order to load Wireguard.
I've tried lowering DNSSEC standards and it helped, at least the BOGUS or NXDOMAIN responses lasted "only" 10sec, so the boot was fast, and WG successful.
I will not use IPs. IPs change.
I just hope Adguard will move to the early part of the boot sequence, so I don't need to use Unbound just to satisfy (unreliably) the boot process.
Quote from: 36thchamber on May 22, 2024, 02:05:22 AM
Yup, after the upgrade DOT DNS couldn't resolve in order to load Wireguard.
I've tried lowering DNSSEC standards and it helped, at least the BOGUS or NXDOMAIN responses lasted "only" 10sec, so the boot was fast, and WG successful.
I will not use IPs. IPs change.
I just hope Adguard will move to the early part of the boot sequence, so I don't need to use Unbound just to satisfy (unreliably) the boot process.
i have resolve it before with change the dns name of the extern site to the ip, after the last update OPNsense 24.1.7_4-amd64 has crashes it.
i am using DOT too.
Edit: ive got it resolved. Make sure to check the wireguard plug in. Somehow it disappeared. Reinstall it
I have the same problems with wireguard
But today I lost a little more time.
I updated to the latest version OPNsense 24.1.8-amd64
and it stopped working.
It says status as connected but I can't do any ping.
I reviewed all the firewall rules, etc., etc., by chance I restart the Lobby>Dashboad menu in the services menu... I restart wireguard and the VPN works again without problems.
After restart it stops working again.
I do the same procedure again, go to Lobby>Dashboad in the services menu... I restart wireguard and the VPN works again without problems.
Something about the startup that goes wrong.
For those with such issues I suggest adding firewall rules for each wireguard specifically allowing traffic to itself. In my case it solved the handshake but no ping/traffic issues.
Spent a long time debugging and that solution solved my issue. I saw the traffic was getting there with tcpdump but wasn't answering and setting rules, when appropriate, allowing traffic for example from wg0 to/form wg0 solved those issues.
Somehow the default/automatic rules were blocking traffic between the wireguard clients or client / server.
Quote from: voodoopt on June 02, 2024, 04:45:03 PM
I have the same problems with wireguard
But today I lost a little more time.
I updated to the latest version OPNsense 24.1.8-amd64
and it stopped working.
It says status as connected but I can't do any ping.
I reviewed all the firewall rules, etc., etc., by chance I restart the Lobby>Dashboad menu in the services menu... I restart wireguard and the VPN works again without problems.
After restart it stops working again.
I do the same procedure again, go to Lobby>Dashboad in the services menu... I restart wireguard and the VPN works again without problems.
Something about the startup that goes wrong.
what exaclty did you do?
I've did the upgrade from 23.7.6 to 24.1.8 and my wireguard tunnel (incoming) stopped working, the site2site is still okay.
Incoming tunnels are coming up (latest handshake is shown at opnsense) and i've got traffic in the firewall logs on the WG interface - but the "return route" seems not to be working.
Upgrading here to OPNsense 24.1.9-amd64 just now and wg stops for me as well , restart via service fix the issue.
[deleted]
Quote from: xkpx on June 18, 2024, 01:10:34 PM
Upgrading here to OPNsense 24.1.9-amd64 just now and wg stops for me as well , restart via service fix the issue.
I can confirm same issue with bare metal install - updated to latest 24.1.9_4 - Wireguard does not work after fresh start - need to restart service manually - and many times I get handshake, but only local traffic - not internet
Very unstable compared to previous releases . . .
I can confirm same issue, update to 24.1.9 opnsense webgui do not start up, not internet, wireguard must be disable an all service must be restart
It doesn't really help when people with problems just jump in without further informations.
Best to open a new thread with following informations:
- Last known working version
- Scenario
- Problem description
- Screenshots of Instance and Endpoint details
Please be sure there is no general problem with the wireguard implementation so most of the time (99%) it's a configuration issue which pops up due to some other event.
Hi all,
Running 24.1.10 and running out of hours I can spend on trying to get Wireguard to work reliably so back to the good old trusted OpenVPN it is for the time being.
I noticed that OPNsense adds this route:
0.0.0.0/1 link#39 US wg0
My intention is that nodes on the LANs can use a gateway group with the wg0 interface being one of the gateways and for that to work I need to add 0.0.0.0/0 to the AllowedIPs.
Does anyone know what the logic is for adding that 0.0.0.0/1 (ie. (only) half of the internet) route?
OPNsense no longer works correctly with WireGuard, the most recent successful build of OPNsense with Wireguard was "23.1.11_1" (LTS EOL for me).
All new builds can not raise tunnels and work after OPNsense machines go to suspend state VM ESXi, priorities of gw, dns, firewall, nat, interfaces and other services work incorrectly and can not restart ordering/healthcheck services themselves.
And in version "23.1.11_1" I didn't even have to install KeepAlive on the tunnel WireGuard, all LAN networks (vLAN vmxnet3 / USB 3.1 Ethernet 1Gbps) worked very well.
OPNsense with WireGuard support has become a low-grade low-quality product. Maybe there is a race-condition in the new versions, I don't update releases anymore. Gradual update to the latest release for today does not give any promising results.
Normalization traffic of Bridge(between vLAN networks)/WG/vLAN(single without Bridge) strafe with MSS/MTU so that vmxnet3 packets pass optimally, interfaces are also configured with MSS/MTU. Use Manual Outbound NAT rule generation for WireGuard (I do not use assigned interfaces to WireGuard, and everything works "23.1.11_1") no leaks DNS/traffic without tunnel for LAN/bridge + DNS/DoH/DoT redirected to local path zoned DNS via Firewall rules.
+ split DNS is sorely lacking for zone splitting of networks, like this https://fedoramagazine.org/systemd-resolved-introduction-to-split-dns/
The problems are particular to your installation and configuration. I as well as numerous other people run dozens of Wireguard tunnels all over their data centers with version 24.7 and/or 24.10.
Instead of just claiming "it's broken! OPNsense bad!" what about sharing some technical detail so people can assist in finding the cause of your problems? Network diagrams, configuration (without keys), output of "wg" on the shell, routes, ... the regular things you do when you have a networking issue.
WireGuard is used as a gateway to access all clients in the WLAN/LAN (vLAN segements, USB-Ethernet LANs), Bridge. WLAN/LAN clients make DNS queries via WireGuard and take into the EDNS Client Subnet (ECS) for location-based steering, considers local split-zoned-LAN DNS TLD within the infrastructure.
- WAN works via vmxnet3 with ESXi NAT.
- vLANS ESXi PVN (Private Virtual Network)
What specific diagnostic data will be helpful? Firewall rules / pf Normalization / MSS / Wireguard / DHCP / ...?
I installed a fresh OPNsense 24.7 and configured NAT, other optimizations. On system ESXi sleep & wakeup via WOL we get that services cannot WireGuard restore even with WG keepalive 25s enabled. OPNsense is not properly able to restore services to operational state GW/DNS/FW rules state. There are issues with reordering services healthcheck recovery prioritization.
Quote from: mistra666 on December 22, 2024, 02:31:24 PMWireGuard is used as a gateway to access all clients in the WLAN/LAN (vLAN segements, USB-Ethernet LANs), Bridge. WLAN/LAN clients make DNS queries via WireGuard and take into the EDNS Client Subnet (ECS) for location-based steering, considers local split-zoned-LAN DNS TLD within the infrastructure.
- WAN works via vmxnet3 with ESXi NAT.
- vLANS ESXi PVN (Private Virtual Network)
That's impossible for me to unpack from just that paragraph without a more or less complete network diagram.
Also USB Ethernet is known to be unreliable in FreeBSD and is strongly discouraged in production use.
Quote from: mistra666 on December 22, 2024, 02:31:24 PMWhat specific diagnostic data will be helpful? Firewall rules / pf Normalization / MSS / Wireguard / DHCP / ...?
Yes? All of it, of course.
Quote from: mistra666 on December 22, 2024, 02:31:24 PMOPNsense is not properly able to restore services to operational state GW/DNS/FW rules state. There are issues with reordering services healthcheck recovery prioritization.
That also does not make much sense on its own and is something I never observed in production.
Can you isolate individual problems that could be addressed one at a time?
ive been having major issues with opnsense since updating. it has become unusable as it will drop internet connection 3 times per hour and needs to be restarted to reestablish connectivity. it will also slow down the internet connection to a crawl with pings going as high as 700+ms 2 to 3 minutes after restart. hoping that the devs are aware of this as i dont see how to make a post or submit a bug.