Yesterday, I performed the upgrade from 20.1 to 20.7. After upgrading, everything appeared to be in working order. However, last night, I discovered that Wireguard, which I had installed and configured prior to the upgrade, was broken. While the enable, server, and client screens appear to work, the other screens (configuration and handshake) are broken and do not load. Uninstalling the packages or reinstalling the packages require reboots in order for the plugins to actually be visible. I'm not seeing anything in the logs either so I'm not sure if the packages are installing but not enabling or if something is failing.
Any help (or somewhere to look for the logs) would be appreciated. I would prefer to use Wireguard over OpenVPN for my VPN.
The screens were empty because WireGuard didnt start. Screenshots of local instance and endpoint please
Attached are the screenshots.
Update:
I figured out the problem and it appears as though if the client allowed IP range has multiple ranges, it breaks. If I change it to a single range, then it works just fine. Looking like a bug here.
I can confirm that there is problem with updating from 20.1 to 20.7. If Endpoint Allowed IPs configuration contains its own LAN subnet, wireguard won't start. I admit it was completely Wireguard config misunderstood but it worked before.
Example:
GW ip 192.168.3.1/24 - if Endpoint Allowed IPs on that machine contains 192.168.1.0/24, 192.168.3.0/24 - WG won't start. Remove 192.168.3.0/24 and it will start and works as expected.
I've also noticed an issue that if under a "local" instance I tie more than 1 peer (even though it's allowed) wireguard stops working as well. 1 peer is OK.
I'd like to have a single WG interface with a bunch of peers (laptop/cell phone/etc) so I can tie one set of firewall rules to a bunch of devices rather than recreate for every device.
Quote from: 5SpeedFun on August 10, 2020, 05:52:47 PM
I've also noticed an issue that if under a "local" instance I tie more than 1 peer (even though it's allowed) wireguard stops working as well. 1 peer is OK.
I'd like to have a single WG interface with a bunch of peers (laptop/cell phone/etc) so I can tie one set of firewall rules to a bunch of devices rather than recreate for every device.
Endpoint has to be /32
I can confirm if you are using multiple ranges in Allowed IPs it wont start after the upgrade to 20.7
Found the issue:
When you are getting a route matching the range from somewhere OSPF static does not matter the wireguard will not start
To expand on this further, it appears as though wg0 needs a unique route. Whatever you put into Allowed IP's creates a static route. If the route exists already, Wireguard fails to start. I created a Allowed IP range and mask that includes the 3 subnets that I want to allow and it is now working. But, if I specify the IP's like I previously had them, it fails.
So, finally dug into this quite a bit and it would appear as though the way the instructions state to setup Wireguard may have worked fine in 20.1, but definitely shouldn't work in 20.1 either. The allowed IP range needs to be the /32 Wireguard address only. I think I saw another post where this is stated as well. Once I did that, problem is resolved.
Has anyone get WireGuard to work after Update 20.7 (20.7.1)?
In my case it looks like an issue with the KeyPairs.
I can´t find a failure in my configuration.
If i type a false key in the Client, the Output is another as with the correct key, so the Client should reach the Server.
Is it started?
Take a look at the list.jpg I think so.
If I type a false key in the Windows-Client I get another screen. So I think that the Server is started.
I have the issue too, that the Server didn't start, if I configure and aktivate more than 1 Client on the WireGuard-Server.
My other WireGuard-Server on my Synology runs in a VM and works after the last WireGuard Update only with WireGuard on OPNsense I have such issues.
Quote from: tezgno on August 14, 2020, 11:28:49 PM
So, finally dug into this quite a bit and it would appear as though the way the instructions state to setup Wireguard may have worked fine in 20.1, but definitely shouldn't work in 20.1 either. The allowed IP range needs to be the /32 Wireguard address only. I think I saw another post where this is stated as well. Once I did that, problem is resolved.
Thanks this seems to have fixed it for me also. Removed all entries and then put the actual wg ip address with a /32 on the end; lastly bounced wg. Although now I can't ping other subnets.
Quote from: Schubbie on August 16, 2020, 01:59:24 PM
Take a look at the list.jpg I think so.
If I type a false key in the Windows-Client I get another screen. So I think that the Server is started.
I have the issue too, that the Server didn't start, if I configure and aktivate more than 1 Client on the WireGuard-Server.
My other WireGuard-Server on my Synology runs in a VM and works after the last WireGuard Update only with WireGuard on OPNsense I have such issues.
This usually happens when endpoint has no /32
Quote from: mimugmail on August 16, 2020, 06:47:28 PM
Quote from: Schubbie on August 16, 2020, 01:59:24 PM
Take a look at the list.jpg I think so.
If I type a false key in the Windows-Client I get another screen. So I think that the Server is started.
I have the issue too, that the Server didn't start, if I configure and aktivate more than 1 Client on the WireGuard-Server.
My other WireGuard-Server on my Synology runs in a VM and works after the last WireGuard Update only with WireGuard on OPNsense I have such issues.
This usually happens when endpoint has no /32
But did you see any Failure in my Screenshots?
Quote from: gurpal2000 on August 16, 2020, 04:50:00 PM
Thanks this seems to have fixed it for me also. Removed all entries and then put the actual wg ip address with a /32 on the end; lastly bounced wg. Although now I can't ping other subnets.
Two things to check:
First, make sure that your firewall allows for traffic from WG to your other subnets. Second, on the client side, make sure that your allowed subnets includes the ones you want to access.
Screenshots looks good.
/usr/local/etc/rc.d/wireguard restart
Output please
root@OPNsense:~ # /usr/local/etc/rc.d/wireguard restart
[#] rm -f /var/run/wireguard/wg0.sock
[#] wireguard-go wg0
INFO: (wg0) 2020/08/17 09:15:09 Starting wireguard-go version 0.0.20200320
[#] wg setconf wg0 /tmp/tmp.UvX0PTXh/sh-np.B2qr90
[#] ifconfig wg0 inet 10.10.11.1/24 10.10.11.1 alias
[#] ifconfig wg0 mtu 1420
[#] ifconfig wg0 up
[+] Backgrounding route monitor
Sadly I have some errors too: None of my clients are able to connect to wireguard. The service is started but there is no connection. I have this error in 2 instances. One is a VM another is on an apu. When I run:
/usr/local/etc/rc.d/wireguard restart
I get the following code:
/usr/local/etc/rc.d/wireguard restart
wg-quick: `wg0' is not a WireGuard interface
[#] wireguard-go wg0
INFO: (wg0) 2020/08/17 09:40:08 Starting wireguard-go version 0.0.20200320
[#] wg setconf wg0 /tmp/tmp.IKz26dvT/sh-np.UBog8P
[#] ifconfig wg0 inet 100.65.0.1/24 100.65.0.1 alias
[#] ifconfig wg0 mtu 1420
[#] ifconfig wg0 up
[#] resolvconf -a wg0 -x
[#] route -q -n add -inet 100.65.0.9/32 -interface wg0
[#] route -q -n add -inet 100.65.0.8/32 -interface wg0
[#] route -q -n add -inet 100.65.0.7/32 -interface wg0
[#] route -q -n add -inet 100.65.0.6/32 -interface wg0
[#] route -q -n add -inet 100.65.0.5/32 -interface wg0
[#] route -q -n add -inet 100.65.0.4/32 -interface wg0
[#] route -q -n add -inet 100.65.0.3/32 -interface wg0
[#] route -q -n add -inet 100.65.0.2/32 -interface wg0
[#] route -q -n add -inet 100.65.0.15/32 -interface wg0
[#] route -q -n add -inet 100.65.0.14/32 -interface wg0
[#] route -q -n add -inet 100.65.0.13/32 -interface wg0
[#] route -q -n add -inet 100.65.0.12/32 -interface wg0
[#] route -q -n add -inet 100.65.0.11/32 -interface wg0
[#] route -q -n add -inet 100.65.0.10/32 -interface wg0
[#] route -q -n add -inet 192.168.6.0/24 -interface wg0
[#] resolvconf -d wg0
[#] rm -f /var/run/wireguard/wg0.sock
Quote from: Schubbie on August 17, 2020, 09:17:43 AM
root@OPNsense:~ # /usr/local/etc/rc.d/wireguard restart
[#] rm -f /var/run/wireguard/wg0.sock
[#] wireguard-go wg0
INFO: (wg0) 2020/08/17 09:15:09 Starting wireguard-go version 0.0.20200320
[#] wg setconf wg0 /tmp/tmp.UvX0PTXh/sh-np.B2qr90
[#] ifconfig wg0 inet 10.10.11.1/24 10.10.11.1 alias
[#] ifconfig wg0 mtu 1420
[#] ifconfig wg0 up
[+] Backgrounding route monitor
Do you see packets in wg0 when you ping 10.10.11.1 from endpoint?
After a little bit of testing I can give the following infos:
When one of the clients attached to a wireguard server contains more then one ip address / network the interface for this server seems not to be starting. if you only have clients with only one ip adress in the server subnet, the interface for the server is starting and you can connect to the server.
Quote from: murmelbahn on August 17, 2020, 10:03:22 AM
After a little bit of testing I can give the following infos:
When one of the clients attached to a wireguard server contains more then one ip address / network the interface for this server seems not to be starting. if you only have clients with only one ip adress in the server subnet, the interface for the server is starting and you can connect to the server.
Which is normal behavior except for Site 2 Site. FreeBSD was more relaxed against misconfig
Quote from: mimugmail on August 17, 2020, 09:47:23 AM
Do you see packets in wg0 when you ping 10.10.11.1 from endpoint?
I don´t configure wg0 in OPNsense i use "WireGuard" under Firewall -> Rules for Rules. The Log hangs after the last Update. It works only a few minutes, so i can´t see it.
If i Ping 10.10.11.1 (WireGuard-IP) in the same Network with WireGuard running on the same Client, it is reachabel. If i connect to my mobile Network, restart WireGuard, than IP 10.10.11.1 is not reachabel, cause the Tunnel is not working.
To test i have left only one allowed IP-Range /24 on the Clients Configuration, but it dosen´t make a difference.
I mean a packet capture on wg interface, do you see incoming packets?
Quote from: tezgno on August 17, 2020, 05:02:21 AM
Quote from: gurpal2000 on August 16, 2020, 04:50:00 PM
Thanks this seems to have fixed it for me also. Removed all entries and then put the actual wg ip address with a /32 on the end; lastly bounced wg. Although now I can't ping other subnets.
Two things to check:
First, make sure that your firewall allows for traffic from WG to your other subnets. Second, on the client side, make sure that your allowed subnets includes the ones you want to access.
I think the default wg firewall entry is "all inclusive" (Any).
Anyway, previously I would have had entries like this "10.10.0.0/24, 192.168.2.0/24" in the Allowed IPs. To me, these are ranges of IP addresses.
Under the new version, I have to change these to "10.10.0.2/32,192.168.2.1/24". Now first is a very specific IP (no range) which is the only end of the tunnel in a VPS. It's fine.
The second is actually the IP address of an LXC bridge on a VPS where the wg client lives. But because /24 is a range, it includes other IP addresses on the 2.x subnet. Which is also fine.
So things work better, and I can do what I used to do before I think. I don't understand why - which is worrying for me (a newbie).
Quote from: mimugmail on August 17, 2020, 10:34:33 PM
I mean a packet capture on wg interface, do you see incoming packets?
I have configured WG0 as Interface, what should not be needed, if I don't want to tunnel my Internettraffic. The Paket Capture show no entries.
Quote from: gurpal2000 on August 17, 2020, 11:36:52 PM
Quote from: tezgno on August 17, 2020, 05:02:21 AM
Quote from: gurpal2000 on August 16, 2020, 04:50:00 PM
Thanks this seems to have fixed it for me also. Removed all entries and then put the actual wg ip address with a /32 on the end; lastly bounced wg. Although now I can't ping other subnets.
Two things to check:
First, make sure that your firewall allows for traffic from WG to your other subnets. Second, on the client side, make sure that your allowed subnets includes the ones you want to access.
I think the default wg firewall entry is "all inclusive" (Any).
Anyway, previously I would have had entries like this "10.10.0.0/24, 192.168.2.0/24" in the Allowed IPs. To me, these are ranges of IP addresses.
Under the new version, I have to change these to "10.10.0.2/32,192.168.2.1/24". Now first is a very specific IP (no range) which is the only end of the tunnel in a VPS. It's fine.
The second is actually the IP address of an LXC bridge on a VPS where the wg client lives. But because /24 is a range, it includes other IP addresses on the 2.x subnet. Which is also fine.
So things work better, and I can do what I used to do before I think. I don't understand why - which is worrying for me (a newbie).
That field doesn't do what you think it does. The only thing that should be in the "Allowed IP" is the /32. If you put the /24 in there, what you think you are doing is allowing that IP range to be accessed by the client when they connect. What's actually happening is that the IP range you put there is being assigned to the wg0 interface as a static route. When you do this, all traffic that is destined to the 192.168.2.1/24 interface range will be directed through the wg0 interface, on the VPN or off it. Your network connections will work, but you'll have a performance issue and likely even a firewall bypass issue.
Personally, I think this is a bug in how that is setup. What I'm doing to provide network segmentation like how I had it previously is I'm using the firewall to allow the certain subnets.
Quote from: mimugmail on August 17, 2020, 11:59:37 AM
Quote from: murmelbahn on August 17, 2020, 10:03:22 AM
After a little bit of testing I can give the following infos:
When one of the clients attached to a wireguard server contains more then one ip address / network the interface for this server seems not to be starting. if you only have clients with only one ip adress in the server subnet, the interface for the server is starting and you can connect to the server.
Which is normal behavior except for Site 2 Site. FreeBSD was more relaxed against misconfig
Aaah thank you for this. After using only the tunnel IP in the client settings everything is working. Have to use Firewall rules for access of different subnets but thats no problem.
Did you use OPNsense 20.7.1 or an older Version? I don't get it to work again after Update. I use the same Client Configuration with another Tunnel-IP and another Port for the VM. on my Synology where it works.
By everyone else WireGuard is working now under 20.7.1? I can't get it to work again :-(
Can you contact me next week in IRC?
Or me I can help you We have over 250 tunnel now using WireGuard and it works great
I have removed openvpn from product0n
Similar trouble here... Upgrade to 20.7 worked like a charm. Applied 20.7.1 and now WireGuard is unable to establish connections on my iPhone stating "DNS resolution failure".
Correcting... it was DNS account issue. I have no further issues.
Quote from: Schubbie on August 18, 2020, 09:48:42 AM
Did you use OPNsense 20.7.1 or an older Version? I don't get it to work again after Update. I use the same Client Configuration with another Tunnel-IP and another Port for the VM. on my Synology where it works.
Can you check if you use GeoIP? Had a similar problem where it was just blocked by failed GeoIP country which broke after upgrade
I don´t use GeoIP.
Is there a possibility to remove all WireGuard Settings? If i un-/install Wireguard anr reboot the Settings are the same as before. I think there is a failure in a configuration that i can´t see in the Web-UI.
Via cli open conf/config.xml and remove wireguard container
I can use PuTTY for that?
But i can´t find the Folder :-(
I rarely use SSH...
/conf/config.xml
Did you take a look at my screenshot one Post before? I didn't found it.
You are in /root/ .. one folder up
THX. I've tried "cd\" correct is "cd ..".
I have delete the lines for Wireguard and siproxd. Now the Konfiguration for Wireguard is empty. I want to try to reconfigure next time.
Wireguard did I uninstalled with "pkg delete", but this delete not more as the WebUI.
pkg remove os-wireguard will delete the plugin and also the software itself. Should also happen when uninstalling via GUI
I've tried it with this ToDo again:
https://www.thomas-krenn.com/de/wiki/OPNsense_WireGuard_VPN_f%C3%BCr_Road_Warrior_einrichten
Under "listen" I see wg0 but no handshakes :-(
Did I have to configure an Interface and an IP for wg0?
I don't know what I should do. First time it runs till the Update last year.
Is there another ToDo I should use?
Show your config (screenshot) for Local and Endpoint, as well as the FW-Rules on both ends. I had to add an interface for the WG (but not activate!) to make the FW-Tab for the tunnel appear...
Is this enough information?
Local Config: Tunnel IP 10.10.11.1/24
Remote Config: "erlaubte IPs" does not include 10.10.11.1/32
Can't check if your Alias for the WAN port is correct (50315)
Set your WAN rule to logging / do a package capture and look if any packages arrive at your WAN...
Local Config: Tunnel IP changed
Remote Config: "erlaubte IPs" added, but this should not necessary
Alias is correct
I can´t see any packets that belongs to Wireguard.
Wireguard is listen but i can´t get a handshake :-(
It ran straight away when it was set up a few months ago, but now it no longer works ...
If nothing reaches the sense, the problem must be on the client or ISP-side, I guess...
You do a package capture on the sense for WAN interface port 50315?
I've tried it with Windows and Android Client.
My VM on a Synology NAS works. I've copied the Client Configuration and changed Keys, iP and Port.
Yes, find no traffic on Port 50315.
I've tried IP 192.168.153.1:50315 and 10.10.11.1:50315 instead FQDN:50315 from my Network.
You try from LAN side? Not from mobile network?
Your "Endpunkt" in the client config is the domain name from your dynDNS provider for the WAN IP, correct? And it's updated and a public IP?
If nothing reaches the WAN port, it should not be a problem with the generate keys (don't modify them manually, only the automatically generated key pairs will work).
I've tried from Mobile and LAN.
Yes, the Endpoint is my DynDNS, I've set an internal forwarding, so the Traffic should not leave the Sense, if the client is in my Network to avoid loops.
I've reconfigured an reinstalled it several times, but it runs only the first time still to the Update a few months before.
Hello,
I haven't had time for further tests, but I just discovered the widget on the dashboard. Shouldn't something be shown in the widget? The instances in Wireguard are active.
It looks like my assumption is confirmed by the fact that Wireguard is not taking over the settings, right?
Couple of comments:
It looks like you have put the same public key in both the local config and the endpoint config on OPNsense? And the same key is in the local and endpoint configs on the client? The client public key needs to go in the endpoint on OPNsense, and the OPNsense public key in the endpoint on the client.
On the client, specify the local tunnel IP as 10.10.11.4/24 so that it is part of the same subnet.
Hello,
yes, ich checked the Keys several Times and have it configured several times.
I had given the Client the /24 IP and tried other IP-Ranges on both Sides.
But shouldn't shown something in the widget of the Dashboard even if no client is connected. In the Dashboard it seems like the service doesn't starts?
My point was that the key setup shown in your screenshots looks wrong and won't work
As for the widget, yes you should see entries for enabled interfaces/endpoints - assuming they are properly configured. I suspect the fact that the key entries are wrong means that WG is refusing to enable them. But the widget is a distraction - better to focus on getting the configuration on OPNsense and the client right