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.
Thank u
