WireGuard VPN routing

[ragnaroknroll]

I've been running Asuswrt-Merlin on my RT-AX86U router for over a year now and just noticed that the latest firmware supports a WireGuard VPN server! I've just replaced my OpenVPN server with a WireGuard one, but had a question and wanted to ask if what I want to achieve is even possible. Currently, when a WireGuard client connects to my router's WireGuard VPN server, the external IP address the client sees is the router's static IP address my ISP gives me. I'd like to route all internet traffic from my WireGuard clients through the Surfshark WireGuard VPN client configured on my router, so that the external IP address the client sees is Surfshark's IP address. Traffic from all devices connected directly to the router are currently being directed through Surfshark, but not the devices connected via the router's WireGuard server. Is there any way I can achieve this?

 

[ragnaroknroll]

Ah never mind! Just as I posted this, I realised I could achieve what I want via a simple VPN Director rule. Problem solved!

 

[ragnaroknroll]

On a related topic, when previously using an OpenVPN server, I used to require a VPN Director rule like the one below, in order for clients to be able to connect to the server while the router was separately connected to the Surfshark VPN service as a client.

Local IP: <router local IP address>, Remote IP: 0.0.0.0, Iface: WAN

Now that I've stopped the OpenVPN server and started a WireGuard server instead, I don't seem to need this VPN Director rule any more. Clients are able to connect even when this rule is disabled and I'm connected to Surfshark. Is this by design? I would have expected any connections to the router's WireGuard server to have to come via Surfshark through port forwarding (although I'm aware Surfshark does not support port forwarding).

Any help figuring out why this works would be much appreciated.

 

[ragnaroknroll]

On a related topic, when previously using an OpenVPN server, I used to require a VPN Director rule like the one below, in order for clients to be able to connect to the server while the router was separately connected to the Surfshark VPN service as a client.

Local IP: <router local IP address>, Remote IP: 0.0.0.0, Iface: WAN

Now that I've stopped the OpenVPN server and started a WireGuard server instead, I don't seem to need this VPN Director rule any more. Clients are able to connect even when this rule is disabled and I'm connected to Surfshark. Is this by design? I would have expected any connections to the router's WireGuard server to have to come via Surfshark through port forwarding (although I'm aware Surfshark does not support port forwarding).

Any help figuring out why this works would be much appreciated.

Hi All. Any assistance with this would be much appreciated. Thanks!

 

[ZebMcKayhan]

On a related topic, when previously using an OpenVPN server, I used to require a VPN Director rule like the one below, in order for clients to be able to connect to the server while the router was separately connected to the Surfshark VPN service as a client.

Local IP: <router local IP address>, Remote IP: 0.0.0.0, Iface: WAN

Now that I've stopped the OpenVPN server and started a WireGuard server instead, I don't seem to need this VPN Director rule any more. Clients are able to connect even when this rule is disabled and I'm connected to Surfshark. Is this by design? I would have expected any connections to the router's WireGuard server to have to come via Surfshark through port forwarding (although I'm aware Surfshark does not support port forwarding).

Any help figuring out why this works would be much appreciated.

If I understand your question correct:

Wireguard is only implemented using policy rules, meaning it cannot be set as default route (as I suspect you had with OpenVPN). This solve the issue you had before which you solved with your rule, while giving you a new issue. Without additional rules you cannot communicate between lan client set to use vpn and server clients as the lan clients use the policy route table which does not contain any routes to your sever clients.

Using policy rules means all data generated by the router itself (dns lookups, ntp et.c) is done over wan and not vpn so your server will naturally use wan to connect your server to the clients.

Or perhaps Im misunderstanding something? What you mean by <router local IP address>? Like 192.168.50.1? Router would only be using this ip when communicating with your lan so I dont know what purpose such rule will have. Routes to your lan is typically in the policy route table. Perhaps something with OpenVPN implementation makes OpenVPN local process to use lan ip as source address?

 

[ragnaroknroll]

@ZebMcKayhan - Thanks for your response. Let me try to explain my question a bit more clearly. I think I may have been a bit too terse when describing in previously.

I have a static IP address provided to me by my ISP. Let's assume this static IP address is a.b.c.d. Let the local IP address assigned to my router be 192.68.1.1.

I have my router configured to connect to the Surfshark VPN service using the VPN Client tab, on the OVPN1 interface. In order to ensure that all my local network clients have their internet traffic directed through OVPN1, I have the following VPN Director rule:

RULE #1: Local IP: 192.168.1.0/24, Remote IP: 0.0.0.0, Iface: OVPN1

I used to run an OpenVPN server on my router, so that I could connect my mobile phone to my home network when using its data connection. The problem was that since my router was connected to Surfshark and routing all its internet traffic through Surfshark's VPN servers, my mobile phone could not access the OpenVPN server running on the router using the IP address a.b.c.d. In order to do this, I had to add the following VPN Director rule to direct all traffic destined directly to the router via the WAN, and not through OVPN1.

RULE #2: Local IP: 192.168.1.1, Remote IP: 0.0.0.0, Iface: WAN

Now that I have turned off the OpenVPN server on my router and started running a WireGuard VPN server since the service became available, I can see that I now no longer need the VPN Director Rule #2. I don't understand why this rule is not needed, since the presence of Rule #1 should imply that all traffic is routed through Surfshark's VPN servers, and my router should not be accessible via a.b.c.d. Nevertheless, my mobile phone is still able to connect to my router's WireGuard VPN server using the IP address a.b.c.d. Is this by design? I would have expected that in order to achieve this, I would either need Rule #2 or configure port forwarding on Surfshark's VPN servers (forwarding the port number my router's WireGuard VPN server is configured to listen on) so that my mobile phone connects to my router's WireGuard VPN server through Surfshark's VPN server.

PS: I recognise Surfshark doesn't provide port forwarding, so the last bit was just hypothetical.

 

[ZebMcKayhan]

The problem was that since my router was connected to Surfshark and routing all its internet traffic through Surfshark's VPN servers

Well, if your OpenVPN client was set to policy route and you used your Rule #1 to redirect your LAN to vpn your router will still access internet typically over WAN. so I would say that statement is not entirely correct.

The problem was that since my router was connected to Surfshark and routing all its internet traffic through Surfshark's VPN servers, my mobile phone could not access the OpenVPN server running on the router using the IP address a.b.c.d. In order to do this, I had to add the following VPN Director rule to direct all traffic destined directly to the router via the WAN, and not through OVPN1.

RULE #2: Local IP: 192.168.1.1, Remote IP: 0.0.0.0, Iface: WAN

well, since the router "local service" will still be accessing internet via a.b.c.d interface. and thus using the source address a.b.c.d. it will not be included in your rule anyway.

But OpenVPN and Wireguard are 2 very different implementations and I dont know all the details about OpenVPN as I have never used it. There are possibilities that there are some parts of OpenVPN that would bind to lan ip 192.168.1.1 and if so, it will not have access to any of your server clients because it is redirected to a policy table which does not include any other VPN routes then the VPN assigned to it.

Wireguard does not bind to any lan address so it will continue communicate on interface a.b.c.d. although the issue remains with clients set to use the VPN policy table typically has no route to your server clients. a similar rule would be needed on VPNDirector for this, but I would rather formulate the rule as:
RULE #2: Local IP: 0.0.0.0/0, Remote IP: 10.6.0.0/24, Iface: WAN

the rule will achieve similar results as your intended #2 rule but with a more targeted approach which will work on a more broader config.

I don't understand why this rule is not needed, since the presence of Rule #1 should imply that all traffic is routed through Surfshark's VPN servers

I could only conclude that there must be something in OpenVPN that seems to bind to your lan-ip so the answer would be in the difference between OpenVPN and Wireguard.

hoping someone with deeper OpenVPN knowledge could answer why this rule is needed on OpenVPN.

 

[ragnaroknroll]

Thanks @ZebMcKayhan. For what it's worth, here's a thread which describes the original issue I was facing, where I was unable to have VPN clients connect to my router's OpenVPN server, when the router was also connected to a VPN service as a client.

Setup VPN Server and Client

Hello, noob here with minimal CS background. I've been trying to setup VPN server and client on my AX82U. Once I activate my OpenVPN server (created with Vultr VPS, but considering testing NordVPN, because there was 30-40Mbps limit) Once I activate VPN client on Router, I can't connect to...

www.snbforums.com

I can also attest to the fact that I've been able to get around this issue using Rule #2 for at least a few years now, before switching to WireGuard, which now does not require Rule #2.

Also, my WireGuard clients are able to access local network resources by just checking the "Access Intranet" option on the VPN Server configuration page. This works even when Rule #1 is enabled.

 

[ZebMcKayhan]

For what it's worth, here's a thread which describes the original issue I was facing

Thanks, but no details are in there. My impression is that the linked thread was about using OpenVPN in default route (All) mode.

Also, my WireGuard clients are able to access local network resources by just checking the "Access Intranet" option on the VPN Server configuration page. This works even when Rule #1 is enabled.

Alright, cool. Then perhaps Im wrong and Merlin does this differently from Asus and include the server routes in the policy table. Thats good news.

 

[ragnaroknroll]

Thanks, but no details are in there. My impression is that the linked thread was about using OpenVPN in default route (All) mode.

Oh, that was just another thread that describes the issue I was originally facing, which led me down this rabbithole, wherein I was unable to have VPN clients connect to my router's OpenVPN server, when the router was also connected to a VPN service (e.g. Surfshark) as a client.

 

[stevieosaurus]

How does the Wireguard work in the VPN director (default ASUS/Merlin GUI), if multiple connections are active, do they work:

1. as aggregate? Meaning you get faster internet speeds divided between connections?
or...
2. as simple failover, when one fails, the next one is automatically used?
or...
3. both? none of the above? Help me understand pls.

 

[RMerlin]

How does the Wireguard work in the VPN director (default ASUS/Merlin GUI), if multiple connections are active, do they work:

1. as aggregate? Meaning you get faster internet speeds divided between connections?
or...
2. as simple failover, when one fails, the next one is automatically used?
or...
3. both? none of the above? Help me understand pls.

First matching rule is applied, as per the documented priority:

VPN Director

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com