Hi all,
The page https://docs.opnsense.org/manual/how-tos/wireguard-s2s.html says how to create a WireGuard connection between two sites. I configured a firewall using these instructions.
Using version 22.1 the interface comes up and immediately goes down. Saving the configuration, installing version 21.7, the updates, the WireGuard plugin and restoring the configuration the WireGuard interface comes up and stays up.
There are no messages, so I'm having difficulty determining what is causing the interface to not stay up.
Hope someone can help, I've spent several hours trying to figure out the cause?
- spider
/usr/local/etc/rc.d/wireguard restart
via Console.
We recently had couple of similar reports where it was overlapping tunnel networks
Hi
Spent about a day installing a new system from scratch and testing the connection. With version 21.7.8 everything works as expected, after running the upgrading to version 22.1 the interface does not come up. I'm not using a dedicated interface for the WireGuard interface. Here is the boot output from 21.7 (tweaked the boxes drawing characters a bit)
[#] ifconfig wg create name wg0
[!] Missing WireGuard kernel support (ifconfig: SIOCIFCREATE2: Invalid argument). Falling back to slow userspace implementation.
[#] wireguard-go wg0
tun0: link state changed to UP
tun0: changing name to 'wg0'
ââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
â â
â Running wireguard-go is not required because this â
â kernel has first class support for WireGuard. For â
â information on installing the kernel module, â
â please visit: â
â https://www.wireguard.com/install/ â
â â
ââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
[#] wg setconf wg0 /dev/stdin
[#] ifconfig wg0 inet 10.10.0.14/24 alias
[#] ifconfig wg0 mtu 1420
[#] ifconfig wg0 up
[#] route -q -n add -inet 10.10.0.14/32 -interface wg0
[#] route -q -n add -inet 10.99.0.0/24 -interface wg0
[+] Backgrounding route monitorand here is the output from 22.1
[#] ifconfig wg create name wg0
[!] Missing WireGuard kernel support (ifconfig: SIOCIFCREATE2: Invalid argument). Falling back to slow userspace implementation.
[#] wireguard-go wg0
tun0: link state changed to UP
tun0: changing name to 'wg0'
┌──────────────────────────────────────────────────────┐
│ │
│ Running wireguard-go is not required because this │
│ kernel has first class support for WireGuard. For │
│ information on installing the kernel module, │
│ please visit: │
│ https://www.wireguard.com/install/ │
│ │
└──────────────────────────────────────────────────────┘
[#] wg setconf wg0 /dev/stdin
[#] ifconfig wg0 inet 10.10.0.14/24 alias
[#] ifconfig wg0 mtu 1420
[#] ifconfig wg0 up
[#] route -q -n add -inet 10.10.0.14/32 -interface wg0
[#] rm -f /var/run/wireguard/wg0.sock
wg0: link state changed to DOWNThe last two lines don't look nice
- rm -f /var/run/wireguard/wg0.sock
wg0: link state changed to DOWN
Quote/usr/local/etc/rc.d/wireguard restart
shows the same error message.
Thanks
- spider
I have the same phenomenon after updating the standby node of one of our production clusters from 21.7.8 to 22.1.
Did not have time to investigate further (production!) but instead used ZFS to roll back to 21.7.
I can share the wireguard config (without private keys ;)) if anyone wants to put some more time into it right now. I will have to wait another week or two before I have some capacity for a serious debugging session.
Can you try to change the LOCAL tunnel network to /32 instead of /24. It seems FreeBSD13 handling changed a bit and we maybe need to adjust documentation. :(
I don't have a tunnel network in this installation. Only allowed IPs. Tunnel network is not necessary in gateway-gateway topology.
I meant spider as he posted some logs which indicates this.
No idea if you want to share yours :)
Don't have a 22.1 installation with that config atm, but the log looked exactly like @spider's:
[#] ifconfig wg0 up
[...]
[#] route -q -n add [...] -interface wg0
[#] route -q -n add [...] -interface wg0
[#] [... add all the routes ...]
[#] rm -f /var/run/wireguard/wg0.sock
wg0: link state changed to DOWN
My trimmed config:
interface: wg0
public key: eehiloQrtuKlj2WieuER2X/hzcG7XR27qvqrqkQkI3Q=
private key: (hidden)
listening port: 51820
peer: L/1DmaGJwqC0JpwNjKt9dRa6erwl3zLvXRcHYUfNqwM=
preshared key: (hidden)
endpoint: *****
allowed ips: *****
latest handshake: 6 seconds ago
transfer: 18.82 GiB received, 2.97 GiB sent
persistent keepalive: every 30 seconds
peer: UVrmqWeiZvap6A0v6oCosT5w+rUBCUxVmVeBuUVWilk=
preshared key: (hidden)
endpoint: *****
allowed ips: *****
latest handshake: 41 seconds ago
transfer: 200.69 GiB received, 45.96 GiB sent
persistent keepalive: every 30 seconds
peer: h6E2aX1XYrd/+E6OxMOCVNaFFanHYKa9V6LUxlb3BAk=
preshared key: (hidden)
endpoint: *****
allowed ips: *****
latest handshake: 1 minute, 1 second ago
transfer: 1.07 GiB received, 59.12 GiB sent
persistent keepalive: every 30 seconds
peer: 9mXAH5tD6rlgYggTfYjoBpXtyDcN39tHTWYYaOGFEmE=
preshared key: (hidden)
endpoint: *****
allowed ips: *****
latest handshake: 1 minute, 16 seconds ago
transfer: 7.80 GiB received, 29.08 GiB sent
persistent keepalive: every 30 seconds
peer: W6+cTWSzxPdUWL/IpyV6VnepQ+VnFNCLRbo/qmyM7mE=
preshared key: (hidden)
endpoint: *****
allowed ips: *****
latest handshake: 1 minute, 56 seconds ago
transfer: 507.34 KiB received, 1.32 MiB sent
persistent keepalive: every 30 seconds
This configuration is currently active and working in 21.7.8.
I posted the response below in the VPN section to a thread I started with the same problem. Hopefully it might help resolve your issue. I was getting the same output as you when I did a wireguard restart from the command line.
I did finally figure out the problem and it was a configuration issue. In the Local tab of the configuration I had the Tunnel IP address as 10.11.0.2/24 and in the Allowed IP's in Endpoints tab had 10.11.0.2/32 which caused a conflict. I also had 192.168.0.0/24 as the local network in the Allowed IP's on the other side of the tunnel. The Allowed IP's should have been 10.11.0.1/32 and once I made that change the tunnel worked. The misconfiguration though did work under 21.7 series so I was assuming my configuration was correct even though it was not. The 22.1 series I guess is less forgiving of this type of configuration error. Unfortunately it took me a long time to figure out the problem so I would go back and double check your configuration and not assume it was correct even if it worked in 21.7 series. I also posted in another thread on the 22.1 Production Series forum my resolution as that was a more active thread than this discussing a similar Wireguard problem. Good luck.
This is my updated /usr/local/etc/wireguard/wg0.conf (modified the keys and the endpoint)
[Interface]
PrivateKey = IFHejkyCiJTq7FDC8iApjL3/mfrfeYaXcIVVMEffsFs=
Address = 10.10.0.14/32
ListenPort = 51820
[Peer]
PublicKey = UND2TqvSaGOeg96OS6gHymCVe++QOg+0DKWDa/R5bT8=
Endpoint = s2s.example.com:51820
AllowedIPs = 10.10.0.14/32,10.99.0.0/24
PersistentKeepalive = 30
On Debian Linux, the config is almost identical /etc/wireguard/example.conf except the interface is called example and it has no tunnel address.
[Interface]
Address = 10.10.0.2/32
SaveConfig = true
ListenPort = 51822
PrivateKey = IFHejkyCiJTq7FDC8iApjL3/mfrfeYaXcIVVMEffsFs=
[Peer]
PublicKey = UND2TqvSaGOeg96OS6gHymCVe++QOg+0DKWDa/R5bT8=
AllowedIPs = 10.99.0.0/24
Endpoint = s2s.example.com:51820
PersistentKeepalive = 60
The output from wireguard restart is
[#] wg setconf wg0 /dev/stdin
[#] ifconfig wg0 inet 10.10.0.14/32 alias
[#] ifconfig wg0 mtu 1420
[#] ifconfig wg0 up
[#] route -q -n add -inet 10.10.0.14/32 -interface wg0
[#] rm -f /var/run/wireguard/wg0.sock
wg0: link state changed to DOWN
Quote from: dmmincrjr on February 23, 2022, 05:33:43 PM
I did finally figure out the problem and it was a configuration issue. In the Local tab of the configuration I had the Tunnel IP address as 10.11.0.2/24 and in the Allowed IP's in Endpoints tab had 10.11.0.2/32 which caused a conflict. I also had 192.168.0.0/24 as the local network in the Allowed IP's on the other side of the tunnel. The Allowed IP's should have been 10.11.0.1/32 and once I made that change the tunnel worked. The misconfiguration though did work under 21.7 series so I was assuming my configuration was correct even though it was not. The 22.1 series I guess is less forgiving of this type of configuration error. Unfortunately it took me a long time to figure out the problem so I would go back and double check your configuration and not assume it was correct even if it worked in 21.7 series. I also posted in another thread on the 22.1 Production Series forum my resolution as that was a more active thread than this discussing a similar Wireguard problem. Good luck.
Yes, that's it. Just changed the AllowedIPs = 10.10.0.14/32,10.99.0.0/24 to AllowedIPs = 10.99.0.0/24 and the interface stays up. So, the working configuration is:
[Interface]
PrivateKey = IFHejkyCiJTq7FDC8iApjL3/mfrfeYaXcIVVMEffsFs=
Address = 10.10.0.14/32
ListenPort = 51820
[Peer]
PublicKey = UND2TqvSaGOeg96OS6gHymCVe++QOg+0DKWDa/R5bT8=
Endpoint = s2s.example.com:51820
AllowedIPs = 10.99.0.0/24
PersistentKeepalive = 30Cheers,
- spider
Just to complete the post
The Endpoint tab now looks like this
(https://i.ibb.co/RcLG8qC/Screen-Shot-02-23-22-at-06-01-PM.png) (https://ibb.co/RcLG8qC)
Quote from: pmhausen on February 23, 2022, 03:43:46 PM
Did not have time to investigate further (production!) but instead used ZFS to roll back to 21.7.
If you want to share how did you do this, I would be all ears.
Thanks for everyone's help.
- spider
Quote from: spider on February 23, 2022, 06:13:30 PM
Quote from: pmhausen on February 23, 2022, 03:43:46 PM
Did not have time to investigate further (production!) but instead used ZFS to roll back to 21.7.
If you want to share how did you do this, I would be all ears.
https://forum.opnsense.org/index.php?topic=25540