OpenWRT / WireGuard will not connect, will not handshake

Installing and Using OpenWrt
1

Hello!

I recently flashed my Linksys WRT1900ACS router to OpenWRT, and would like to WireGuard configured.

I have followed nearly every YouTube and google'd list of instructions, and can NOT seem to get it to handshake with my remote laptop. I am clearly doing something wrong and would really appreciate any advice!!

I do have a dynamic DNS set up, connecting one of my domain names 'mydomain.com' to the external IP address being assigned to my home by my ISP, which is being updated via the 'myddns_ipv4' service which I successfully installed and configured on the router. Pinging it from a terminal window gives the desired results.

OpenWRT Firewall / Port Forward setup:

  • UDP protocol
  • Source zone = wan
  • external port = 51820
  • Destination zone = lan
  • Internal port = 51820
  • Internal IP address = 192.168.1.1 (note, some tutorials say set this to the interface IP, in this case 192.168.9.1 ??)

OpenWRT WireGuard setup:

  • Interface 'wg0'
  • ip address 192.168.9.1/24 (I have also tried 10.1.1.1/24)
  • port 51820
  • Public and Private keys populated with "Generate new key pair" button
  • Assigned to firewall zone 'lan' (note, some tutorials don't bother with this??)
  • Peer defined:
    • description = Surface Pro
    • Public and Private keys generated with "Generate new key pair" button
    • Preshared key not definted (trying to simplify and troubleshoot)
    • Allowed IP = 192.168.9.2/32
    • Route Allowed IP's = checked
    • Endpoint Port = 51820
Peer Configuration Export:
[Interface]
PrivateKey = redacted
Address = 192.168.9.2/32
ListenPort = 51820
DNS = 192.168.1.1

[Peer]
PublicKey = redacted
# PresharedKey not used
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = mydomain.com:51820
# PersistentKeepAlive not defined

Router rebooted, after which Status / WireGuard shows the Surface Pro peer, with 'Data Received' = 0, 'Data Transmitted' = 0, 'Latest Handshake' = Never

Surface Pro Laptop Peer:

  • WireGuard client installed
  • Tunnel set up by copy/pasting the results from the above Peer Configuration Export button

The problem: When I activate the WireGuard peer on the laptop, it doesn't complain, however, it never completes a handshake, and no data is being transferred. The running log says "Sending handshake initiation to peer ...." followed by "Handshake for peer 1 did not complete after 5 seconds". Over on the OpenWRT WireGuard Status page, it continues to show 0 bytes transmitted and Latest Handshake = Never.

Here are the contents of some relevant files on the router:
/etc/config/network:

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 'fda3:0542:98ba::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'

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 device
        option name 'wan'
        option macaddr 'redacted'

config interface 'wan'
        option device 'wan'
        option proto 'dhcp'

config interface 'wan6'
        option device 'wan'
        option proto 'dhcpv6'

config interface 'wg0'
        option proto 'wireguard'
        option private_key 'redacted'
        option listen_port '51820'
        list addresses '192.168.9.1/24'

config wireguard_wg0
        option description 'Surface Pro'
        option public_key 'redacted'
        option private_key 'redacted'
        list allowed_ips '192.168.9.2/32'
        option route_allowed_ips '1'
        option endpoint_port '51820'

/etc/config/firewall

config defaults
        option syn_flood '1'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'

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

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

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

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'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        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'

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'

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'

config redirect
        option dest 'lan'
        option target 'DNAT'
        option name 'WireGuard-Portfwd'
        list proto 'udp'
        option src 'wan'
        option src_dport '51820'
        option dest_ip '192.168.1.1'
        option dest_port '51820'

wg show

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

peer: redacted
  allowed ips: 192.168.9.2/32

Any and all advice very welcome. I feel like I am missing something simple.

2

Is the router's time correct?
https://openwrt.org/docs/guide-user/services/vpn/wireguard/extras#race_conditions

3

Appears to be, yes

4

Hi @ewjax

for WG to work, at least one side (peer) need to have public IP address.

first, you need to ensure that you have "good" public IP address, and not some CGNAT or private 192.168.x.x whatever on your WAN connector

5

remove the listen port from here:

Remove the endpoint port below:

This should be a rule, not a redirect. Remove this and make a traffic rule instead.

What is the IP address on the wan of your OpenWrt router? Please provide only the first two octets (in bold: aaa.bbb.ccc.ddd). You can find that information by running this command:

ubus call network.interface.wan status | grep address
1 Like
6

Hello @psherman and @NPeca75 , thank you for your replies!

Responses.

I have tried both those things, but will try again and confirm.

Can you say more about this? I had created this via the OpenWRT web interface, via "Network / Firewall / Port Forwards / Add". When I looked at /etc/config/firewall I had noticed it created the "redirect" entry, as opposed to everything else, which shows up as a rule. So I was suspicious about it but not sure how to address it.

IP Address of wan
This is the topic I'm most suspicious about, and both of you mention it, and what I'm seeing is confusing.

Results:

                "addresses",
        "ipv4-address": [
                        "address": "192.168.0.248",
        "ipv6-address": [
                "ipv4-address": [
                "ipv6-address": [

Also, here is a screen clip from the web interface "Status / Overview"

external

I have never intentionally set up anything on the 192.168.0.x subnet, so I am very confused why my wan is showing up at 192.168.0.248/24. It is also showing my gateway at 192.168.0.1. If you had asked me, I would have said gateway was at 192.168.1.1.

When I ping mydomain.com, I get replies from 104.21.x.y.

It seems to me that there is some router magic happening that is routing things from 104.21.x.y to 192.168.0.1?? Is that possibly the cause of my WireGuard issues?

7

Hi

yes, as i suspected
whatever box you have between your ISP and your OWRT is in router mode, so this box will "hide" your LAN behind 192.168.0.X network.
for your WG to work, you need 104.21.x.x address on your WAN port
only way to achive this is to ask your ISP to put their box in "bridge" mode
this way, your OWRT will become "the router", and you need to put all your device behind OWRT

8

Regarding your 192.168.0.1 WAN IP address.

What is the WAN port of the Linksys connected to?

If it is an ISP supplied 'router', can you log into it at 192.168.0.1 to manage it, and set up a port forward rule to 192.168.0.248 for port 51820 ?

Corrected.

9

A port forward is not applicable here -- port forwards are intended to literally forward the traffic to another device. Instead, a traffic rule is what should be used when the border device (i.e. router) is handling the service that will listen on the port that is being opened.

This means you are behind another router. Your ISP device (modem/ONT) is likely a combo unit modem+router type unit and it is running NAT masquerading.

Assuming that this is true, you have 3 options:

  1. Create a port forward on the ISP device that forwards UDP 51820 > 192.168.0.248 (or a DMZ to that same address will have the same effect, but it's less specific/granular)
  2. Change the ISP device to passthrough/bridge mode so that it sends the ISP issued IP address directly to your OpenWrt router
  3. Remove the ISP device entirely. This only works if the device is not also a physical media adapter (i.e. DSL/cable/cellular modem or ONT)
1 Like
10

192.168.0.0/24 is subnet which was provided by ISP box

It is also showing my gateway at 192.168.0.1. If you had asked me, I would have said gateway was at 192.168.1.1

you are confusing 2 different things
192.168.0.1 is a gateway provided by ISP box
192.168.1.1 is a gateway provided by OWRT for attached LAN devices

11

OMG. It never dawned on me that I was behind the ISP router. Of course. Although why that is significant for WireGuard is a mystery, but whatever, I'm content to push the "I Believe" button on that one for now.

Total mind explosion here. I only use their device for a modem. I totally forgot that it also has a router with dhcp and wifi and everything.

I just figured out how to get through the login portal at 192.168.0.1 (default login of admin/password. Yes, the password is password.) Gonna tinker with it and see how badly things break when I put it into bridge mode. If I don't post for a while, you will know I broke it badly...

12

because, you want that some random device in the wide world communicate with your OWRT and establish a WG tunnel
best way is to give your OWRT a real public IP
there is also a way as @psherman wrote, to set up port forwarding in ISP router, it is not so 'nice", but it is working after all ...

13

Well, with the discovery of the (embarrassingly obvious) ISP router (thanks to @psherman @bill888 and @NPeca75 for all pointing that out), at least one major source of confusion has been cleared up. However, the WireGuard problem is not resolved. Made me sad. I truly thought that was the 'eureka' moment I needed.

Steps taken:

  • ISP router at 192.168.0.1 put into Bridge mode
  • the ListenPort explicit 51280 entries in the peer definition removed on both OWRT and laptop peers
  • router rebooted

Results

 "address": "72.212.x.y",

which looks healthier.

However, the laptop peer still will not handshake.

Working through this now. The concepts of "zone" and "interface" are still new to me and muddy in my mind.

14

Remove the port forward (redirect) and add this instead:

config rule
        option name 'Allow-WireGuard'
        list proto 'udp'
        option src 'wan'
        option src_port '51820'
        option target 'ACCEPT'

If that doesn't solve the problem, please do the following test:

  • connect your (remote) peer to your OpenWrt's lan (i.e. your phone or laptop -- it should be physically local and on the same network for this next test)
  • on the remote peer, change the endpoint address to 192.168.1.1
  • start a connection
  • post the output of wg show from the router itself right after the connection attempt.
15

Traffic rule successfully created using the guidance provided. Thanks, the concepts of 'interface' and 'zone' are new and still muddy to me.

However, that did not enable handshake. Using your next idea:

  • remote peer connected to lan wifi. IP = 192.168.1.197
  • remote peer Endpoint set to 192.168.1.1:51820

And finally, successful connection and handshake. So now I have the ability to vpn to my own network, from within my network, yay! Sorry, haha, gotta celebrate the small victories...

Results of wg show:

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

peer: key-redacted
  endpoint: 192.168.1.197:57202
  allowed ips: 192.168.9.2/32
  latest handshake: 22 seconds ago
  transfer: 118.54 KiB received, 116.86 KiB sent

I think what that suggests is WireGuard is not playing well with my DDNS setup for 'mydomain.com'

But I guess we also learned at least that all the private and public keys on both peers seems to be set up correctly.

16

Yes... worth celebrating because it indicates the WG is generally configured properly. That is a win. In actual practice, of course, this specific development has no practical use, but the value was validating WG.

Maybe...
Next, we'll try using a direct IP connection rather than ddns.

Use the address from above (obviously in its non-redacted state) as the endpoint host in your WG config. I am assuming that your remote peer is a phone -- turn off wifi and then attempt to make a connection using the cellular network.

17

For clarity, in case it matters, the remote peer is actually a Surface Pro laptop. It is sitting on my desk but to simulate "remoteness" I am connecting it via wifi to a little travel router I have. In it's "simulated remote" state, it has been given an IP address of 192.168.8.196, which it got from the travel router dhcp. The travel router sits at 192.168.8.1.

I don't think that matters, but I wanted to mention it in case it does, since you were talking about phones. I think this accomplishes the same idea but in a different manner.

Latest results:

  • reconnected laptop to travel router, IP = 192.168.8.196
  • laptop wireguard peer configured with Endpoint = 72.212.x.y:51820

Results = connection and handshake success

18

Your laptop is still ultimately connecting through the same router and internet connection, though, right?

It is good that the handshake succeeded here, but we need to test with a truly external connection. Does your phone offer a hotspot function? Could you disconnect your phone from your local wifi, then enable the hotspot and connect the surface pro to the phone's hotspot... then try again.

19

I can also confirm this problem on wrt1900acsv2 Snapshot versionin the scheme of the same configuration on GL MT6000 it works!

20

ultimately, yes. The travel router wan port is currently connected via cat5 to one of the home lan switches. I was thinking that anything that connected to the travel router wlan wifi, with a 192.168.8.x IP address, would not be able to see anything on the home lan 192.168.1.x network.

But now I'm not so sure. From the laptop I was able to ping 192.168.1.1, which surprised me, so I think you're right, it's not a good test.

I'll give this some thought. Unfortunately my cell LTE reception here is weak, so I'm not confident switching to the wifi-less phone will be a good test.