What's new

[SOLVED] OpenVPN server and Client not allowed at same time?

  • 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!

Sas

Regular Contributor
I have both OpenVPN server and OpenVPN client configs in my router, and I use them for different purposes. I have noticed that if I am connected by client to a remote vpn server, if I connect from outside my lan to my openVPN server on my router that I am unable to get to any internal machine. IF I disconnect the client vpn, I will then be able to get to lan devices over the server connection. Is there a way to allow both to be running and working at the same time? Like I said, I CAN connect to my router's OpenVPN server while the router's OpenVPN client is connected elsewhere, but I can't do anything with that connection because I can't get to anything on the lan while it is. Hope this makes sense.

BTW I am running an AC86U with 384.19
 
This is an old, well-known, well-understood issue, and there are several other threads concerning it.

The basic problem is that when you connect the OpenVPN client to a typical commercial OpenVPN provider, that changes the default gateway to the VPN. And that affects *everything* that relies on the default gateway setting for routing purposes, *including* remote access over the WAN. IOW, your inbound connection over the WAN is having its replies routed back over the VPN, which is NOT allowed by the stateful firewall (specifically, reverse path filtering).

One way to avoid the problem is to use PBR (policy based routing) and NOT let anything that needs remote access over the WAN (router or beyond to the LAN) use the VPN. Another is to port forward over the VPN instead, provided your VPN provider supports it. Or if you *know* the public IPs from which you will be doing remote access over the WAN, add them as static routes that point to the WAN/ISP as their gateway. There are other options as well, but those are the most common.
 
Last edited:
  • Like
Reactions: Sas
One way to avoid the problem is to use PBR (policy based routing) and NOT let anything that needs remote access over the WAN (router or beyond to the LAN) use the VPN. Another is to port forward over the VPN instead, provided your VPN provider supports it.

Thanks for your reply. Not sure if I am completely understanding you about PBR, but I believe I have already done that on the client, as only one device on my lan routes through it:

Screen Shot 2020-10-04 at 8.17.41 AM.png


And this works when the client is active, ONLY this device/IP uses the client. Nevertheless, when this is active and I try to connect to the router's OpenVPN Server as well from outside my lan, it can connect fine, but it has no access to ANY internal device on the lan, nor the router's web interface itself. Is there something else I am missing here?
 
Given your latest information, it should work. Only thing that immediately comes to mind as a potential (if highly unlikely) problem is if by chance the tunnel IP network you're using on your own OpenVPN server is in conflict w/ the OpenVPN client's tunnel on the router. As in all routing situations, the IP networks across all your network interfaces have to be unique and non-overlapping. And while it is rare, there's always a small risk this isn't case and you end up creating a routing conflict. At least I would check and make sure.
 
  • Like
Reactions: Sas
Given your latest information, it should work. Only thing that immediately comes to mind as a potential (if highly unlikely) problem is if by chance the tunnel IP network you're using on your own OpenVPN server is in conflict w/ the OpenVPN client's tunnel on the router. As in all routing situations, the IP networks across all your network interfaces have to be unique and non-overlapping. And while it is rare, there's always a small risk this isn't case and you end up creating a routing conflict. At least I would check and make sure.
Thank you! The remote vpn that I am connecting to is another ASUS router running the same merlin version (384.19) and OpenVPN...while I had made sure that their local lan subnets did not overlap (192.168.10.0 and 192.168.5.0), I neglected to consider the fact that the subnet being supplied to VPN clients (in this case default 10.8.0.0) DID overlap. So I changed my local vpn server to use 172.16.0.0 and voila!

Thanks again!
 
Another is to port forward over the VPN instead, provided your VPN provider supports it. There are other options as well, but those are the most common.

Hi @eibgrad
Could you pls further explain how to concretly implement those solutions (remembering I am a novice user), I have more or less the same issue except my open vpn client/server networks do not overlap.
(issue is that I cannot access devices that are protected by vpn client when remotely connecting a device thru the OpenVPN Server)
VPN Server => 10.8.0.0
VPN Client => 10.33.0.x

All clients are W10 machines.

thx,
GS
 
Last edited:
Hi @eibgrad
Could you pls further explain how to concretly implement those solutions (remembering I am a novice user), I have more or less the same issue except my open vpn client/server networks do not overlap.
(issue is that I cannot access devices that are protected by vpn client when remotely connecting a device thru the OpenVPN Server)
VPN Server => 10.8.0.0
VPN Client => 10.33.0.x

All clients are W10 machines.

thx,
GS

Most likely you've encountered the following bug (well, I think it's a bug, not so much Merlin).

 
Most likely you've encountered the following bug (well, I think it's a bug, not so much Merlin).


Thanks, I think I understood this one:

now, the question is "how do I add manually the OpenVPN Server to the routing table of ovpnc1 and ovpnc2", because of course the OpenVpn Clients are always connected (and started at boot time) while the OpenVPN Server is started on demand ... !
GS
 
Thanks, I think I understood this one:

now, the question is "how do I add manually the OpenVPN Server to the routing table of ovpnc1 and ovpnc2", because of course the OpenVpn Clients are always connected (and started at boot time) while the OpenVPN Server is started on demand ... !
GS

Restarting the OpenVPN clients after restarting the OpenVPN server? (provided you give the server a few seconds to get established)
 
... isn't there a more "automatic clever" way of achieving this ? .... (adding route or something like that, somewhere ...)
 
You mean, hack it?! LOL

Code:
ip route | grep tun21 | while read route; do ip route add $route table ovpnc1; done
 
... isn't there a more "automatic clever" way of achieving this ? .... (adding route or something like that, somewhere ...)

FYI. I decided to fix the problem permanently by creating an OpenVPN event script to automatically synchronize any active OpenVPN server networks w/ any active OpenVPN client routing policy tables.


You need to have JFFS and JFFS scripts enabled under Administration->Script, ssh into the router, then use the following command to install the script.

Code:
curl -kLs bit.ly/merlin-installer|tr -d '\r'|sh -s kTThBV46

Finally, reboot. Just beware, it will NOT overwrite any existing openvpn-event script. If that happens, you'll need to resolve the conflict manually.

UPDATE: Made a slight fix (v1.1.0). I wasn't qualifying the event to only server events (tun2#), now I am.
 
Last edited:
Hi, eibgrad

Thanks very much for the solution you posted. Short version: I installed your script and it worked. Wahoo!

I purchased a RT-AX86U and found it could easily handle the overhead of a VPN client connection, so now all my stay-at-home devices (NAS, smart devices, Fire TV, etc.) go through the VPN client on the router. Following on, I thought I might as well up my game and get the VPN server set up so as to access my home network when away from home rather than fiddling with DDNS or using my QNAP's QNAPCloud features. From everything I've read over the years, VPN server access seems to be the safest option for dialling in remotely to your home network. .

Fortunately, before proceeding, I had the thought that there might be interference of some sort between VPN server and client. Unfortunately, on searching this forum, this proved to be correct and it made clear to me how very limited my understanding of networking is.

On the plus side, I did discover amtm and that we can load scripts and add-ons, but I was left thinking it would take months of study to understand the principles necessary to achieve what I wanted. For instance, x3mrouting - seems to have great possibilities but I haven't the faintest notion of how it works.

Thankfully, I found your post and, along with other very helpful posts showing how to enable scripts, amtm, etc,. I was able to achieve my modest aim. I don't know how your solution works and have a great deal to learn in general but it is a great relief to have this basic setup just work.
 
Please can you explain this simpler?

So, if I have an OpenVPN server running (say to use a VPN when away on untrusted WIFI) does that mean that if I have an OpenVPN client (say NotsoFast VPN) then one or other will not work but the above script will fix it?

Thanks
 
Please can you explain this simpler?

So, if I have an OpenVPN server running (say to use a VPN when away on untrusted WIFI) does that mean that if I have an OpenVPN client (say NotsoFast VPN) then one or other will not work but the above script will fix it?

Thanks


Basically, Merlin does NOT guarantee the order in which the OpenVPN servers or clients get established. And that can lead to problems when it's *required* for the OpenVPN server to be established before any of the OpenVPN clients.

And when might that be?

Anytime the OpenVPN client uses Routing Policy, it creates a secondary routing table solely for the purposes of those clients bound to the VPN. And the router does this by copying the contents of the main table over to a secondary routing table. But if the OpenVPN server is NOT established at the time that process takes place, the secondary routing table will NOT contain the OpenVPN server's network interface since it doesn't exist yet! And now any subsequent attempt by a *remote* OpenVPN client to access any clients bound to one of the *local* OpenVPN clients (e.g., NordVPN) will fail because those clients lack the necessary routing back to the *remote* OpenVPN client.

It's just a timing problem.

The purpose of the script is to make sure the OpenVPN server(s) and OpenVPN client(s) are kept synchronized so you never have a situation where the OpenVPN server is active but its network interface is missing from a previously established OpenVPN client.
 
FYI. I decided to fix the problem permanently by creating an OpenVPN event script to automatically synchronize any active OpenVPN server networks w/ any active OpenVPN client routing policy tables.
Hope you don't mind....I borrowed from your script to add to my fork...
acf387e3c4 (HEAD -> 374.43_2-update) others: openvpn: improve script processing; add fix for server sequencing (eibgrad)
 
FYI. I decided to fix the problem permanently by creating an OpenVPN event script to automatically synchronize any active OpenVPN server networks w/ any active OpenVPN client routing policy tables.


You need to have JFFS and JFFS scripts enabled under Administration->Script, then copy/paste the script into a shell (ssh) window, and it will automatically create and install the OpenVPN event script. Finally, reboot. Just beware, it will NOT overwrite any existing openvpn-event script. If that happens, you'll need to resolve the conflict manually.

UPDATE: Made a slight fix (v1.1.0). I wasn't qualifying the event to only server events (tun2#), now I am.
hi @eibgrad

I'm currently using your fix. Will I encounter issues with the upcoming 386.3 and its VPN director?

Thanks :)
 
hi @eibgrad

I'm currently using your fix. Will I encounter issues with the upcoming 386.3 and its VPN director?

Thanks :)

I have no more way of knowing than you. On the face of it, I don't see why it wouldn't work given the way the fix works. But as you know, any major underlying change has the potential to negatively affect third party scripts. Even the most popular ones supported in the AddOn forum. Frankly, I wish Merlin would adopt the changes into his firmware, much the way @john9527 did. FWIW, I've tested other third party firmware as well, like DD-WRT and FreshTomato, and none of them exhibit this problem. AFAIK, it's only an issue w/ Merlin.
 
Thanks for your answer. Erf, I understand your point on the fact that Eric don't consider this an issue.

And for my question, well, we will see with the release.
 

Sign Up For SNBForums Daily Digest

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