What's new

Simultaneous VPN Server and VPN Client

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

DC_David

New Around Here
I am a complete novice in home networking. I am trying to learn but clearly need some help. I have managed the following: (1) installed Merlin on my ASUS RT-AC3200 router, (2) connected my router VPN client to my NordVPN service and confirmed that it's working (3) confirmed all my LAN devices are working (i.e. Netflix, Hulu, Amazon etc.) when connected to NordVPN, (4) installed a NAS server and confirmed that i can access it.

However, when I am away from my LAN, I would like to connect to my home network by using OpenVPN through my VPN server on the ASUS router WHILE NORDVPN IS RUNNING. I can't make that work. To date I have set up the DDNS server on my router and confirmed that, if I terminate the NordVPN connection, I can connect to my LAN from a non-LAN internet connection.

I don't want anything fancy. My goal is as follows: (1) be able to access my home LAN so I can use the date on my NAS drive (pictures) when I am away from home (2) keep my NordVPN connection active from my router at all times so that my ISP can not track my activity.

My apologies if this has been covered here. I looked but could not find anything.
 
I am a complete novice in home networking. I am trying to learn but clearly need some help. I have managed the following: (1) installed Merlin on my ASUS RT-AC3200 router, (2) connected my router VPN client to my NordVPN service and confirmed that it's working (3) confirmed all my LAN devices are working (i.e. Netflix, Hulu, Amazon etc.) when connected to NordVPN, (4) installed a NAS server and confirmed that i can access it.

However, when I am away from my LAN, I would like to connect to my home network by using OpenVPN through my VPN server on the ASUS router WHILE NORDVPN IS RUNNING. I can't make that work. To date I have set up the DDNS server on my router and confirmed that, if I terminate the NordVPN connection, I can connect to my LAN from a non-LAN internet connection.

I don't want anything fancy. My goal is as follows: (1) be able to access my home LAN so I can use the date on my NAS drive (pictures) when I am away from home (2) keep my NordVPN connection active from my router at all times so that my ISP can not track my activity.

My apologies if this has been covered here. I looked but could not find anything.
Since you are also using OpenVPN server on your router, make sure you select a NordVPN protocol that does not overlap with the OpenVPN Server subnet or vise versa. Server Port may be another area of conflict, using the same port for both the server and client for example. You can see the fields I mention in the screen print on this post. https://www.snbforums.com/threads/how-to-setup-a-vpn-server-with-asus-routers.33638/

You may also need to check settings Push LAN to Clients and Direct Clients to redirect internet traffic on the OpenVPN Server for your use case.

Push LAN to clients: allows you to access your network via the tunnel,
such as remote desktop, file sharing and print sharing.

Direct clients to redirect internet traffic: If this feature is enabled all traffic will go via the router.
 
I was facing a similar problem where I’ve had an OpenVPN server already active, then tried to activate an OpenVPN client, which would kill the internet entirely. Xentrk already mentioned this but I wanted to reaffirm the problem I was facing: ensure the VPN server and client are on separate subnets. Mine were both on 10.8.0.x. Changing one of the subnets resolved the problem for me. I think a good firmware improvement would be to automatically use different subnets for VPN clients and servers.
 
Note, the reason I'm posting here and now, despite this being an older thread, is that I've noticed this thread being referenced many times when it comes to this problem, so it appears to be the best opportunity to explain what I see as the problem.

Yes, a conflict w/ the IP networks used by the tunnels on the OpenVPN client and server can sometimes be the problem. However, that's usually the exception. There is a much more common and likely reason for this situation.

When the OpenVPN client is active, and you're connecting to a commercial OpenVPN provider (e.g., PureVPN), that provider's OpenVPN server pushes a "redirect-gateway" directive to the OpenVPN client, which instructs it to change the router's default gateway to the VPN's default gateway. Now anything the router does, OR, the local network does wrt the internet occurs over the VPN.

And now here's the rub. When you attempt to remotely connect to your OpenVPN server over the WAN while that OpenVPN client is active, the replies for the OpenVPN server will necessarily be sent over the VPN! Remember, the router itself is bound the VPN too, not just the local network behind it. And according to the firewall rules (and more specifically, reverse-path filtering), it is INVALID to use different network interfaces for the incoming and outgoing packets on any given connection. THAT is far more likely the reason why you can't get remotely connected to your OpenVPN server.

IOW...

WAN in, WAN out, good
WAN in, VPN out, bad
VPN in, VPN out, good
VPN in, WAN out, bad

This doesn't affect just the OpenVPN server. *ANY* services accessed over the WAN while the VPN is active, whether it be the router (GUI, SSH, etc.) or the devices on the local network via port forwarding, will have the same problem.

There are several ways to resolve it.

1. Access the service over the VPN. That keeps the configuration VPN in, VPN out. Of course, that assumes your VPN provider offers port forwarding (in my experience, some do, most don't).

2. Use static routes to bind your remote public IP to the WAN. Of course, this isn't very practical for most ppl, esp. if they are roaming. But in some cases it is, such as accessing your OpenVPN server from well-known places (your workplace, the wifi cafe you frequent, etc.).

3. Use PBR (policy based routing). Most PBR works by rejecting the OpenVPN server's attempt to change the router's default gateway. It then creates an alternate routing table that points to the VPN's gateway, and only sends specific local devices over the VPN. This technique keeps the router itself OFF the VPN, and so now your remote access to the WAN and all its services works again.

4. Use Merlin's alternate PBR script to mark packets for specific services headed outbound from the router (i.e., local processes) so they use the ISP/WAN rather than the VPN.

https://github.com/RMerl/asuswrt-merlin/wiki/Policy-based-routing-(manual-method)

As written, it only works w/ devices behind the WAN. But w/ a small modification, it can be made to work w/ the router itself. If interested, let me know and I'll show you how.
 
Last edited:
https://github.com/RMerl/asuswrt-merlin/wiki/Policy-based-routing-(manual-method)

As written, it only works w/ devices behind the WAN. But w/ a small modification, it can be made to work w/ the router itself. If interested, let me know and I'll show you how.

Even two years ago, I stated that the quoted script is flawed for several reasons (conflicting use of an ASUS reserved fwmark is one)

All of the quoted script features are now included in the firmware in a more robust manner, however, to selectively route Ports via the WAN from a LAN device that normally has ALL of its' traffic via a VPN, requires an additional couple of manual rules.
 
Is there an updated guide to access my VPN (NordVPN) when I am away from my LAN?

I already changed the subnet (to 10.7.0.0) and the UDP Port (to 1195) of the VPN server but I still can't acces my VPN client through the VPN server.
 
P.S. Here's another possible solution that I forgot I had developed quite some time ago. Consider it option #5.

https://pastebin.com/gnxtZuqg

What this script does is use DDNS to solve the problem.

Normally you use DDNS to track the public IP of your router for remote access purposes. But what the above script does is use DDNS so the router can track where *you* are (in terms of your current public IP) as you roam.

You install the script, making sure to configure it w/ a DDNS domain name of your own choosing (e.g., from DuckDNS). The script continually monitors that DDNS domain name for changes. And when it finds a change, it adds a static route that binds that public IP to the WAN! So now you regain access to your router's services and port forwards, even if the router itself is using the VPN as its default gateway.

Now granted, this solution isn't for everybody. It does require that you update the DDNS domain name as you roam, either manually (which really isn't all that difficult, DuckDNS has a webpage for those purpose, and defaults to your current public IP, so it's just a matter of hitting the Apply/Save button), or automatically using a PC/laptop/smartphone DDNS client. Also, the script (as written) only checks for changes every 5 mins (I didn't want to abuse the DDNS system). So on average, the adding of the static route on your router is going to take 2 1/2 mins to take effect. But you could obviously reduce that 5 mins to something less. I also wrote the script to support *multiple* DDNS domain names, so multiple clients could take advantage of this technique. It was written for dd-wrt specifically, but I don't think it actually has any dd-wrt specific dependencies. If it does, I'm sure it would require only minor adjustments to run on just about any other third-party firmware. It's not really all that complex.

As I said, I forgot I had even written it. So I haven't been promoting it. I wrote it to help a specific individual on the dd-wrt forums. FWIW, he was quite happy w/ the results. Never heard a complaint back from him either. It's just one more option among many to get around this sticky problem.
 
Last edited:
I have a working VPN Client running, routing all my internal devices via NordVPN.
Great...

Now I start a VPN Server with TUN protocol and can connect from outside to my Home network. This also works great and I can use my 192.168.X.X addresses the same way as if I were at home.
Great...


Now I want to connect from outside to my VPN Server AND use my internet from Homenetwork via NordVPN.

Is there a way to get this working?

:) Thank u

Like this pic (from here) but without SSH or scripting :( ?!?!



markering_596.jpg
 
Last edited:
Even two years ago, I stated that the quoted script is flawed for several reasons (conflicting use of an ASUS reserved fwmark is one)

All of the quoted script features are now included in the firmware in a more robust manner, however, to selectively route Ports via the WAN from a LAN device that normally has ALL of its' traffic via a VPN, requires an additional couple of manual rules.

I would first like to thank eibgrad and Martineau for their helpful reflections, as they helped me a lot!

Unfortunately I am still looking for the "how" on the "additional couple of manual rules". Can you help me out with some coding examples Martineau?

My setup:
ISP modem/router > ASUS RT-AC86U with Merlin installed ("VPN router" > Synology server

On my VPN router I have a client running for a VPN service (outgoing) and a server running to access my network from when I am outside of my LAN network (incoming).

The outgoing works great, no problem.
The incoming is a different story. I can connect to the VPN router because I put it on WAN through Policy Rules. I cannot connect to the Synology server as I do not want to put it on WAN.
A solution might be (I am a noob, so please correct me if it is nonsense):
- Run OpenVPN server on Synology instead of VPN router (Stop VPN server on VPN router).
- Forward server port through ISP modem/router (was already done for VPN router) and (additionally) through VPN router.
- Put ONLY the OpenVPN server (running on Synology) on the WAN.

The last step is where I need to use Policy Rules for which I can specify ports.
Is this a script I need to enter in the "firewall-start" on the VPN router?
And which script specifically?


For your additional information:
I tried to enter the 'push "route x.x.x.x x.x.x.x"' in the Custom Configuration of the VPN router.
I also made the "firewall-start" through SSH in the /JFFS/scripts/ folder and entered the following code:
'iptables -t nat -A POSTROUTING -s x.x.x.x/24 -d x.x.x.x/24 -j MASQUERADE'
It didn't work, so I think it is the Synology being on the VPN client which is the culprit. If the VPN client is stopped, I can connect to the Synology via the VPN server.
 
@Soulsearcher

The incoming is a different story. I can connect to the VPN router because I put it on WAN through Policy Rules. I cannot connect to the Synology server as I do not want to put it on WAN.

Let me ask you a more fundamental question. If you don't want the NAS on the WAN, then why access it from the WAN?

Seems to me you're being contradictory. If you want it on the VPN, then access it from the VPN. I don't even know the point of having it use the VPN for initiating connections outbound anyway. When is this behavior being invoked? Is it running a bittorrent client? If so, then it seems to me you need port-based split tunneling that routes that specific traffic over the VPN, while leaving everything else to the WAN (esp. since you seem content to initiate inbound connections to the NAS over the WAN).

https://github.com/RMerl/asuswrt-merlin/wiki/Policy-based-routing-(manual-method)

Yes, as written, it is flawed, but still, this is the kind of split tunneling you need, where the port is considered.

But as I said, the simpler solution is to access the NAS over the VPN for all actions (plus it protects all NAS traffic). Of course, this requires a VPN provider that supports port forwarding (something most ppl don't consider when choosing a VPN provider until they run into this problem). Or, as I also suggested, perhaps running my script (which I've recently updated/improved).

P.S. My script, (originally written for dd-wrt) will probably need a few minor modifications to run w/ Merlin, esp. since Merlin uses his own event model. But I didn't want to bother (at least not right now) if no one was interested.
 
Last edited:
@Soulsearcher

The incoming is a different story. I can connect to the VPN router because I put it on WAN through Policy Rules. I cannot connect to the Synology server as I do not want to put it on WAN.

Let me ask you a more fundamental question. If you don't want the NAS on the WAN, then why access it from the WAN?

Seems to me you're being contradictory. If you want it on the VPN, then access it from the VPN. I don't even know the point of having it use the VPN for initiating connections outbound anyway. When is this behavior being invoked? Is it running a bittorrent client? If so, then it seems to me you need port-based split tunneling that routes that specific traffic over the VPN, while leaving everything else to the WAN (esp. since you seem content to initiate inbound connections to the NAS over the WAN).

https://github.com/RMerl/asuswrt-merlin/wiki/Policy-based-routing-(manual-method)

Yes, as written, it is flawed, but still, this is the kind of split tunneling you need, where the port is considered.

But as I said, the simpler solution is to access the NAS over the VPN for all actions (plus it protects all NAS traffic). Of course, this requires a VPN provider that supports port forwarding (something most ppl don't consider when choosing a VPN provider until they run into this problem). Or, as I also suggested, perhaps running my script (which I've recently updated/improved).

P.S. My script, (originally written for dd-wrt) will probably need a few minor modifications to run w/ Merlin, esp. since Merlin uses his own event model. But I didn't want to bother (at least not right now) if no one was interested.


You are absolutely right.
I am being contradictory.
This contradiction is caused by my inexperience in this matter, my apologies. I am learning bit by bit what network management means, triggered by increased awareness about privacy on the internet and the role of the ISP and other parties. So even though I run also a bittorrent client, I still wish to have my VPN running on my whole LAN if this is possible.

I do not have the skills (yet) to implement/adapt the "Policy based routing (manual method)".

I do have a VPN provider that supports port forwarding - PIA - but I am still trying to grasp the basics of this.

My further questions to continue this route (and please correct me if I am wrong so I can learn from it):
- This would mean that I could forward the VPN port 1194 of my VPN server (which is already forwarded through my ISP modem/router) through the VPN provider's "firewall"?
- How do you make that work? I know there is an option in their client software to ask for port forwarding, but shouldn't this be asked from the client running on the VPN router? I found something which might lead to a solution here:
https://www.privateinternetaccess.com/forum/discussion/23431/new-pia-port-forwarding-api
but where should I use this on the ASUS Merlin? Custom Configuration in the VPN client or somewhere through SSH?
And then there is the challenge to "connect" the port they have given me to the 1194 port opened through my firewall...
- Also, the port they give you might change. How to manage that? I guess the connection needs to be ON all the time in order not to break the port forwarding.
- And if I manage to get this gate to my VPN server (which will be running on the VPN router or the Synology, still to decide) open, does this mean that I would be making a "tunnel in a tunnel"? In other words: VPN outgoing through VPN provider (encrypted) and then inside this tunnel my incoming encrypted tunnel from my pc to the OpenVPN Server in my LAN?
- What remains is the DynDNS to find my way back to my LAN. As the VPN router will be on the VPN now (in this new scenario), but still behind my ISP modem (on which I installed my DynDNS currently), I guess I should install my DynDNS service on the VPN router. However, ASUS Merlin states that this might not work. Correct?

I am ready to try and tinker as I did already many many many hours before.
And I will give feedback on my lessons learned to possibly help others.
 
You are absolutely right.
I am being contradictory.
This contradiction is caused by my inexperience in this matter, my apologies. I am learning bit by bit what network management means, triggered by increased awareness about privacy on the internet and the role of the ISP and other parties. So even though I run also a bittorrent client, I still wish to have my VPN running on my whole LAN if this is possible.

I do not have the skills (yet) to implement/adapt the "Policy based routing (manual method)".

I do have a VPN provider that supports port forwarding - PIA - but I am still trying to grasp the basics of this.

My further questions to continue this route (and please correct me if I am wrong so I can learn from it):
- This would mean that I could forward the VPN port 1194 of my VPN server (which is already forwarded through my ISP modem/router) through the VPN provider's "firewall"?
- How do you make that work? I know there is an option in their client software to ask for port forwarding, but shouldn't this be asked from the client running on the VPN router? I found something which might lead to a solution here:
https://www.privateinternetaccess.com/forum/discussion/23431/new-pia-port-forwarding-api
but where should I use this on the ASUS Merlin? Custom Configuration in the VPN client or somewhere through SSH?
And then there is the challenge to "connect" the port they have given me to the 1194 port opened through my firewall...
- Also, the port they give you might change. How to manage that? I guess the connection needs to be ON all the time in order not to break the port forwarding.
- And if I manage to get this gate to my VPN server (which will be running on the VPN router or the Synology, still to decide) open, does this mean that I would be making a "tunnel in a tunnel"? In other words: VPN outgoing through VPN provider (encrypted) and then inside this tunnel my incoming encrypted tunnel from my pc to the OpenVPN Server in my LAN?
- What remains is the DynDNS to find my way back to my LAN. As the VPN router will be on the VPN now (in this new scenario), but still behind my ISP modem (on which I installed my DynDNS currently), I guess I should install my DynDNS service on the VPN router. However, ASUS Merlin states that this might not work. Correct?

I am ready to try and tinker as I did already many many many hours before.
And I will give feedback on my lessons learned to possibly help others.

Well now you're delving into new territory when it comes to VPN port forwarding w/ PIA. Yes, PIA does support port forwarding over their VPN, but it has a boatload of limitations. They require the use of a special API, it only works w/ specific VPN servers, only allows *one* port forward, etc. To even have a chance of port forwarding w/ PIA takes quite a bit of skills. That's why I wrote a script specifically to handle PIA port forwarding.

https://pastebin.com/DrwquEeT

I wrote it about a year ago for a dd-wrt member who requested it. I then ported it to tomato shortly thereafter. Then only a few weeks ago, ported it to Merlin. I recently had one member of SNB attempting to use it, but they never reported back whether it worked for them.
 
I respect your efforts that went into your coding.
I will try it and give feedback.

From your feedback I understand I need to do this on my VPN router and through SSH (but also including some kind of "activation code" in my Custom Configuration of the VPN client - as described in your code).

Begin options - questions regarding your code:

- "internal port of PIA port forward" is set at 80. Should it not be set at 1194 for my VPN Server to work?

- Should I still forward ports on my ISP modem/router and VPN router?

- Most limitations I read about already, however, the one that puzzles me is this one:
# - PIA port forward is NOT accessible from the same public ip as the OpenVPN client that initiated the connection
With this limitation (and assuming that my ddns provider does not blacklist PIA), how should I connect back to my LAN?
I do not know this DNSoMatic from your code, but would setting this up with my current DDNS provider help?
I guess I then need to remove the DDNS service request on my ISP modem/router (not on PIA clearly) in order to avoid conflicts?
 
You are absolutely right.
I am being contradictory.
This contradiction is caused by my inexperience in this matter, my apologies. I am learning bit by bit what network management means, triggered by increased awareness about privacy on the internet and the role of the ISP and other parties. So even though I run also a bittorrent client, I still wish to have my VPN running on my whole LAN if this is possible.

I do not have the skills (yet) to implement/adapt the "Policy based routing (manual method)".

I do have a VPN provider that supports port forwarding - PIA - but I am still trying to grasp the basics of this.

My further questions to continue this route (and please correct me if I am wrong so I can learn from it):
- This would mean that I could forward the VPN port 1194 of my VPN server (which is already forwarded through my ISP modem/router) through the VPN provider's "firewall"?
- How do you make that work? I know there is an option in their client software to ask for port forwarding, but shouldn't this be asked from the client running on the VPN router? I found something which might lead to a solution here:
https://www.privateinternetaccess.com/forum/discussion/23431/new-pia-port-forwarding-api
but where should I use this on the ASUS Merlin? Custom Configuration in the VPN client or somewhere through SSH?
And then there is the challenge to "connect" the port they have given me to the 1194 port opened through my firewall...
- Also, the port they give you might change. How to manage that? I guess the connection needs to be ON all the time in order not to break the port forwarding.
- And if I manage to get this gate to my VPN server (which will be running on the VPN router or the Synology, still to decide) open, does this mean that I would be making a "tunnel in a tunnel"? In other words: VPN outgoing through VPN provider (encrypted) and then inside this tunnel my incoming encrypted tunnel from my pc to the OpenVPN Server in my LAN?
- What remains is the DynDNS to find my way back to my LAN. As the VPN router will be on the VPN now (in this new scenario), but still behind my ISP modem (on which I installed my DynDNS currently), I guess I should install my DynDNS service on the VPN router. However, ASUS Merlin states that this might not work. Correct?

I am ready to try and tinker as I did already many many many hours before.
And I will give feedback on my lessons learned to possibly help others.

I found port forwarding to be quite difficult and I never really got it to work :(.
I would suggest to follow the suggestion by @Martineau if you know the port that your NAS Synology uses...
Or
You could allow passthrough to your VPN client when connecting to your VPN server. You would then route devices connecting to your VPN server through your VPN client. You can read more about it in this thread.
[Edit] This would preserve VPN connectivity on your lan as well as any device connecting to your VPN server.
https://www.snbforums.com/threads/openvpn-server-and-client-question.38378/

Good luck with whatever you choose :).
 
Last edited:
From your feedback I understand I need to do this on my VPN router and through SSH (but also including some kind of "activation code" in my Custom Configuration of the VPN client - as described in your code).

Not sure I'd call it an activation code. But yes, you add the following to the custom config section of that particular OpenVPN client.

Code:
writepid /tmp/var/run/vpnclient.pid

This is a common OpenVPN directive that helps the script track that particular OpenVPN client as it starts, restarts, and stops. The script is able to detect when this happens, and if necessary, rerun through the same process of determining the external port, creating the local port forward(s) over the OpenVPN client's network interface, etc.

Begin options - questions regarding your code:

- "internal port of PIA port forward" is set at 80. Should it not be set at 1194 for my VPN Server to work?

Yes. By default, mostly for demonstration purposes or to prove it works, the script uses the router's LAN ip and GUI port (80). But eventually you'll want to specify your own internal IP and internal port. You can either modify the script, or (preferably) pass them via command line arguments (--ip and --port). The script is actually two scripts; an outer/wrapper script (/jffs/scripts/services-start), which is what the router automatically calls on bootup, and inner/wrapped script (/jffs/scripts/merlin-pia-port-forward.sh), which the outer/wrapper script executes. It's within the outer/wrapper script you can add/modify command line arguments to the inner/wrapped script.

- Should I still forward ports on my ISP modem/router and VPN router?

NO! In this particular case, you are creating an outbound tunnel from the second router using the OpenVPN client to the VPN provider's VPN server. All port forwarding by the VPN provider will be inbound over that same tunnel, directly back to the OpenVPN client. So the ISP's modem+router and your second router, in terms of their respective WAN's, are totally oblivious to all this activity. It's all hidden within the tunnel. The script takes care of *local* port forwarding over the OpenVPN clients end of the tunnel, and then on to the target you've specified w/ the --ip and --port arguments I mentioned above.

It's very much like SSH remote port forwarding (if that means anything to you), where remote traffic is able to tunnel itself back into the SSH client from the SSH server.

- Most limitations I read about already, however, the one that puzzles me is this one:
# - PIA port forward is NOT accessible from the same public ip as the OpenVPN client that initiated the connection
With this limitation (and assuming that my ddns provider does not blacklist PIA), how should I connect back to my LAN?

Under normal circumstances, this would never happen. As you roam outside your home network, you will *always* be accessing it *from* a different public IP than your home router's WAN or VPN public IPs.

For testing purposes, or to prove to themselves it's working, some ppl might be tempted to access the port forward while still inside their home network (which would normally happen over the active OpenVPN client). That's what it's telling you NOT to do! The proper way to access it (even for testing purposes) it is to actually be on the internet side of the WAN (cellular network, neighbor's wifi, etc.).

I do not know this DNSoMatic from your code, but would setting this up with my current DDNS provider help?
I guess I then need to remove the DDNS service request on my ISP modem/router (not on PIA clearly) in order to avoid conflicts?

Strictly speaking, DDNS is an option. For all I know, your VPN's public IP might be determinable from the PIA website, perhaps in the support section, in some "Client Area". But I added DDNS support just in case this wasn't the case. This has NOTHING to do w/ the DDNS support on the router. That's only for the purposes of determining the public IP on the WAN. Leave that as it is. For the purposes of this script, you need to *add* another DDNS name that can be associated w/ the public IP of the VPN. To keep things simple and flexible, I chose to use dnsomatic.com, for several reasons. First, it's been around forever. Second, it acts as a DDNS *proxy*, where you can configure it to update other DDNS providers. So effectively it allows you to choose among many other DDNS providers, as long as they are on the dnsomatic supported list. But as I said, *some* DDNS providers blacklist known VPN providers. Finally, it still supports http (many DDNS providers have moved to https, and that can be a problem for some older routers that only support the older wget and http).

PIA has made this ridiculously complex. Most other VPN providers who support port forwarding make it brain-dead simple. But PIA has chosen all this complexity for some reason.
 
Last edited:
Not sure I'd call it an activation code. But yes, you add the following to the custom config section of that particular OpenVPN client.

Code:
writepid /tmp/var/run/vpnclient.pid

This is a common OpenVPN directive that helps the script track that particular OpenVPN client as it starts, restarts, and stops. The script is able to detect when this happens, and if necessary, rerun through the same process of determining the external port, creating the local port forward(s) over the OpenVPN client's network interface, etc.



Yes. By default, mostly for demonstration purposes or to prove it works, the script uses the router's LAN ip and GUI port (80). But eventually you'll want to specify your own internal IP and internal port. You can either modify the script, or (preferably) pass them via command line arguments (--ip and --port). The script is actually two scripts; an outer/wrapper script (/jffs/scripts/services-start), which is what the router automatically calls on bootup, and inner/wrapped script (/jffs/scripts/merlin-pia-port-forward.sh), which the outer/wrapper script executes. It's within the outer/wrapper script you can add/modify command line arguments to the inner/wrapped script.



NO! In this particular case, you are creating an outbound tunnel from the second router using the OpenVPN client to the VPN provider's VPN server. All port forwarding by the VPN provider will be inbound over that same tunnel, directly back to the OpenVPN client. So the ISP's modem+router and your second router, in terms of their respective WAN's, are totally oblivious to all this activity. It's all hidden within the tunnel. The script takes care of *local* port forwarding over the OpenVPN clients end of the tunnel, and then on to the target you've specified w/ the --ip and --port arguments I mentioned above.

It's very much like SSH remote port forwarding (if that means anything to you), where remote traffic is able to tunnel itself back into the SSH client from the SSH server.



Under normal circumstances, this would never happen. As you roam outside your home network, you will *always* be accessing it *from* a different public IP than your home router's WAN or VPN public IPs.

For testing purposes, or to prove to themselves it's working, some ppl might be tempted to access the port forward while still inside their home network (which would normally happen over the active OpenVPN client). That's what it's telling you NOT to do! The proper way to access it (even for testing purposes) it is to actually be on the internet side of the WAN (cellular network, neighbor's wifi, etc.).



Strictly speaking, DDNS is an option. For all I know, your VPN's public IP might be determinable from the PIA website, perhaps in the support section, in some "Client Area". But I added DDNS support just in case this wasn't the case. This has NOTHING to do w/ the DDNS support on the router. That's only for the purposes of determining the public IP on the WAN. Leave that as it is. For the purposes of this script, you need to *add* another DDNS name that can be associated w/ the public IP of the VPN. To keep things simple and flexible, I chose to use dnsomatic.com, for several reasons. First, it's been around forever. Second, it acts as a DDNS *proxy*, where you can configure it to update other DDNS providers. So effectively it allows you to choose among many other DDNS providers, as long as they are on the dnsomatic supported list. But as I said, *some* DDNS providers blacklist known VPN providers. Finally, it still supports http (many DDNS providers have moved to https, and that can be a problem for some older routers that only support the older wget and http).

PIA has made this ridiculously complex. Most other VPN providers who support port forwarding make it brain-dead simple. But PIA has chosen all this complexity for some reason.

Clear explanation, thanks.

Unfortunately I cannot get further then step 3 in your installation.
The "writepid /tmp/var/run/vpnclient.pid" stops my VPN client due to a simple error (from logs): "No such file or directory".
I tried to create the file, but I cannot even access the directory (or above) through SSH. Probably an issue of authorization, but from tinkering with a Raspberry Pi I have learned that I should not take this lightly.

Any ideas?
writepid /tmp/var/run/vpnclient.pid
writepid /tmp/var/run/vpnclient.pid
 
Clear explanation, thanks.

Unfortunately I cannot get further then step 3 in your installation.
The "writepid /tmp/var/run/vpnclient.pid" stops my VPN client due to a simple error (from logs): "No such file or directory".
I tried to create the file, but I cannot even access the directory (or above) through SSH. Probably an issue of authorization, but from tinkering with a Raspberry Pi I have learned that I should not take this lightly.

Any ideas?
writepid /tmp/var/run/vpnclient.pid
writepid /tmp/var/run/vpnclient.pid

That's odd. Normally anything under /tmp is read/write for you or any process. I just ran it here (using 384.12 beta) and it runs fine. Before the OpenVPN client starts, I can even ran the following commands and it works fine (reports back 000).

Code:
echo 000 >  /tmp/var/run/vpnclient.pid
cat /tmp/var/run/vpnclient.pid

The only thing I can guess is maybe the entire directory structure (/tmp/var/run) isn't available in all cases by the time the OpenVPN client starts, esp. if you have the OpenVPN client setup to "automatically start at boot time". But that still seems unlikely.

What happens if you do NOT use "automatically start at boot time", but just let the system come up, then turn the OpenVPN client ON (thus giving the system more time to establish the /tmp/var/run directory structure)?

Frankly, it doesn't matter where the pid is stored, so you could try changing the script and custom config to use /tmp/vpnclient.pid, so you avoid the issue of the entire directory structure not being available, if that indeed is the problem.

But as I said, it runs fine over here. Doesn't make sense unless something changed between the 384.12 beta and 384.12 release, which doesn't seem likely either.

Btw, which release of the firmware are you using?
 

Similar threads

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