Wireguard can't complete handshake

Bluecube

Bluecube

Bluecube

Soldato
Joined
20 Feb 2011
Posts
4,138
I've got Wireguard installed on a Raspberry Pi which in turn is connected direct to my router, a UDM.

I've added a client and have scanned the resulting QR code into the Wireguard app on my iPhone. On activating the VPN, the log shows that the tunnel status is connected. However, very quickly the logs show that a handshake is initiated which repeatedly fails.

And this is where I'm stuck. The Wireguard debug shows no problems. I've activated port forwarding on the UDM. I'm at a loss now as to how to fix this issue. I've done a bit of net searching but nothing makes any difference. Has anyone here had any similar issues? And if so, did you manage to fix them?
 
Then I’d say no, you’re stuck. VPN on UniFi is very poorly supported. And that’s been the case of years.
 
What I’m saying is the controller is the controller and it doesn’t like VPNs because they bypass it and it sees that as an attack. Install your VPN into the controller and it works.
 
That’s a pretty disappointing situation I have to say especially given the lack of official VPN options available on the UDM. Looks as if I’ll be dropping the UDM and replacing it with a Pfsense solution now.
 
Seems a bit extreme considering you can just integrate Wireguard into the UDM controller and it’ll work fine.
 
Not really. I had a look at the link you sent and it’s not just a matter of downloading the necessary files to the UDM. It’s a fairly complex operation to do what Ubiquiti should be providing as a matter of course in their products given their cost and pro/ semi pro leanings.

As may have guessed the VPN issue after many others is the last straw. I have not been impressed at all by the UDM.
 
WJA96 said:
What I’m saying is the controller is the controller and it doesn’t like VPNs because they bypass it and it sees that as an attack. Install your VPN into the controller and it works.
Click to expand...

First I've heard... You seriously can't run a UDP service behind a Ubiquiti product? All the UDM has to do is DNAT the packets to the correct host and port.

OP you've missed a lot of info out in your post. You have WireGuard 'on your Pi'. How? Raspbian Buster with PiVPN? Enabled buster-backports and installed wireguard that way? From the talk of scanning qr codes I assume PiVPN (rather than a manual install of qrencode). Did you enable packet forwarding in the kernel for the Pi? That's done automagically by PiVPN but if you set it up yourself it's a necessary step. Firewall on the Pi?

PiVPN (if that's what you used) can be a bit temperamental and buggy. I had a simlar issue and a uninstall and reinstall (of PiVPN not Raspbian) fixed it. You'll need to regenrate your configs but it only takes a second really.
 
I used PiVPN as you correctly guessed and installed on the latest Raspbian. Packet forwarding is enabled and the Pi’s firewall has the necessary entries enabling connection between eth0 and wg0.

I’ve uninstalled and reinstalled PiVPN several times but have had no joy. From what I can see from the client logs (an iPhone in this case) a connection is made but when data is sent, the client attempts to make a handshake which repeatedly fails.
 
Server -
PrivateKey = redact
Address = 10.6.0.1/24
ListenPort = 51820

### begin iPhone ###
[Peer]
PublicKey = redact
PresharedKey = redact
AllowedIPs = 10.6.0.2/32
### end iPhone ###

Client -
[Interface]
PrivateKey = Redact
Address = 10.6.0.2/24
DNS = 1.1.1.1, 1.0.0.1
[Peer]
PublicKey = redact
PresharedKey = redact
Endpoint = fake.ddns.net:51820
AllowedIPs = 192.168.1.0/24, 10.6.0.0/24

You’ll see that I’ve been experimenting with Allowed IPs. Even when set to 0.0.0.0, the connection fails at the handshake.
 
Sorry, I forgot about this thread. :o Your client config has the wrong subnet for the IP. You have Address = 10.6.0.2/24 where it should be 10.6.0.2/32 - but I'm not sure that's enough to cause your issue.
 
That may have been a result of my fiddling trying to get things working. Changed it back and no joy. According to the log, the client connects to the server. It’s only when data starts to be transferred that a handshake is issued and fails. I wonder if the crypto keys are messed up and not matching...

If I get time I’ll sit down and start again from scratch without PiVPN.
 
I found a straightforward tutorial here on the Raspberry Pi forums that shows how to build Wireguard from scratch and also how to create Wireguard config files. Very straightforward - I recommend it.

But still the blasted client wouldn't handshake with the server... Cutting a (very) long story short, I noticed that the client wasn't connecting to the correct public IP address despite using DDNS. I typed the correct public IP address into the client config and voila - a handshake! I logged into the DDNS service I use, no-IP, and manually updated the DDNS to point to the correct IP address. Changed the client settings back to DDNS hostname and it worked again...

So it seems that either the UDM wasn't updating No-IP with the public IP address or No-IP wasn't updating it's records... Something I'll have to keep an eye on!
 
Who's your ISP? Does your IP change regularly (i.e. every time your modem reboots, every 24h or similar)? Or is it VM with 'sticky DHCP' where you keep the same 'dynamic' IP for months or years at a time? It may well be worth just getting your own domain and pointing it at your IP if the latter is the case. It's what I did and I had the same IP for years on end. Glad you got to the bottom of it.
 
I’m with Sky. I’m not sure if my IP address changes frequently. It’s something I’ll be keeping an eye on from now on. I’m a bit puzzled why the DDNS didn’t update though as I’ve never had problems until now. It’d be good to know whether it’s a UDM or a DDNS provider issue.
 
You must log in or register to reply here.
Back
Top Bottom