Wireguard – no handshake. What’s bare min client setup needed?

Looking at wireguard solutions at the moment, lab testing on different devices and OpenWRT seemed a useful platform to test (and probably deploy) for wireguard.

Have so far used: EdgeRouter X, Centos, VyOS and Windows Client to setup and & test wireguard tunnels (and have basic awareness of how it should work from this).

Would like to move to testing OpenWRT and have the following devices:

TPLINK Archer C7 – 21.02.0
Gl.inet AR-300 - 19.07.7
Raspberry Pi CM4 IoT Router Carrier Board Mini – 21.02.0 (DFRobot Build)

I have tried to get each of these to connect as a client into VyOS and Centos Wireguard servers. I have copied the keys from the Windows client which does connect successfully and I have also tried setting up with new keys. To date, I can only get the AR-300 to work as a client (and this has its own interface that sets this up, not via Luci).

Regardless of what I do, I can’t seem to get either the tplink or the Pi to work as a client. (Though I did test the TPLINK working as a server initially and this was OK). I’m sure I’ve missed something obvious, but I consistently fail to see any handshake occur.

I’m going to outline the following minimum steps I’ve done:

1 Reset to default settings for 21.02.0.
2 Install & configure basics as per https://openwrt.org/docs/guide-user/services/vpn/wireguard/basics get the private key from wg.key and paste it into the private key field of the interface (under General Settings). Set the IP address (client side IP of the tunnel)
3 Under Peers, set description, public key from the server, Endpoint Host (IP of the server), Endpoint Port. Save & apply, restart interface.
4 Under Status/Wireguard, Peer is shown with correct details, but “latest handshake” shows “never”. (Server also shows no handhake from client).

As a sanity check, I then use the same key details as I setup above and create a new tunnel in my Wireguard Windows Client (same network as my OpenWRT devices) and I am able to successfully connect this to my Wireguard Server. I can see the server show the incoming connection from the public key of the peer used above. If I try to use these same (working) details from OpenWRT, I never see any handshake.

To simplify things, I’m not (yet) looking for any routing or firewall settings, I just want to confirm I have a valid handshake and the tunnel exists. I believe as long as I have the minimum config set, I should at least see a handshake. This is the minimum config I’m looking for - can someone please confirm the minimum required config to get a client side connection going as above?

Any help or advice would be greatly appreciated.

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/firewall

wireguard is a software solution and (largely) independent from the underlying hardware (apart from the connection speed/ achievable throughput). The configuration is close to identical on all devices, but you do have to get the subnet routing right (this is the most common cause for problems).

Thanks for the reply, here's the config:

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd03:9d99:94b6::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth1.1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option device 'eth0.2'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth0.2'
        option proto 'dhcpv6'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '2 3 4 5 0t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '1 6t'

config interface 'wg0'
        option proto 'wireguard'
        option private_key '(Redacted)'
        list addresses '10.254.0.2/24'

config wireguard_wg0
        option description 'Centos'
        option public_key '(redacted)'
        option endpoint_host '192.168.25.121'
        option endpoint_port '49924'

config defaults
        option syn_flood        1
        option input            ACCEPT
        option output           ACCEPT
        option forward          REJECT
# Uncomment this line to disable ipv6 rules
#       option disable_ipv6     1

config zone
        option name             lan
        list   network          'lan'
        option input            ACCEPT
        option output           ACCEPT
        option forward          ACCEPT

config zone
        option name             wan
        list   network          'wan'
        list   network          'wan6'
        option input            REJECT
        option output           ACCEPT
        option forward          REJECT
        option masq             1
        option mtu_fix          1

config forwarding
        option src              lan
        option dest             wan

# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
        option name             Allow-DHCP-Renew
        option src              wan
        option proto            udp
        option dest_port        68
        option target           ACCEPT
        option family           ipv4

# Allow IPv4 ping
config rule
        option name             Allow-Ping
        option src              wan
        option proto            icmp
        option icmp_type        echo-request
        option family           ipv4
        option target           ACCEPT

config rule
        option name             Allow-IGMP
        option src              wan
        option proto            igmp
        option family           ipv4
        option target           ACCEPT

# Allow DHCPv6 replies
# see https://dev.openwrt.org/ticket/10381
config rule
        option name             Allow-DHCPv6
        option src              wan
        option proto            udp
        option src_ip           fc00::/6
        option dest_ip          fc00::/6
        option dest_port        546
        option family           ipv6
        option target           ACCEPT

config rule
        option name             Allow-MLD
        option src              wan
        option proto            icmp
        option src_ip           fe80::/10
        list icmp_type          '130/0'
        list icmp_type          '131/0'
        list icmp_type          '132/0'
        list icmp_type          '143/0'
        option family           ipv6
        option target           ACCEPT

# Allow essential incoming IPv6 ICMP traffic
config rule
        option name             Allow-ICMPv6-Input
        option src              wan
        option proto    icmp
        list icmp_type          echo-request
        list icmp_type          echo-reply
        list icmp_type          destination-unreachable
        list icmp_type          packet-too-big
        list icmp_type          time-exceeded
        list icmp_type          bad-header
        list icmp_type          unknown-header-type
        list icmp_type          router-solicitation
        list icmp_type          neighbour-solicitation
        list icmp_type          router-advertisement
        list icmp_type          neighbour-advertisement
        option limit            1000/sec
        option family           ipv6
        option target           ACCEPT

# Allow essential forwarded IPv6 ICMP traffic
config rule
        option name             Allow-ICMPv6-Forward
        option src              wan
        option dest             *
        option proto            icmp
        list icmp_type          echo-request
        list icmp_type          echo-reply
        list icmp_type          destination-unreachable
        list icmp_type          packet-too-big
        list icmp_type          time-exceeded
        list icmp_type          bad-header
        list icmp_type          unknown-header-type
        option limit            1000/sec
        option family           ipv6
        option target           ACCEPT

config rule
        option name             Allow-IPSec-ESP
        option src              wan
        option dest             lan
        option proto            esp
        option target           ACCEPT

config rule
        option name             Allow-ISAKMP
        option src              wan
        option dest             lan
        option dest_port        500
        option proto            udp
        option target           ACCEPT

# allow interoperability with traceroute classic
# note that traceroute uses a fixed port range, and depends on getting
# back ICMP Unreachables.  if we're operating in DROP mode, it won't
# work so we explicitly REJECT packets on these ports.
config rule
        option name             Support-UDP-Traceroute
        option src              wan
        option dest_port        33434:33689
        option proto            udp
        option family           ipv4
        option target           REJECT
        option enabled          false

# include a file with users custom iptables rules
config include
        option path /etc/firewall.user


### EXAMPLE CONFIG SECTIONS
# do not allow a specific ip to access wan
#config rule
#       option src              lan
#       option src_ip   192.168.45.2
#       option dest             wan
#       option proto    tcp
#       option target   REJECT

# block a specific mac on wan
#config rule
#       option dest             wan
#       option src_mac  00:11:22:33:44:66
#       option target   REJECT

# block incoming ICMP traffic on a zone
#config rule
#       option src              lan
#       option proto    ICMP
#       option target   DROP

# port redirect port coming in on wan to lan
#config redirect
#       option src                      wan
#       option src_dport        80
#       option dest                     lan
#       option dest_ip          192.168.16.235
#       option dest_port        80
#       option proto            tcp

# port redirect of remapped ssh port (22001) on wan
#config redirect
#       option src              wan
#       option src_dport        22001
#       option dest             lan
#       option dest_port        22
#       option proto            tcp

### FULL CONFIG SECTIONS
#config rule
#       option src              lan
#       option src_ip   192.168.45.2
#       option src_mac  00:11:22:33:44:55
#       option src_port 80
#       option dest             wan
#       option dest_ip  194.25.2.129
#       option dest_port        120
#       option proto    tcp
#       option target   REJECT

#config redirect
#       option src              lan
#       option src_ip   192.168.45.2
#       option src_mac  00:11:22:33:44:55
#       option src_port         1024
#       option src_dport        80
#       option dest_ip  194.25.2.129
#       option dest_port        120
#       option proto    tcp

Note: This is basically default, I've just added the wireguard part (as described in my first post). The peer is the Centos server that I'm trying to connect to as a client. It is connected direclty and locally to it (in the 192.168.25.0 network that my OpenWRT has connected to its WAN port). The peer (.121) is pingable from OpenWRT as well.
The IP of the wireguard tunnel is 10.254.0.2 for the client and 10.254.0.1 for the server (these are the same I've used for my sucessful tests with other devices as mentioned in the first post).
Note: I'm not yet trying to route traffic to this, I'm just trying to establish the handshake. When I tried this on other devices, I had not needed any additional routing or firewalling settings to establish the handshake, but poerhaps I do for OpenWRT.

Where does this host live? 192.168.25.0/24 immediately upstream of your OpenWrt router?

Try making this /32.

Can we see the other peer's configuration?

Yes, the host is immedaitely upstream of the OpenWRT router, which has its WAN port connected to the 192.168.25.0 subnet and the host is on .121 (It can ping it OK).
I will get you the peer's config soon.

The Centos Server this I'm trying to connect to as a peer shows the following with wg show

interface: wg0
  public key: (redacted)
  private key: (hidden)
  listening port: 49924

peer: (redacted)
  endpoint: 192.168.25.126:53423
  allowed ips: (none)
  latest handshake: 2 hours, 1 minute, 51 seconds ago
  transfer: 296 B received, 248 B sent

peer: (redacted)
  allowed ips: (none)

peer: (redacted)
  allowed ips: (none)

The peer that shows connected was me using the Windows Wireguard Client and as you can see, this shows a handshake. I also tried copying these same keypair details to the AR-300 unit and that was able to connect and get a handshake. I have tried these same keys with the OpenWRT on 2 different devices, but so far failed to get any handshake. I've also tried generating new keypairs, which are the other 2 peers that show no handshake.

This is the wg0.conf file from the server

[Interface]
Address = 10.254.0.1/24
ListenPort = 49924
SaveConfig = True
PrivateKey = (redacted)
[Peer]
PublicKey = (redacted)
AllowedIPs = 0.0.0.0/0

re changing the mask to /32 - yes, I can try this, though this was my original setting and over time as I've messed with it, I also tried opening it up to where I have it now at /24. Other clients connecting with these details still handshake OK,

This should not be set like this on the 'server' -- your server should have the peer allowed IPs set as individual /32's on the same subnet as your /24 interface definition. The allowed IPs should be 0.0.0.0/0 on the remote peer if all traffic is to be tunneled through to the 'server'.

The server should look like this (keep in mind, this is formatted for OpenWrt):

config interface 'wireguard'
	option proto 'wireguard'
	option private_key 'REDACTED'
	option listen_port '49924'
	list addresses '10.254.0.1/24'

config wireguard_wireguard
	option public_key 'REDACTED'
	list allowed_ips '10.254.0.2/32'
	option route_allowed_ips '1'
	option description 'RemotePeer1'

config wireguard_wireguard
	option public_key 'REDACTED'
	list allowed_ips '10.254.0.3/32'
	option route_allowed_ips '1'
	option description 'RemotePeer2'

The remote peer (i.e. your OpenWrt router) should have a config file that looks something like this:

config interface 'wg_RemoteRouter'
	option proto 'wireguard'
	option private_key 'REDACTED'
	list addresses '10.254.0.3/32'

config wireguard_wg_RemoteRouter
	option public_key 'REDACTED'
	list allowed_ips '0.0.0.0/0'
	option route_allowed_ips '1'
	option endpoint_host '192.168.25.121'
	option endpoint_port '49924'
	option description 'Peer2'

Thanks psherman. Let me see if I can work with this. It may be my other test environments were more forgiving and it has been changed a lot through the testing, but I'm keen to get it working with OpenWRT, so your suggestions are appreciated. I will try this.

Got it! I now have a handshake!
I have undone & re-done config a few times in a few ways now to make sure it's correct.

It was only the option in the peer for allowed IPs that was missing. The subnet mask or 24 or 32 made no difference (/24 still worked), but you're right, 32 would be better.

list allowed_ips '0.0.0.0/0'

I'm sure I had this in previous attempts, but it is also likley I had only restarted the interface before testing, not saved & applied first. Anyway, I now have it working and I'm very appreciative for the help.
Likely I wil still need to clean things, up, do routing & firewalling, but at least I can now be sure of the minimum requirement to get the tunnel connected.

The correction I'd need to add (from my first post above) would be:
3 Under Peers, set description, public key from the server, Allowed IP to '0.0.0.0/0', Endpoint Host (IP of the server), Endpoint Port. Save & apply, restart interface.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.