Tried Searching but Didn't Find an Answer: Simultaneous VPN Client and Server

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

SpicyLimes

Occasional Visitor
Greetings,

Short and to the Point: Can you simultaneously run a VPN Server and VPN Client on the same network without a metric-ton of configuration?

I am currently using the ASUS Merlin firmware on an ASUS AX58U Router with a network wide OpenVPN Client configuration that is tunneling all network traffic through it. I have also configured the router to use a Raspberry Pi on my network that is running Pi-Hole (DNS server) and Unbound (recursive DNS resolver). So basically my network traffic is encrypted by the VPN Client (via Surfshark) and is also benefiting from an Ad-Blocker (Pi-Hole). I have tried Google'ing this topic, and also searching this forum for an answer to this question but haven't come up with a definitive answer. From what I COULD find, it doesn't seem possible without a lot configuring and compromises on my current setup.

My goal is to be able to access my network from anywhere so I can monitor the devices/computers remotely. I know that Pi-Hole recommends PiVPN to establish a remote connection to use the Ad-Blocking functionality remotely, but to be honest I do not really care about that - I mainly want to be able to access my network remotely in order to troubleshoot issues, monitor my IoT devices via Home Assistant, and access my home PCs (Linux and Windows based). I don't claim to be a networking specialist, in fact, I first started learning about networking after I purchased this router and wanted to setup a network-wide VPN Client and use a Pi as an Ad-Blocker - basically my knowledge of networking is quite limited, so please, ELI5 ("explain it like I'm 5 years old")! :p

The reason I am looking to do this is because my job is now starting to allow my Team to start traveling again and I want to be able to access my network remotely. I have explored numerous "Remote Desktop" software and apps such as ZeroTier, No Machine, Zoho Assist, RemotePC, TeamViewer, and Remote.it, but I wanted to explore this option first. Thoughts?

If this is possible, can anyone chime in with a "How-To"?
 
Last edited:

xtv

Occasional Visitor
Greetings,

Short and to the Point: Can you simultaneously run a VPN Server and VPN Client on the same network without a metric-ton of configuration?

I am currently using the ASUS Merlin firmware on an ASUS AX58U Router with a network wide OpenVPN Client configuration that is tunneling all network traffic through it. I have also configured the router to use a Raspberry Pi on my network that is running Pi-Hole (DNS server) and Unbound (recursive DNS resolver). So basically my network traffic is encrypted by the VPN Client (via Surfshark) and is also benefiting from an Ad-Blocker (Pi-Hole). I have tried Google'ing this topic, and also searching this forum for an answer to this question but haven't come up with a definitive answer. From what I COULD find, it doesn't seem possible without a lot configuring and compromises on my current setup.

My goal is to be able to access my network from anywhere so I can monitor the devices/computers remotely. I know that Pi-Hole recommends PiVPN to establish a remote connection to use the Ad-Blocking functionality remotely, but to be honest I do not really care about that - I mainly want to be able to access my network remotely in order to troubleshoot issues, monitor my IoT devices via Home Assistant, and access my home PCs (Linux and Windows based). I don't claim to be a networking specialist, in fact, I first started learning about networking after I purchased this router and wanted to setup a network-wide VPN Client and use a Pi as an Ad-Blocker - basically my knowledge of networking is quite limited, so please, ELI5 ("explain it like I'm 5 years old")! :p

The reason I am looking to do this is because my job is now starting to allow my Team to start traveling again and I want to be able to access my network remotely. I have explored numerous "Remote Desktop" software and apps such as ZeroTier, No Machine, Zoho Assist, RemotePC, TeamViewer, and Remote.it, but I wanted to explore this option first. Thoughts?

If this is possible, can anyone chime in with a "How-To"?
Hi,
in short: yes.
You can have up to 5 OpenVPN clients and up to 2 OpenVPN servers at the same time.

You just have to setup a VPN server (OpenVPN is more flexible) via the webUI.
The main routing to access your local network should be already there with the standard configuration.

The only thing where could need extra tinkering is that you need to be sure that DNS is propagated to the "ontheroad" clients.

I'd suggest to try first with the standard config, and if that does not work (meaning that you can connect to the VPN but names are not resolved properly by the DNS) you can force it by accessing the "VPN Advanced Detail" in the VPN server configuration and add the following couple of lines to the last section("Custom configuration"):

Code:
push "dhcp-option DNS 192.168.0.100"
push "dhcp-option SEARCH your_local_domain"

The first line sends info to client about what DNS to use.
The second line tells the client that when you type there a hostname (without a domain name) it should autocomplete with your_local_domain. So if you try to access "host" it will be transformed to "host.your_local_domain".

Obviously you have to change the above "192.168.0.100" with the IP address of your DNS (the Pi-Hole in your case) and "your_local_domain" with the local domain that you use in your local network.


One additional note: depending on the configuration of your PiHole server, you might need to change something also there, since not necessarily the PiHole will respond to queries from an IP outside your local network. In this case you should check on the Pi-Hole if the Pi-Hole Configuration restricts the communication or if the port 53 on the firewall has some limitations.
 

SpicyLimes

Occasional Visitor
1111940698_preview_AAEAAQAAAAAAAAjPAAAAJDMzMzNhZGFmLTMyZDAtNDI3MS05MGUyLThlODY1MjNjYmUzZA.jpg


WOW! Thank you! Great information, and awesome tips for troubleshooting! I will give this a try either tonight or tomorrow before I start traveling on Saturday.

One additional note: depending on the configuration of your PiHole server, you might need to change something also there, since not necessarily the PiHole will respond to queries from an IP outside your local network. In this case you should check on the Pi-Hole if the Pi-Hole Configuration restricts the communication or if the port 53 on the firewall has some limitations.
So, this one might get a little tricky because of how I have everything setup - I am basically forcing all devices within my network to use the Pi-Hole DNS Server regardless if they want to or not (which is also reeking havoc on my Netflix streaming devices, but that's another issue all in itself) by assigning the DNS Server 1 under LAN > DHCP to my Pi and leaving the DNS Server 2 blank - then I have Pi-Hole using an upstream DNS of 127.0.0.1#5335 so Unbound can resolve the DNS (see image below) - furthermore, I have my WAN DNS Server 1 set at 1.1.1.1 (used to be 9.9.9.9 but I noticed more issues with streaming services while using that IP, although I am not sure why). Do you believe this will be an issue?

Screenshot 2021-04-08 1.02.21 PM.png


Also, Pi-Hole has an option within the web GUI (under Settings > DNS - see image below) that provides 3 options (I have the top option selected currently, as you can see from the image below); the last one might be pertinent to your above statement - it states:
Listen on all interfaces, permit all origins
Note that the last option should not be used on devices which are directly connected to the Internet. This option is safe if your Pi-hole is located within your local network, i.e. protected behind your router, and you have not forwarded port 53 to this device. In virtually all other cases you have to make sure that your Pi-hole is properly firewalled.
Would this be what you were mentioning above?

Screenshot 2021-04-08 12.59.07 PM.png
 

eibgrad

Very Senior Member
Short and to the Point: Can you simultaneously run a VPN Server and VPN Client on the same network without a metric-ton of configuration?

On the same "network" (i.e., they could each be hosted on different devices), or on the same "router" (presumably your primary router)? Because it makes a difference in how that question gets answered.
 

SpicyLimes

Occasional Visitor
On the same "network" (i.e., they could each be hosted on different devices), or on the same "router" (presumably your primary router)? Because it makes a difference in how that question gets answered.
Since I am posting on the ASUS Merlin forum, as well as on the contextual basis of my first post, I am referring to having a simultaneous VPN Client and VPN Server on the "router". ;)
 

eibgrad

Very Senior Member
Since I am posting on the ASUS Merlin forum, as well as on the contextual basis of my first post, I am referring to having a simultaneous VPN Client and VPN Server on the "router". ;)

It's not always obvious, esp. from this side of the forum. There's a tendency for some to use terms imprecisely and/or interchangeably, and you can end up wasting a lot of time solving non-existent problems as a result.

Anyway…

Yeah, you can do it, but there are a few tricky issues to consider beyond those already mentioned.

Whenever using both the OpenVPN client and server simultaneously, the OpenVPN server will become unreachable. All the replies to the OpenVPN server over the WAN will be routed back out the VPN, and the stateful firewall (specifically, reverse path filtering) won't permit it. So you have to find a means to deal w/ that issue.

One way is to use Routing Policy w/ the OpenVPN client, which removes the router itself from the VPN (making it reachable again via the OpenVPN server), then decide what gets routed over the OpenVPN client using rules, even it that means the entire local network (e.g., 192.168.1.0/24).

But that raises another issue. The OpenVPN server is NOT guaranteed to get established before any OpenVPN clients (a complaint I'm made w/ the developer). And if the OpenVPN server gets started *after* the OpenVPN client, those devices bound to Routing Policy's alternate routing table will NOT contain any references to the OpenVPN server's network interface. And that will make those devices unreachable by clients of the OpenVPN server!

It's an issue encountered by other users, and as I said, one I've complained about to the developer.


FWIW, I've created a workaround.


Yeah, it's all way too complicated, unfortunately. But it's these small details that can come back to bite you and create lots of confusion.

A better solution than Routing Policy is if you *know* the source IP(s) from which you will be accessing the OpenVPN server, you can add those as static routes to the OpenVPN client custom config field (in the form of route directives) to bind them explicitly to the WAN.

Code:
route 199.199.199.199 255.255.255.0 net_gateway

Of course, that may not be practical in all cases, particularly when roaming. But when accessing from your workplace, a commonly visited wifi cafe, etc., it may be workable.

In short, you can have a simultaneous OpenVPN client and server, but it's not quite as simple as turning them ON and it all works to perfection. You have to consider these other issues too.
 

SpicyLimes

Occasional Visitor
It's not always obvious, esp. from this side of the forum. There's a tendency for some to use terms imprecisely and/or interchangeably, and you can end up wasting a lot of time solving non-existent problems as a result.

Anyway…
110% understand that, and I appreciate you pointing that out - I'm glad that you took my comment more as a friendly "poke" than as a passive-aggressive comment!

Yeah, you can do it, but there are a few tricky issues to consider beyond those already mentioned.

Whenever using both the OpenVPN client and server simultaneously, the OpenVPN server will become unreachable. All the replies to the OpenVPN server over the WAN will be routed back out the VPN, and the stateful firewall (specifically, reverse path filtering) won't permit it. So you have to find a means to deal w/ that issue.

One way is to use Routing Policy w/ the OpenVPN client, which removes the router itself from the VPN (making it reachable again via the OpenVPN server), then decide what gets routed over the OpenVPN client using rules, even it that means the entire local network (e.g., 192.168.1.0/24).

But that raises another issue. The OpenVPN server is NOT guaranteed to get established before any OpenVPN clients (a complaint I'm made w/ the developer). And if the OpenVPN server gets started *after* the OpenVPN client, those devices bound to Routing Policy's alternate routing table will NOT contain any references to the OpenVPN server's network interface. And that will make those devices unreachable by clients of the OpenVPN server!

It's an issue encountered by other users, and as I said, one I've complained about to the developer.


FWIW, I've created a workaround.


Yeah, it's all way too complicated, unfortunately. But it's these small details that can come back to bite you and create lots of confusion.

A better solution than Routing Policy is if you *know* the source IP(s) from which you will be accessing the OpenVPN server, you can add those as static routes to the OpenVPN client custom config field (in the form of route directives) to bind them explicitly to the WAN.

Code:
route 199.199.199.199 255.255.255.0 net_gateway

Of course, that may not be practical in all cases, particularly when roaming. But when accessing from your workplace, a commonly visited wifi cafe, etc., it may be workable.

In short, you can have a simultaneous OpenVPN client and server, but it's not quite as simple as turning them ON and it all works to perfection. You have to consider these other issues too.

So... uh... yea... o_O I understand the concept of what you are describing and why attempting this is basically futile (sans Borg Queen reference). With all that information provided (thank you again), it seems that sticking with RemotePC or TeamViewer is going to be the only option available to me. At least until I come back from my travels in about a month.

Anyone have a preference as to their favorite Remote Desktop software? TeamViewer... RemotePC... AstroRelay... Others?
 

eibgrad

Very Senior Member
I understand the concept of what you are describing and why attempting this is basically futile (sans Borg Queen reference). With all that information provided (thank you again), it seems that sticking with RemotePC or TeamViewer is going to be the only option available to me. At least until I come back from my travels in about a month.

I wouldn't say it's futile. You just have to understand how it works so you can address these known issues and avoid problems.

And btw, resorting to remote desktop applications won't necessarily solve all your problems. If the targets of your remote desktop application are accessed over the WAN, and are also bound to the router's OpenVPN client, their replies will be routed over the VPN and become unreachable too!

Ironically, using the OpenVPN server is actually preferable, despite the issues I mentioned previously. Because once you overcome those issues, those targeted devices are reachable, *even* if they are bound to the router's OpenVPN client! That's the one big advantage in terms of remote access via the OpenVPN server compared to the WAN.
 
Last edited:

SpicyLimes

Occasional Visitor
I wouldn't say it's futile. You just have to understand how it works so you can address these known issues and avoid problems.

And btw, resorting to remote desktop applications won't necessarily solve all your problems. If the targets of your remote desktop application are accessed over the WAN, and are also bound to the router's OpenVPN client, their replies will be routed over the VPN and become unreachable too!

Ironically, using the OpenVPN server is actually preferable, despite the issues I mentioned previously. Because once you overcome those issues, those targeted devices are reachable, *even* if they are bound to the router's OpenVPN client! That's the one big advantage in terms of remote access via the OpenVPN server compared to the WAN.
Oh I know it won't be a problem for me to set something like this up, what I meant was that it's futile for me to attempt it right now.

BUT BUT BUT...

So, since setting up this new router along with the VPN and Ad-Blocker, I haven't tried connecting to my main computer using RemotePC (I have an account with them that I setup last year for a year's subscription for $4). After reading your post, I disabled Wi-Fi on my iPhone and attempted to log in to that computer via RemotePC over LTE... and I was successful. Seems like I can access the computer remotely even with the OpenVPN Client being enabled...
 

eibgrad

Very Senior Member
Oh I know it won't be a problem for me to set something like this up, what I meant was that it's futile for me to attempt it right now.

BUT BUT BUT...

So, since setting up this new router along with the VPN and Ad-Blocker, I haven't tried connecting to my main computer using RemotePC (I have an account with them that I setup last year for a year's subscription for $4). After reading your post, I disabled Wi-Fi on my iPhone and attempted to log in to that computer via RemotePC over LTE... and I was successful. Seems like I can access the computer remotely even with the OpenVPN Client being enabled...

That's why I emphasized "accessed over the WAN".

Some of these remote desktop apps are actually cloud services. When the target starts the app, it creates an outbound connection to the remote desktop service in the cloud, from which any remote client can be routed back in over that same connection (that's why you don't need to explicitly setup port forwarding!). So if the client is bound to the WAN or VPN, it doesn't matter.

Contrast that to something like RDP or VNC, which do NOT provide a cloud service. In that case, you necessarily have to route over the WAN or VPN (assuming your VPN provider supports it) according to how the target is bound to either of those network interfaces (and implement port forwarding) in order to reach it.

So yeah, given a remote desktop solution based on a cloud service, I can see it working. But then you get into the whole issue of the risk of managing something like this remotely vs. strictly locally.
 
Last edited:

SpicyLimes

Occasional Visitor
That's why I emphasized "accessed over the WAN".

Some of these remote desktop apps are actually cloud services. When the target starts the app, it creates an outbound connection to the remote desktop service in the cloud, from which any remote client can be routed back in over that same connection (that's why you don't need to explicitly setup port forwarding!). So if the client is bound to the WAN or VPN, it doesn't matter.

Contrast that to something like RDP or VNC, which do NOT provide a cloud service. In that case, you necessarily have to route over the WAN or VPN (assuming your VPN provider supports it) according to how the target is bound to either of those network interfaces (and implement port forwarding) in order to reach it.

So yeah, given a remote desktop solution based on a cloud service, I can see it working. But then you get into the whole issue of the risk of managing something like this remotely vs. strictly locally.
Doh, I should have thought of that. That is something that I am very well versed on, but for some reason didn't even think of that when I attempted it. My mind must have been so geared on a remote connection (sans cloud). Anyway, I greatly appreciate the help and the explanation of how these different items work. I'll raise a glass to you and those who chimed in today... cheers!
 

xtv

Occasional Visitor
Actually it's pretty easy to setup, and it does work.

I just made a quick test and all was working with a quite standard config.

The test setup is:
  • ax88u as main router in the local network
  • client OpenVPN on ax88u connecting to an external network (e.g. office)
  • server OpenVPN on ax88u receiving connections from "ontheroad" clients in internet (all ports are closed, access is only granted to OpenVPN server ports)

Tested with an iPad with OpenVPN client that can connect to internet, local network and external network. All using the internal network DNS that resolves localhosts applies filters, etc...

For this to work you just have to go for a straight setup following on the router following the standard HowTo (without need for any cloud service).

In the OpenVPN client configuration you can force all internet traffic to go out through the vpn, also there is a small extra available via "amtm"called x3mRouting (see documentation) which allows to define selective routing by client.

Note: use the setup with certificates, as shared secret can be broken easily by brute force.

Important: I would recommend to avoid exposing ANY service directly on internet (RDP, VNC, etc... they would require constant patching and maintenance to keep them reasonably safe, also they are not famous to be ultra secure solutions when published on internet). Again do not expose anything that is not strictly necessary on WAN or...
you might be assimilated by some people that will add your biological and technological distinctiveness to their own ;)

It gets sightly more complicated if your OpenVPN client (or server) is not on the router but inside the local network (e.g. on a dedicated RPi) or of your network topology is quite unusual, anyway, 99% you should be able to solve even that with just a couple of custom routes set on the router and pushed to the "ontheroad" clients.
 

Latest threads

Sign Up For SNBForums Daily Digest

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