Setting up Wireguard server with Asus RT68U-AC

[Johno]

I've installed Wireguard server on a Raspberry Pi3 and have it configured to run as a service listening on a specified port, with all UDP traffic to the specified port on the WAN's static IP address forwarded to the Pi3. With the Wireguard client installed on a laptop connected to the same wireless network, activating the WG client connection causes the following log warning:

2020-05-03 00:20:21.984: [TUN] [SP4] peer(A/BI…7rTY) - Handshake did not complete after 5 seconds, retrying (try 2)

The server endpoint is defined as my router's public IP address and port number but I'm wondering if a laptop on the same network as the WG server would have it's traffic bypass the WAN interface and hence the port forwarding and hence not be directed to the Raspi3 and so the WG client can't connect to the WG server?

I've tethered the same laptop to my smartphone's WiFi hotspot so that the WG client is talking to the router from outside the LAN via the phone's mobile data network but still no difference - the WG client log still shows the "handshake did not complete" warning and no connection is established with the WG server.

Can anyone suggest whether any router settings will affect the connection? I read something on another post about disabling NAT acceleration doing the trick so I've done the same, but to no avail.

Any ideas anyone?

 

[Wallace_n_Gromit]

I've installed Wireguard server on a Raspberry Pi3 and have it configured to run as a service listening on a specified port, with all UDP traffic to the specified port on the WAN's static IP address forwarded to the Pi3. With the Wireguard client installed on a laptop connected to the same wireless network, activating the WG client connection causes the following log warning:

2020-05-03 00:20:21.984: [TUN] [SP4] peer(A/BI…7rTY) - Handshake did not complete after 5 seconds, retrying (try 2)

The server endpoint is defined as my router's public IP address and port number but I'm wondering if a laptop on the same network as the WG server would have it's traffic bypass the WAN interface and hence the port forwarding and hence not be directed to the Raspi 3 and so the WG client can't connect to the WG server?

In the past have run a Raspberry Pi 1 OpenVPN server behind my Router listening behind a 68U with Wan traffic coming into a User-defined port being redirected to the Pi. Have thought about trying something like what you are doing.
I agree that the issue you would have using a laptop on the LAN side is that you could not be routed/forwarded by the router back into the LAN side Raspberry Pi Server. BUT if you had a Paid VPN service (like NordVPN) in which your laptop could appear into the internet outside your LAN, then try to access your Raspberry VPN then that should work, assuming everything was configured correctly. (Not that you should get one, just talking about how I tested my own VPN server connectivity.)

I've tethered the same laptop to my smartphone's WiFi hotspot so that the WG client is talking to the router from outside the LAN via the phone's mobile data network but still no difference - the WG client log still shows the "handshake did not complete" warning and no connection is established with the WG server.

That is similar to the second way I have used to fool the router into thinking my LAN device is not on my LAN to test my connection. Did you have access to your local router Wi-Fi disabled as you had the hotspot enabled?

Can anyone suggest whether any router settings will affect the connection? I read something on another post about disabling NAT acceleration doing the trick so I've done the same, but to no avail.

Any ideas anyone?

1) Are you using more than one router? The easiest way to set up VPN is to have Raspberry VPN set up at the Gateway router nearest the ISP
2) Did you set up a static LAN IP address/port in your router for the Raspberry Pi ? (you mentioned a static WAN IP) For example 192.168.1.77:1194
3)You, of course, set up the router to forward packet traffic from a user-defined port on WAN side to the static IP address on LAN side. for example ISP_WAN_IP:8194 >> 192.168.1.77:1194

I'm not an expert on VPN stuff( and know nothing about Wireguard), justing trying to brainstorm thoughts about some issues I seems to vaguely remember in the routing of packets from/to the WAN/LAN that I experienced .

 

[Johno]

In the past have run a Raspberry Pi 1 OpenVPN server behind my Router listening behind a 68U with Wan traffic coming into a User-defined port being redirected to the Pi. Have thought about trying something like what you are doing.
I agree that the issue you would have using a laptop on the LAN side is that you could not be routed/forwarded by the router back into the LAN side Raspberry Pi Server. BUT if you had a Paid VPN service (like NordVPN) in which your laptop could appear into the internet outside your LAN, then try to access your Raspberry VPN then that should work, assuming everything was configured correctly. (Not that you should get one, just talking about how I tested my own VPN server connectivity.)



That is similar to the second way I have used to fool the router into thinking my LAN device is not on my LAN to test my connection. Did you have access to your local router Wi-Fi disabled as you had the hotspot enabled?



1) Are you using more than one router? The easiest way to set up VPN is to have Raspberry VPN set up at the Gateway router nearest the ISP
2) Did you set up a static LAN IP address/port in your router for the Raspberry Pi ? (you mentioned a static WAN IP) For example 192.168.1.77:1194
3)You, of course, set up the router to forward packet traffic from a user-defined port on WAN side to the static IP address on LAN side. for example ISP_WAN_IP:8194 >> 192.168.1.77:1194

I'm not an expert on VPN stuff( and know nothing about Wireguard), justing trying to brainstorm thoughts about some issues I seems to vaguely remember in the routing of packets from/to the WAN/LAN that I experienced .

Thanks for the info and suggestions, I discovered that the ethernet interface on my RaspPi was named something other then eth0 so I fixed that and thought to myself that must have been the problem, but still no joy.

I've connected my laptop to my phone's mobile data hotspot and confirmed that my IP address was an external one, then started up the WG client app, activated it and the log now says that it's connected, but the wg command in an SSH session on the RaspPi doesn't show that anything is connected to the WG server.

There's only one router (the gateway) which assigns to same IP from the DHCP server to the RaspPi and the port forwarding specifies the port number (I'm using the same port number for both server and client)

 

[Wallace_n_Gromit]

Thanks for the info and suggestions, I discovered that the ethernet interface on my RaspPi was named something other then eth0 so I fixed that and thought to myself that must have been the problem, but still no joy.

I've connected my laptop to my phone's mobile data hotspot and confirmed that my IP address was an external one, then started up the WG client app, activated it and the log now says that it's connected, but the wg command in an SSH session on the RaspPi doesn't show that anything is connected to the WG server.

There's only one router (the gateway) which assigns to same IP from the DHCP server to the RaspPi and the port forwarding specifies the port number (I'm using the same port number for both server and client)

https://pivpn.io/
http://bitman.org/irafinch/rpivpn/

In the past, I have experimented/set up Raspberry Pi VPN server(s) behind my Router(s) using PiVPN and a book bought on Amazon. The author of the book is pondering adding Wireguard option to his current book, or writing another one. I currently have a Rpi running Ira Finch's implementation of OpenVPN server behind my router on those occasions that I happen to be out and about/traveling on public/hotel wifi's and want to switch between AsusWRT VPN server and Rpi VPN server.

I did notice that recently the pivpn.io site says their inplementation now offers Wireguard as well as OpenVPN. Has anyone experimented with that implementation?

Maybe a good suggestion is to try several different implementations of wireguard including https://www.pivpn.io/ just to get something that works? Then see how they did it (syntax, settings etc) to troubleshoot your configuration?

Also, try the thread https://www.snbforums.com/threads/wireguard-implementation.59784/

and try this one, https://www.snbforums.com/threads/experimental-wireguard-for-rt-ac86u-ax88u.46164/ ...your question might be off topic a bit, but someone might have already come across an issue like yours and be willing to help troubleshoot.

 

[Johno]

Maybe a good suggestion is to try several different implementations of wireguard including https://www.pivpn.io/ just to get something that works? Then see how they did it (syntax, settings etc) to troubleshoot your configuration?

Also, try the thread https://www.snbforums.com/threads/wireguard-implementation.59784/

and try this one, https://www.snbforums.com/threads/experimental-wireguard-for-rt-ac86u-ax88u.46164/ ...your question might be off topic a bit, but someone might have already come across an issue like yours and be willing to help troubleshoot.

Thanks again.
I've just done a test using Shields Up page on grc.com to see if port 51820 is actually open and it doesn't appear to be! Is there a maximum port number that can be forwarded by an Asus RT-AC68U router? I would've thought port range would be up to 65535

 

[Johno]

I've determined that the RaspPi3 is indeed listening to port 51820 using the command netstat -a | grep 51820 so it must be the router doing something weird with that port.

 

[Martineau]

I've determined that the RaspPi3 is indeed listening to port 51820 using the command netstat -a | grep 51820 so it must be the router doing something weird with that port.

Do any of the iptables rules actually register hits ?

nvram get vts_rulelist

iptables  --line -t nat -nvL PREROUTING; iptables --line -t nat -nvL VSERVER

 

[Johno]

Thanks, the virtual server rules are all there and it looks like some traffic coming through, if I'm interpreting the following correctly, though 528 bytes doesn't seem much:

Chain PREROUTING (policy ACCEPT 15120 packets, 1701K bytes)
num pkts bytes target prot opt in out source destination
1 2935 133K VSERVER all -- * * 0.0.0.0/0 80.229.251.220
2 0 0 VSERVER all -- * * 0.0.0.0/0 169.254.213.135
3 2088 140K DNSFILTER udp -- * * 192.168.1.0/24 0.0.0.0/0 udp dpt:53
4 6 356 DNSFILTER tcp -- * * 192.168.1.0/24 0.0.0.0/0 tcp dpt:53
Chain VSERVER (2 references)
num pkts bytes target prot opt in out source destination
1 0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4672 to:192.168.1.1
2 0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4665 to:192.168.1.1
3 0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:4662 to:192.168.1.1
4 0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:51413 to:192.168.1.1
5 0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:51413 to:192.168.1.1
6 3 144 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:6881:6889 to:192.168.1.66
7 2 104 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:32976 to:192.168.1.80
8 3 528 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:51820 to:192.1.168.81:51820
9 2927 133K VUPNP all -- * * 0.0.0.0/0 0.0.0.0/0

Though having said that, each time I initiate a connection from a Wireguard client, the bytes received figure reported by iptables increases by 176 bytes when the client sends a handshake initiation, so that would indicate that port forwarding is working after all.

I'm stumped.

 

[Martineau]

Thanks, the virtual server rules are all there and it looks like some traffic coming through, if I'm interpreting the following correctly, though 528 bytes doesn't seem much:

Chain PREROUTING (policy ACCEPT 15120 packets, 1701K bytes)
num pkts bytes target prot opt in out source destination
1 2935 133K VSERVER all -- * * 0.0.0.0/0 80.229.251.220
2 0 0 VSERVER all -- * * 0.0.0.0/0 169.254.213.135
3 2088 140K DNSFILTER udp -- * * 192.168.1.0/24 0.0.0.0/0 udp dpt:53
4 6 356 DNSFILTER tcp -- * * 192.168.1.0/24 0.0.0.0/0 tcp dpt:53

Chain VSERVER (2 references)
num pkts bytes target prot opt in out source destination
1 0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4672 to:192.168.1.1
2 0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4665 to:192.168.1.1
3 0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:4662 to:192.168.1.1
4 0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:51413 to:192.168.1.1
5 0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:51413 to:192.168.1.1
6 3 144 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:6881:6889 to:192.168.1.66
7 2 104 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:32976 to:192.168.1.80
8 3 528 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:51820 to:192.1.168.81:51820
9 2927 133K VUPNP all -- * * 0.0.0.0/0 0.0.0.0/0

Well you could always reset the stats for the Port Forward chain

iptables -Z -t nat -nvL VSERVER

then wait a few mins to see if there are any unsolicited hits, then try the Shields Up and see how many bytes are received as a result of the test.

Either way at least you now know to check for yourself if Port Forwarding is working, rather than rely on grc.com.

 

[Johno]

Thanks for the useful commands, I'll try what you've said but it does seem that port forwarding is working, so may have to see what happening with the Wireguard server on the Pi3

 

[ColinTaylor]

I've just done a test using Shields Up page on grc.com to see if port 51820 is actually open and it doesn't appear to be!

That's because Shields Up can only test TCP ports and you are using UDP which is stateless.

 

[Johno]

That's because Shields Up can only test TCP ports and you are using UDP which is stateless.

Ah, of course