What's new

Accessing remotly Server While Using VPN on Asus Router with Merlin Firmware

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

psimaker

New Around Here
Hello everyone,

I’m facing an issue with my Asus router (Model: BE88U running Merlin firmware (version: [3006.102.2]). I’ve configured a Mullvad VPN connection through OpenVPN (tried wireguard also) to route all my network traffic through the VPN. However, I need to access remotely my home server, while keeping the rest of the server’s traffic routed through the VPN.

Setup and Goal:

  • My home server’s local IP is 192.168.8.112.
  • I want to access ports 22, 80, 443, and 32400
  • All traffic should go through the VPN.
What I’ve Tried So Far:

  1. I set up policy-based routing rules to attempt to route.
  2. I also configured port forwarding for these ports, intending to make them accessible externally via the WAN IP while the VPN connection is active.
Any ideas how I could reach that? On my old Glinet router, I had no issues.

Thanks in advance for any help!
 
Any device bound to the VPN is NOT accessible over the WAN because of reverse-path filtering, which requires inbound traffic (such as that coming from remote access) to exit through the same network interface. IOW, you can't create a situation of WAN in/VPN out, or vice versa. It has to be WAN in/WAN out, or VPN in/VPN out.

One obvious way to work around the issue is to always access devices bound to the VPN, over the VPN rather than the WAN, provided your VPN provider allows it (most do NOT).

Another is to create static routes that bind the incoming source IP from remote access over the WAN, to the WAN, but that assumes you have the ability to KNOW ahead of time what those source IPs are likely to be (workplace, school, local wifi cafe, etc.).

At least those are the relatively easy solutions.

Another possibility is binding the app/service that's the target of remote access over the WAN to a secondary IP network (aka, multihoming), along w/ the router, thus isolating that particular app/service from the VPN, even though everything else on the target device is still bound to the VPN. Needless to say, it's a bit more complicated to configure.

I've also seen some ppl create a guest VM for the specific app(s) they wanted routed over the WAN. This works because the host and guest VM are typically using different source IPs, and can thus be managed independently wrt the VPN Director.

It's also theoretically possible to implement your own PBR (policy based routing) rather than depend on the VPN Director, one which is more finely-grained and similarly directs traffic either over the WAN or VPN based on other criteria and NOT just the source IP (e.g., source port).
 
Any device bound to the VPN is NOT accessible over the WAN because of reverse-path filtering, which requires inbound traffic (such as that coming from remote access) to exit through the same network interface. IOW, you can't create a situation of WAN in/VPN out, or vice versa. It has to be WAN in/WAN out, or VPN in/VPN out.

One obvious way to work around the issue is to always access devices bound to the VPN, over the VPN rather than the WAN, provided your VPN provider allows it (most do NOT).

Another is to create static routes that bind the incoming source IP from remote access over the WAN, to the WAN, but that assumes you have the ability to KNOW ahead of time what those source IPs are likely to be (workplace, school, local wifi cafe, etc.).

At least those are the relatively easy solutions.

Another possibility is binding the app/service that's the target of remote access over the WAN to a secondary IP network (aka, multihoming), along w/ the router, thus isolating that particular app/service from the VPN, even though everything else on the target device is still bound to the VPN. Needless to say, it's a bit more complicated to configure.

I've also seen some ppl create a guest VM for the specific app(s) they wanted routed over the WAN. This works because the host and guest VM are typically using different source IPs, and can thus be managed independently wrt the VPN Director.

It's also theoretically possible to implement your own PBR (policy based routing) rather than depend on the VPN Director, one which is more finely-grained and similarly directs traffic either over the WAN or VPN based on other criteria and NOT just the source IP (e.g., source port).


Thanks a lot for your reply.

I think there is no way that is not plossible.First of all it was possible without any problems on my GLinet Router

On GLinet there is a settings like:

photo_2024-11-07_08-57-12.jpg


The main goal is that I want to reach each subdomain via these ports on my server but the VPN traffic should stay untouched.
 
You're comparing apples to oranges.

I can't speak to the issue of WG since I don't know how it's actually configured on that or any other router. I can only speak to the issue of OpenVPN client as you originally described it. The only legitimate comparison at the moment is the use of OpenVPN client on the GL.iNet (or any other) router w/ the same configuration.

The problem is nothing new. It pops up on this and other forums all the time.





In fact, I just had someone a few days ago using DD-WRT w/ the same problem.


(see the last post, by me, in that thread)
 
You're comparing apples to oranges.

I can't speak to the issue of WG since I don't know how it's actually configured on that or any other router. I can only speak to the issue of OpenVPN client as you originally described it. The only legitimate comparison at the moment is the use of OpenVPN client on the GL.iNet (or any other) router w/ the same configuration.

The problem is nothing new. It pops up on this and other forums all the time.





In fact, I just had someone a few days ago using DD-WRT w/ the same problem.


(see the last post, by me, in that thread)
I think I have found a solution.
If the IP range of the VPN operator is manageable, let's say 193.33.127.xxx
For Mullvad you could look it up (https://mullvad.net/de/servers), then pick up the Wireguard Server you want.
Then you could release 193.33.127.0/24 via the director (remote IP to WAN)

Hopefully there is no big security issue with this settings.
 
I think I have found a solution.
If the IP range of the VPN operator is manageable, let's say 193.33.127.xxx
For Mullvad you could look it up (https://mullvad.net/de/servers), then pick up the Wireguard Server you want.
Then you could release 193.33.127.0/24 via the director (remote IP to WAN)

Hopefully there is no big security issue with this settings.

Sorry, I don't understand what you're trying to say.

As long as any given LAN device is NOT bound to the VPN, it will remain accessible via the WAN. If that's what you've effectively done (which is what I originally suggested), then yes, that device will be reachable over the WAN.
 
Every device uses VPN.
I wanted my server to also use VPN through the router. The problem was that Nextcloud, for example, could not be reached via the domain as long as I had set the VPN connection. I have now added the following rule under “VPN Director”: “Iface” = WAN and ‘Remote IP’ = IP from VPN provider
Now I also have VPN on my server and the domain of my Nextcloud can be reached externally.
 
Every device uses VPN.
I wanted my server to also use VPN through the router. The problem was that Nextcloud, for example, could not be reached via the domain as long as I had set the VPN connection. I have now added the following rule under “VPN Director”: “Iface” = WAN and ‘Remote IP’ = IP from VPN provider
Now I also have VPN on my server and the domain of my Nextcloud can be reached externally.

When you specify the Remote IP w/ the VPN director, you are effectively creating a static route that binds that IP to the WAN, which is what I originally suggested as a workaround.

Another is to create static routes that bind the incoming source IP from remote access over the WAN, to the WAN, but that assumes you have the ability to KNOW ahead of time what those source IPs are likely to be (workplace, school, local wifi cafe, etc.).

And as I indicated, this assumes you KNOW what that IP will be.

IOW, when the remote access occurs over the WAN w/ that source IP, you have specifically told the router to route that traffic back out the WAN, but now as a destination IP, since it is a now a reply. That's why static routing works. You end up bypassing the fact the router has otherwise bound replies from the target of remote access over the WAN to the VPN.
 
Thank you so much for your detailed and helpful response! I really appreciate you taking the time to guide me through this.
I have one quick question: based on your knowledge, are there any potential security risks with this configuration that I should be aware of? I want to ensure my setup is not only functional but also secure in the long term.

Thanks again for your support!
 
Irrespective of your particular issue in this thread, and in general, we do NOT recommend accessing services directly over the WAN, but instead using a VPN (e.g., OpenVPN server).

That has alway been a major concern since you're now relying solely on the target of that remote access to protect you. And whether the target is sufficiently hardened against potential attacks will vary greatly depending on the service and its implementation. But if you force that access through a VPN server, at least that creates an additional and significant hurdle for hackers. And the VPN server is known to be hardened against such attacks since that's it's primary function. That is NOT the case w/ other services.

That's why, for example, users who use RDP over the WAN are far more likely to be attacked then those that use a VPN server and access RDP as a local reference (i.e., by the private IP on the LAN).

I realize that sometimes you have no choice but to do remote access over the WAN. But whenever possible, you should be using a VPN server of some type.
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top