Wireguard DDNS

[kavie87]

I’m looking at upgrading from my current router to a AX86U Pro or GT-AX6000.
Was hoping for some assistance.
I want to set it up as Wireguard Server. It will be running behind double nat… port forwarding is already setup and works fine currently with my current router running wireguard. I am able to chuck in DDNS details that my Linux box updates with Cloudflare. Whenever I setup clients it will put the DDNS as the IP address even though I don’t have DDNS setup.

Hopefully that makes sense. Essentially can I put in DDNS details that will come across when I setup a wireguard client even though I don’t want the router to update the Public IP address…

 

[CaptainSTX]

Running two WireGuard clients on my AX86S. When I do this and also run WireGuard on a device behind this router the download speed on the device drops to around 250 Mbps. If I disable the WireGuard clients on the AX86 the download speed on the device jumps to 800+ Mbps. When I have the WireGuard clients running and on the AX86S and run an OpenVPN client on the device my download is again 800+ Mbps. Similar situation if I run OpenVPN clients on the AX86 and then run the WireGuard client on the device with download speeds of 800+ Mbps. All NAT pass through settings enabled.

Any suggestions on whatever settings could be changed to allow higher download speeds when running a WireGurard client behind the router when running WireGuard clients on the router.

When testing all clients are going to different servers. Same result using 388.2.2 or 388.4 firmware.

 

[Tech Junky]

WireGuard clients on the router.

While wg is lightweight compared to ovpn it's going to need a better CPU for higher performance.

WG will spawn additional processes as demand ramps up which will exhaust the CPU of resources.

 

[CaptainSTX]

While wg is lightweight compared to ovpn it's going to need a better CPU for higher performance.

WG will spawn additional processes as demand ramps up which will exhaust the CPU of resources.

I started using WireGuard on my AX86S not because of its better throughput which wasn't that important for the IoT devices connecting but because it is more stable. It seemed that my OpenVPN clients would disconnect once a week or so while I never had any problems with the WireGuard clients.

The issue I would like to solve is why if I'm running WireGuard clients on the AX86S why can't other clients connected and running their own WireGuard client not obtain a download speed of 800+ Mbps when running their own WireGuard client? They can get this speed if the WireGuard clients are not running on the AX86S or if the AX86S is running OpenVPN clients.

 

[Tech Junky]

800+ Mbps

Putting a tunnel in a tunnel will cause issues with performance. It's kind of like double nat but worse. Pick one and stick with it vs trying to put it in two places.

Using WG for quite awhile now and if you put it on the edge of the network aka router then why would you need it on the clients?

WG sets up a connection to the VPN provider and NAT's the connection through its own interface to tunnel the traffic through the VPN endpoint.

So, of you send it out WG-A through the router but then have a client on WG-B it has to go out A to get to B and then back through the same in reverse. If the paths to the "site" aren't optimal then you'll see reduced speed test results. Also, not all ST sites have the best bandwidth or servers for producing reliable results. Not to mention OVPN uses TCP and WG uses UDP which gives WG faster speed but, can cause issues with the connection if the packets get dropped over another VPN connection.

Basically if you KISS it then it just works and works well.

 

[CaptainSTX]

Putting a tunnel in a tunnel will cause issues with performance. It's kind of like double nat but worse. Pick one and stick with it vs trying to put it in two places.

Using WG for quite awhile now and if you put it on the edge of the network aka router then why would you need it on the clients?

WG sets up a connection to the VPN provider and NAT's the connection through its own interface to tunnel the traffic through the VPN endpoint.

So, of you send it out WG-A through the router but then have a client on WG-B it has to go out A to get to B and then back through the same in reverse. If the paths to the "site" aren't optimal then you'll see reduced speed test results. Also, not all ST sites have the best bandwidth or servers for producing reliable results. Not to mention OVPN uses TCP and WG uses UDP which gives WG faster speed but, can cause issues with the connection if the packets get dropped over another VPN connection.

Basically if you KISS it then it just works and works well.

Not supposed to be a tunnel in a tunnel and as I previously said the AX86S is using VPN manager and the device is supposed to connect using the WAN connection to the Internet to avoid a double tunnel. The reduction in speed certainly seems to be the result of a double tunnel when running WG clients on AX86. I have also tried some routing rules to try and be sure the connection from the device runs outside the AX86 VPN tunnel. I choose to run the VPN client on the device because it has the processor speed to handle either an OpenVPN or WG connection at over 800 Mbps. Everything works as expected if AX86 is running OpenVPN clients. Looking for what is different when running WG.

 

[Tech Junky]

what is different when running WG.

WG spawns more sessions as speed ramps up and could deplete resources if you're pegging the speed of the connection.

The cheap router CPU can't handle a ton of threads when pushing the data.

I wouldn't trust anything Asus says to actually happen though when invoking features through their SW.

WG should be on the clients or only on the router forcing all traffic through said VPN
OVPN should just be disabled and never bothered with again due to low performance.

External access to your LAN through a VPN should be minimized for security reasons. If you need to expose services / devices then approaching this with another method such as SSH would be more secure. Using a SSH knock on a specific port other than the common ports would be better.