Wireguard - can't get handshake

I've been trying to get wireguard to work for many hours without success.
I'm only looking to use wireguard to get access to IPMI control panels in colocation.
I'm very new to all of this, it seems like I'm in over my head.

Below my configuration settings;




The interface is in the LAN firewall zone.

I've tried several different guides over and over but haven't gotten any handshake so far.
Anything more I can try?
Thanks in advance!

On Server:
IP 10.0.10.0 is not valid. Use 10.0.10.1/24
Don't use endpoint port (unless the peer is not behind NAT beyond your control), no need to Route Allowed IPs.
The forward on the firewall is wrong, you need a rule to allow udp/1234 from wan to device.

On client:
Remove the listen port, unless you are not behind nat beyond your contol.
Add the option to Route Allowed IPs.

Verify that both peers have the correct time.
The documentation on wireguard.

1 Like

Your firewall rule is wrong, too. You should set it up as a traffic rule, not a forward.

1 Like

I know, I told him!

1 Like

Sorry @trendy - you most certainly did. :smiley:

2 Likes

Thanks for the fast replies!

-I've changed the interface IP to 10.0.10.1/24 (tried before, set to x.0 according to some post)
-Removed endpoint port from openwrt peer setting
-Disabled "route allowed IPs" in openwrt peer settings
-Removed the listen port on client
-Edited the firewall rule:
Capture

The result remains the same.

Did you restart network and firewall services after the changes?

Indeed I have done as such.

Is the time correct on both?

Maybe I misunderstood, but the OpenWrt is supposed to provide access to everything (0.0.0.0/0) for this windows (?) wireguard, right?

Time is synced.
I've set it to everything for now for debugging, what I actually need is to just provide access to some machines in lan 10.0.0.100-10.0.0.150.
The client is running windows.
I read before I should try a different subnet for wireguard (hence 10.0.10.1/24 for the interface) so I'm first trying to get anything to work to see some kind of handshake.

On Windows, address 10.0.10.20/24

Just tried, no difference.

Setup a packet capture and see if there are incoming packets:
opkg update; opkg install tcpdump; tcpdump -i any udp port 1234
Then try from the windows to send any traffic.


No handshake, but at least some sign of life on the server side!

This isn't much. Just the windows trying to contact the OpenWrt. Since there is no response, it means that there is misconfiguration. Check the keys in case there was a typo. Make sure you have assigned them correctly.
Private key of each machine goes to Interface.
The public key of each machine goes to the peer section of the other machine!
This means that the public key of the Windows will be entered in the OpenWrt-peer-Public Key field.

I've checked the key pairs countless times, those are assigned as you describe;
Created a keypair on the router, used the priv key in the interface, the public key in windows client peer. The keypair generated on the windows client: priv key in interface, public key to wireguard peer section.

Firewall rule is still wrong, remove SRC port 1234 - only use DST port 1234.

Screenshot from 2020-02-29 18-30-13

3 Likes

Thanks everyone for the help! Using only destination port in the firewall rule is what did it. Hope this helps some future people as well.

1 Like

I have now changed the interface to 10.0.0.10/27 and peer to 10.0.0.11/32 which is working as excpected, however I've read that this should not be done for some reason? (ie. setting the vpn to a lan subnet)

Good catch @lleachii

Correct, you cannot bridge them, you can only route them, therefore they'll have to be in different subnets.

2 Likes