PIA Next-Gen Servers and Port Forwarding Automation

[Pyrhic]

Hi all,

Apologies if I've missed the answer to this - I did a bit of digging in the search and didn't find it:

Private Internet Access have launched their 'next gen' / gen 4 set of servers, and will be switching off the old ones at the end of October. The old port forwarding method used in the scripts given in HTPC's automation guides will not work with the gen 4 servers - they need to use the new port forwarding request method.

Has anyone successfully produced an easy script to 1) get a port from PIA next gen 2) update Deluge with the port?

I think the second I could probably just about work out for myself by Frankensteining bits in from the existing script - it's really the first bit that baffles. PIA themselves have made some scripts here which should in theory work:

https://www.privateinternetaccess.com/he...forwarding

but to my (untrained, amateur, feeble) eyes, it looks like a mega script that does all sorts of things in addition to requesting port forwards, and I'm not sure I understand it enough to fillet it down to just the bit I need.

So er - can I copy anyone's homework?

Thanks as always 

[DocDrydenn]

Found this post and noticed there was a lot of views but no answers, so...

I spent a little time and managed to wrangle together a fix. I now have my Split Tunnel working on the PIA Next-Gen servers with proper Next-Gen Port Forwarding.

Give me some time to "clean it up" and gather it together... I'll post how I did it here as soon as I can.

[Pyrhic]

(Nov 09, 2020, 06:16 PM)DocDrydenn Wrote: Found this post and noticed there was a lot of views but no answers, so...

I spent a little time and managed to wrangle together a fix. I now have my Split Tunnel working on the PIA Next-Gen servers with proper Next-Gen Port Forwarding.

Give me some time to "clean it up" and gather it together... I'll post how I did it here as soon as I can.

Amazing! Thanks so much, that'd be HUGELY appreciated I've started to gather together some scraps of how to do it from the official scripts, but it was rather like looking at a 5,000 piece jigsaw puzzle and having to get to work...

[DocDrydenn]

Okay, so here's how I got it working...

First, I must give 99.99% of the credit to thrnz for working out the scripts I used as the base of this fix. https://github.com/thrnz/docker-wireguard-pia (I'll take the remaining 0.01% credit for piecing it all together. LOL)

Second, I am no "expert" to any of this. My "fix" is sloppy and could probably be done much nicer by someone else with more experience. Since that person hasn't stepped up to offer it, we'll all have to settle for my messy "fix". Also, feel free to modify/change any part of it. Again, 99.99% of the credit is to thrnz.

I'm running Transmission on my server and I've setup everything (transmission and the split tunnel) by following the steps from the guides (along with some tips on the forum for Ubuntu 18.04). When the legacy PIA servers were switched off, I did have to update my OpenVNP setup to use the new servers. I'm not going to cover what I had to do to make the switch since most have probably already figured this out. Instead, this post is for getting Port Forwarding working with the PIA Next-Gen servers when setup for Split Tunneling... as per the guides.

I say that, so that you might have an idea of what I started with. The "fix" I provide here depends upon this setup - for example: the guide sets up the split tunnel on `tun0` and includes multiple script files (we'll be modifying one of them...). It also sets up a systemd service (`openvpn@openvpn.service`). My point is this: If your setup is different, then you'll need to figure out the differences and make any needed adjustments... and I will most likely not be able to help you if you run into problems.

Code:

#UPDATE: These scripts need "jq", "traceroute", and  "curl" installed or they won't work.

sudo apt install traceroute jq curl -y

Here's the deal: Port Forwarding with the PIA Next-Gen servers is a bit more complicated than it used to be.
1. It requires an authorizing "token" be generated from a PIA server. 
2. It requires a port number be requested from a PIA server (with the generated "token" from step 1).
3. The assigned port number requires a "keep-alive" about every 15 minutes or the port will be closed.
4. Once we have a good port number, we need to feed it to Transmission (just as we had to do before), so we'll need to make a very small modification to the original `/etc/openvpn/portforward.sh` script from the guides.
5. You must be using a PIA server that supports Port Forwarding. See their website for a list if you're not sure.

Some extra notes:
- The "token" generation requires your PIA credentials which you will add to the main script.
- Because the assigned port number must be "kept alive" the script must not be stopped once it has been started. (My fix for this is to run it as a service... I'll explain more about this below).
- The "token" will expire after about 2 months and will have to be re-generated. (Just reboot the system or restart the service we create below)
- Since the guides sorta use the `/etc/openvpn/` folder as the working directory for most of the original scripts, I decided to do the same for this fix. If you decide to use a different folder, be sure to make the needed path changes inside the scripts/files.
- The "token" and the assigned port number are stored in files (`/etc/openvpn/pia-token.dat` and `/etc/openvpn/port.dat`) for easy use.

Okay, let's start this mess...

---

We will need: 1 new script, 1 modified script, and 1 new service... 

Let's start with the new script: `/etc/openvpn/pia-portforward.sh`
  pia-portforward.sh.txt (Size: 9.76 KB / Downloads: 108)

This script is the heart of it all. After creating this file, be sure to enter your PIA credentials, save it, and make it executable (`chmod +x pia-portforward.sh`).

Now, the modified script: `/etc/openvpn/portforward.sh`

This file should already exist (since it would have been made by following the guides) and we only need to make a slight change to it. Open it up and scroll down to the "request new port" section. There's no reason to get fancy here... just comment out what's already there and add the `PORT=$(cat /etc/openvpn/port.dat)` line... It should look something like below. Here, we're just telling this script to get the port number from the file our main script created. Easy.

Code:

#request new port
#PORTFORWARDJSON=$(curl -m $CURL_TIMEOUT --silent --interface $VPNINTERFACE  'https://www.privateinternetaccess.com/vpninfo/port_forward_assignment' -d "user=$USERNAME&pass=$PASSWORD&client_id=$CLIENT_ID&local_ip=$VPNLOCALIP" | head -1)
#trim VPN forwarded port from JSON
#PORT=$(echo $PORTFORWARDJSON | awk 'BEGIN{r=1;FS="{|:|}"} /port/{r=0; print $3} END{exit r}')
PORT=$(cat /etc/openvpn/port.dat)
echo $PORT

Lastly, we need to create the service that will run our script... and keep it running: `/etc/systemd/system/pia-pf.service`
  pia-pf.service.txt (Size: 344 bytes / Downloads: 74)

After creating this file, we need to add it to the system with `sudo systemctl enable pia-pf.service`

At this point, we can start the service with `sudo systemctl start pia-pf.service` and check the status with `sudo systemctl status pia-pf.service`.
(Note: The service can take a few seconds to get the port so you may need to check the status a few times.)

If needed, the service can be stopped with `sudo systemctl stop pia-pf.service` or restarted with `sudo systemctl restart pia-pf.service`. To remove the service from the system, stop the service first, then run `sudo systemctl disable pia-pf.service`.

Checking the status, you should notice that it says that the service is "active (running)" and that it indicates the port that it got from PIA.

You can also check that the port number being reported matches the number put into `/etc/openvpn/port.dat`

Lastly, you can check your Transmission to see if it received the correct port and that it tests as working.

That's it. I'm sure my explanation is rough to follow, but it does work... at least on my server. Feel free to ask questions, but remember that I'm a noob to all this and probably won't be able to help you. Hopefully, those who are experts will be able to provide any needed help. Good luck... you'll need it. LOL

[Pyrhic]

Hi Doc,

Thanks so much for writing that up - very easy to follow along, but predictably it hasn't quite gone smoothly - service file status is showing failure - I know you said you probably can't help, but I'll ask anyway in case it's something easy:

(FYI in case you want to keep working on this script for others - I had one problem along the way I was able to self-troubleshoot - you need traceroute installed for this to work, and it needs to be the older version of traceroute one can get in Ubuntu's apt package manager, not the inetutils-traceroute one!)

Originally I was only getting pia-token.dat created - one I installed traceroute I got a little further and port.dat appeared, which appears to be valid to the naked eye (i.e. - looks like a port!) and it also looks like it has been fed through to Deluge successfully (i.e. the incoming port matches the one in port.dat!) - so I think it's tantalisingly close...

Running the script manually for debug purposes, I'm still getting a failure:

trap: SIGTERM: bad trap
4c64d95df2e319baf528c77b3a403c8acb827d9cb4d1457d79428a1cc1cd221a468da9cb99d4c4c8b2956bb0f1318c5d9a0bf1e943ab8d20ccdcf0f7b8a58139
Tue 10 Nov 12:22:50 GMT 2020: Automatically getting API IP failed.
./pia-portforward.sh: 72: [: unexpected operator
Tue 10 Nov 12:22:50 GMT 2020: Fatal error

I think that means something on line 72 is the problem (?) line 72 appears to be:


  [ "$cacert_istemp" == "1" ] && [ -w "$cacert" ] && rm "$cacert"

Any ideas?

Thanks again for going to the trouble of putting this together and helping me out - the kindness of the internet always humbles me

UPDATE: had another look at this; I don't know *when* this started work, but systemctl status is now showing it as running, but the last messages (?) show an error of sorts I recognise; I might be mangling this explanation, but basically - either Deluge changed the version of Python it targets, or I've got too modern a version of Python on my system now - in any case, it throws up an error essage when you try to change the port programmatically as in the old PIA script, but it *does* actually succeed. The service file is showing the error you get when you try to change the port (presumably because the service file is calling the original portforward.sh script) - so I think all is fine, assuming this error isn't causing it to fail (which I assume it's not as it's showing as "active (running)"

That all said, running the pia-portforward.sh script is still showing that issue around line 72 - given it seems to be working, maybe it can be safely ignored, but thoughts welcome!

[DocDrydenn]

Interesting... Yes, good catch on the traceroute... I forgot I had to install that.

As for your error, it's erroring in the in the cleanup function... which happens after a failure. Looking at your post, you're actually erroring out at the "Automatically getting API IP failed" message. That routine is located around line number 190.

Code:

# Hacky way to try to automatically get the API IP: use the first hop of a traceroute.
# This seems to work for both Wireguard and OpenVPN.
# Ideally we'd have been provided a cn, in case we 'guess' the wrong IP.
# Must be a better way to do this.
if [ -z "$api_ip" ]; then
 api_ip=$(traceroute -4 -m 1 $iface_tr privateinternetaccess.com | tail -n 1 | awk '{print $2}')
 # Very basic sanity check - make sure it matches 10.x.x.1
 if ! echo "$api_ip" | grep -q '10\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.1'; then
   echo "$(date): Automatically getting API IP failed."
   fatal_error
 fi
 echo "$(date): Using $api_ip as API endpoint"
fi

Are you passing the correct network interface to the script with the `-f` argument (i.e. `-f tun0`)?
Do you already have a connection to the PIA server on this interface?
Is that interface connecting to a PIA server that supports Port Forwarding? Not all PIA servers do. Check the PIA website to see if the one you're using supports Port Forwarding.

The script does allow for an API IP to be provided by use of the '-i' argument (i.e. `-i <API_IP>`). Without this, the script will attempt to guess at the correct IP.

See, I told you I wouldn't be of much help. LOL

If nothing else, I believe we've narrowed it down to this section. Oh, and I believe the original cert error you're seeing (the failure during the cleanup function) is because that cleanup function is trying to remove the cert, however, the cert wasn't downloaded yet (due to the API IP error). The code could use more error handling... but for now, I'm sure once you get the API IP part settled, the cert error will go away.

---

Here is the full working status output of my working setup...

Code:

transmission@transmission:~$ sudo systemctl status pia-pf.service
[sudo] password for transmission:
● pia-pf.service - PIA Port Forwarding Daemon
    Loaded: loaded (/etc/systemd/system/pia-pf.service; enabled; vendor preset: enabled)
    Active: active (running) since Mon 2020-11-09 17:22:12 EST; 15h ago
  Main PID: 619170 (pia-portforward)
     Tasks: 2 (limit: 7032)
    Memory: 2.6M
    CGroup: /system.slice/pia-pf.service
            ├─ 619170 /bin/sh /etc/openvpn/pia-portforward.sh -f tun0 -p /etc/openvpn/port.dat -s /etc/openvpn/portforward.sh
            └─1393624 sleep 900

Nov 09 17:22:12 transmission systemd[1]: Started PIA Port Forwarding Daemon.
Nov 09 17:22:12 transmission pia-pf[619170]: trap: SIGTERM: bad trap
Nov 09 17:22:12 transmission pia-pf[619170]: <token>
Nov 09 17:22:20 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:20 PM EST: Using 10.x.xxx.1 as API endpoint
Nov 09 17:22:21 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:21 PM EST: Using zurich404 as cn
Nov 09 17:22:21 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:21 PM EST: Getting PIA ca cert
Nov 09 17:22:22 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:22 PM EST: Verifying API requests. CN: zurich404
Nov 09 17:22:22 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:22 PM EST: Getting PF token
Nov 09 17:22:23 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:23 PM EST: Obtained PF token. Expires at 2021-01-11T12:24:04.025116072Z
Nov 09 17:22:23 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:23 PM EST: Server accepted PF bind
Nov 09 17:22:23 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:23 PM EST: Port dumped to /etc/openvpn/port.dat
Nov 09 17:22:23 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:23 PM EST: Running /etc/openvpn/portforward.sh
Nov 09 17:22:24 transmission pia-pf[619318]: 212.102.37.52
Nov 09 17:22:24 transmission pia-pf[619318]: 39163
Nov 09 17:22:24 transmission sudo[619340]:     root : TTY=unknown ; PWD=/etc/openvpn ; USER=root ; COMMAND=/usr/sbin/iptables -D INPUT 2
Nov 09 17:22:24 transmission sudo[619340]: pam_unix(sudo:session): session opened for user root by (uid=0)
Nov 09 17:22:24 transmission sudo[619340]: pam_unix(sudo:session): session closed for user root
Nov 09 17:22:24 transmission sudo[619342]:     root : TTY=unknown ; PWD=/etc/openvpn ; USER=root ; COMMAND=/usr/sbin/iptables -I INPUT 2 -i tun0 -p tcp --dport>
Nov 09 17:22:24 transmission sudo[619342]: pam_unix(sudo:session): session opened for user root by (uid=0)
Nov 09 17:22:24 transmission sudo[619342]: pam_unix(sudo:session): session closed for user root
Nov 09 17:22:24 transmission pia-pf[619347]:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Nov 09 17:22:24 transmission pia-pf[619347]:                                  Dload  Upload   Total   Spent    Left  Speed
Nov 09 17:22:24 transmission pia-pf[619347]: [158B blob data]
Nov 09 17:22:24 transmission pia-pf[619347]: {"arguments":{},"result":"success"}
Nov 09 17:22:24 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:24 PM EST: Forwarding on port 39163
Nov 09 17:22:24 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:24 PM EST: Rebind interval: 900 seconds
Nov 09 17:22:24 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:24 PM EST: This script should remain running to keep the forwarded port alive
Nov 09 17:22:24 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:24 PM EST: Press Ctrl+C to exit
transmission@transmission:~$

[Pyrhic]

(Nov 10, 2020, 01:37 PM)DocDrydenn Wrote: Interesting... Yes, good catch on the traceroute... I forgot I had to install that.

As for your error, it's erroring in the in the cleanup function... which happens after a failure. Looking at your post, you're actually erroring out at the "Automatically getting API IP failed" message. That routine is located around line number 190.

Code:

# Hacky way to try to automatically get the API IP: use the first hop of a traceroute.
# This seems to work for both Wireguard and OpenVPN.
# Ideally we'd have been provided a cn, in case we 'guess' the wrong IP.
# Must be a better way to do this.
if [ -z "$api_ip" ]; then
 api_ip=$(traceroute -4 -m 1 $iface_tr privateinternetaccess.com | tail -n 1 | awk '{print $2}')
 # Very basic sanity check - make sure it matches 10.x.x.1
 if ! echo "$api_ip" | grep -q '10\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.1'; then
   echo "$(date): Automatically getting API IP failed."
   fatal_error
 fi
 echo "$(date): Using $api_ip as API endpoint"
fi

Are you passing the correct network interface to the script with the `-f` argument (i.e. `-f tun0`)?
Do you already have a connection to the PIA server on this interface?
Is that interface connecting to a PIA server that supports Port Forwarding? Not all PIA servers do. Check the PIA website to see if the one you're using supports Port Forwarding.

The script does allow for an API IP to be provided by use of the '-i' argument (i.e. `-i <API_IP>`). Without this, the script will attempt to guess at the correct IP.

See, I told you I wouldn't be of much help. LOL

If nothing else, I believe we've narrowed it down to this section. Oh, and I believe the original cert error you're seeing (the failure during the cleanup function) is because that cleanup function is trying to remove the cert, however, the cert wasn't downloaded yet (due to the API IP error). The code could use more error handling... but for now, I'm sure once you get the API IP part settled, the cert error will go away.

---

Here is the full working status output of my working setup...

Code:

transmission@transmission:~$ sudo systemctl status pia-pf.service
[sudo] password for transmission:
● pia-pf.service - PIA Port Forwarding Daemon
    Loaded: loaded (/etc/systemd/system/pia-pf.service; enabled; vendor preset: enabled)
    Active: active (running) since Mon 2020-11-09 17:22:12 EST; 15h ago
  Main PID: 619170 (pia-portforward)
     Tasks: 2 (limit: 7032)
    Memory: 2.6M
    CGroup: /system.slice/pia-pf.service
            ├─ 619170 /bin/sh /etc/openvpn/pia-portforward.sh -f tun0 -p /etc/openvpn/port.dat -s /etc/openvpn/portforward.sh
            └─1393624 sleep 900

Nov 09 17:22:12 transmission systemd[1]: Started PIA Port Forwarding Daemon.
Nov 09 17:22:12 transmission pia-pf[619170]: trap: SIGTERM: bad trap
Nov 09 17:22:12 transmission pia-pf[619170]: c451030e5a71cffa56c47b0118e29c7bd31f25d630daa44bc2a4ef0b953e3b041>
Nov 09 17:22:20 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:20 PM EST: Using 10.9.112.1 as API endpoint
Nov 09 17:22:21 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:21 PM EST: Using zurich404 as cn
Nov 09 17:22:21 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:21 PM EST: Getting PIA ca cert
Nov 09 17:22:22 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:22 PM EST: Verifying API requests. CN: zurich404
Nov 09 17:22:22 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:22 PM EST: Getting PF token
Nov 09 17:22:23 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:23 PM EST: Obtained PF token. Expires at 2021-01-11T12:24:04.025116072Z
Nov 09 17:22:23 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:23 PM EST: Server accepted PF bind
Nov 09 17:22:23 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:23 PM EST: Port dumped to /etc/openvpn/port.dat
Nov 09 17:22:23 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:23 PM EST: Running /etc/openvpn/portforward.sh
Nov 09 17:22:24 transmission pia-pf[619318]: 212.102.37.52
Nov 09 17:22:24 transmission pia-pf[619318]: 39163
Nov 09 17:22:24 transmission sudo[619340]:     root : TTY=unknown ; PWD=/etc/openvpn ; USER=root ; COMMAND=/usr/sbin/iptables -D INPUT 2
Nov 09 17:22:24 transmission sudo[619340]: pam_unix(sudo:session): session opened for user root by (uid=0)
Nov 09 17:22:24 transmission sudo[619340]: pam_unix(sudo:session): session closed for user root
Nov 09 17:22:24 transmission sudo[619342]:     root : TTY=unknown ; PWD=/etc/openvpn ; USER=root ; COMMAND=/usr/sbin/iptables -I INPUT 2 -i tun0 -p tcp --dport>
Nov 09 17:22:24 transmission sudo[619342]: pam_unix(sudo:session): session opened for user root by (uid=0)
Nov 09 17:22:24 transmission sudo[619342]: pam_unix(sudo:session): session closed for user root
Nov 09 17:22:24 transmission pia-pf[619347]:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Nov 09 17:22:24 transmission pia-pf[619347]:                                  Dload  Upload   Total   Spent    Left  Speed
Nov 09 17:22:24 transmission pia-pf[619347]: [158B blob data]
Nov 09 17:22:24 transmission pia-pf[619347]: {"arguments":{},"result":"success"}
Nov 09 17:22:24 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:24 PM EST: Forwarding on port 39163
Nov 09 17:22:24 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:24 PM EST: Rebind interval: 900 seconds
Nov 09 17:22:24 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:24 PM EST: This script should remain running to keep the forwarded port alive
Nov 09 17:22:24 transmission pia-pf[619170]: Mon 09 Nov 2020 05:22:24 PM EST: Press Ctrl+C to exit
transmission@transmission:~$

Hiya,

Top marks to that man! - hadn't appreciated that the service file was passing the interface with the -f modifier. Running the script manually with "-f tun0" I now get:

trap: SIGTERM: bad trap
0d497bf5dfc440787accbcd74723eb9a6d5b578caa2b4b5914c95eee951b4c20ba48b9582870b49e41addce5207994cb5c2897aba6fc50ccea46e0a49eed46ff
Tue 10 Nov 14:06:43 GMT 2020: Using ##.##.##. as API endpoint
Tue 10 Nov 14:06:43 GMT 2020: Using YYYYY as cn
Tue 10 Nov 14:06:43 GMT 2020: Getting PIA ca cert
Tue 10 Nov 14:06:44 GMT 2020: Verifying API requests. CN:YYYY
Tue 10 Nov 14:06:44 GMT 2020: Getting PF token
Tue 10 Nov 14:06:45 GMT 2020: Obtained PF token. Expires at 2021-01-12T02:03:39.040439661Z
Tue 10 Nov 14:06:45 GMT 2020: Server accepted PF bind
Tue 10 Nov 14:06:45 GMT 2020: Forwarding on port XXXXX 
Tue 10 Nov 14:06:45 GMT 2020: Rebind interval: 900 seconds
Tue 10 Nov 14:06:45 GMT 2020: This script should remain running to keep the forwarded port alive
Tue 10 Nov 14:06:45 GMT 2020: Press Ctrl+C to exit

(ignore ###, YYYY and XXXX - just obscuring potentially identifying info as this is public etc.)

Not sure if that SIGTERM stuff is a problem (?) but in any case it appears to be working - systemctl status is showing it as running, and I can see that despite this weird Deluge/Python issue, the script appears to keep going after that:

Nov 10 13:30:47 XXXX pia-pf[8406]: Traceback (most recent call last):
Nov 10 13:30:47 XXXX pia-pf[8406]:   File "/usr/lib/python3/dist-packages/>
Nov 10 13:30:47 XXXX pia-pf[8406]:     builtins.__dict__['_n'] = builtins.>
Nov 10 13:30:47 XXXX pia-pf[8406]: KeyError: 'ngettext'
Nov 10 13:30:58 XXXX pia-pf[8406]: Setting "listen_ports" to: (XXXXX, XXXXX>
Nov 10 13:30:58 XXXX pia-pf[8406]: Configuration value successfully update>
Nov 10 13:30:58 XXXX pia-pf[8321]: Tue 10 Nov 13:30:58 GMT 2020: Forwardin>
Nov 10 13:30:58 XXXX pia-pf[8321]: Tue 10 Nov 13:30:58 GMT 2020: Rebind in>
Nov 10 13:30:58 XXXX pia-pf[8321]: Tue 10 Nov 13:30:58 GMT 2020: This scri>
Nov 10 13:30:58 XXXX pia-pf[8321]: Tue 10 Nov 13:30:58 GMT 2020: Press Ctr>

(those first 4 lines are the Deluge/Python issue)

Tried Deluge's built-in port checker tool just now and it's showing as open too.

In short: fairly sure you've sorted me out! Thanks so much for taking pity on my poor, lonely, answerless thread - you've made my day

[Mrzx]

Heey guys, thanks you soo much for this post.
But i having some trouble get it to run, and i got no clue how to get it working, im so new to this  

i get this when i run systemctl status pia-pf.service

Code:

● pia-pf.service - PIA Port Forwarding Daemon
  Loaded: loaded (/etc/systemd/system/pia-pf.service; enabled)
  Active: active (running) since Thu 2020-11-12 22:37:55 CET; 8ms ago
Main PID: 1354 (pia-portforward)
  CGroup: /system.slice/pia-pf.service
          └─1354 /bin/sh /etc/openvpn/pia-portforward.sh -f tun0 -p /etc/openvpn/port.dat -s /etc/openvp...

Nov 12 22:37:55 raspberrypi1 systemd[1]: Starting PIA Port Forwarding Daemon...
Nov 12 22:37:55 raspberrypi1 systemd[1]: Started PIA Port Forwarding Daemon.
Nov 12 22:37:55 raspberrypi1 pia-pf[1354]: trap: SIGTERM: bad trap
Nov 12 22:37:55 raspberrypi1 pia-pf[1354]: /etc/openvpn/pia-portforward.sh: 55: /etc/openvpn/pia-port...ound
Hint: Some lines were ellipsized, use -l to show in full.
root@raspberrypi1:~# sudo systemctl status pia-pf.service


● pia-pf.service - PIA Port Forwarding Daemon
  Loaded: loaded (/etc/systemd/system/pia-pf.service; enabled)
  Active: activating (auto-restart) (Result: exit-code) since Thu 2020-11-12 22:38:00 CET; 2s ago
 Process: 1354 ExecStart=/etc/openvpn/pia-portforward.sh -f tun0 -p /etc/openvpn/port.dat -s /etc/openvpn/portforward.sh (code=exited, status=1/FAILURE)
Main PID: 1354 (code=exited, status=1/FAILURE)

and i don´t see anything in `/etc/openvpn/port.dat`
not sure i even get a "token"

really on deep water here  

but a least transmission is downloading again

[Pyrhic]

(Nov 12, 2020, 10:06 PM)Mrzx Wrote: Heey guys, thanks you soo much for this post.
But i having some trouble get it to run, and i got no clue how to get it working, im so new to this  

i get this when i run systemctl status pia-pf.service

Code:

● pia-pf.service - PIA Port Forwarding Daemon
  Loaded: loaded (/etc/systemd/system/pia-pf.service; enabled)
  Active: active (running) since Thu 2020-11-12 22:37:55 CET; 8ms ago
Main PID: 1354 (pia-portforward)
  CGroup: /system.slice/pia-pf.service
          └─1354 /bin/sh /etc/openvpn/pia-portforward.sh -f tun0 -p /etc/openvpn/port.dat -s /etc/openvp...

Nov 12 22:37:55 raspberrypi1 systemd[1]: Starting PIA Port Forwarding Daemon...
Nov 12 22:37:55 raspberrypi1 systemd[1]: Started PIA Port Forwarding Daemon.
Nov 12 22:37:55 raspberrypi1 pia-pf[1354]: trap: SIGTERM: bad trap
Nov 12 22:37:55 raspberrypi1 pia-pf[1354]: /etc/openvpn/pia-portforward.sh: 55: /etc/openvpn/pia-port...ound
Hint: Some lines were ellipsized, use -l to show in full.
root@raspberrypi1:~# sudo systemctl status pia-pf.service


● pia-pf.service - PIA Port Forwarding Daemon
  Loaded: loaded (/etc/systemd/system/pia-pf.service; enabled)
  Active: activating (auto-restart) (Result: exit-code) since Thu 2020-11-12 22:38:00 CET; 2s ago
 Process: 1354 ExecStart=/etc/openvpn/pia-portforward.sh -f tun0 -p /etc/openvpn/port.dat -s /etc/openvpn/portforward.sh (code=exited, status=1/FAILURE)
Main PID: 1354 (code=exited, status=1/FAILURE)

and i don´t see anything in `/etc/openvpn/port.dat`
not sure i even get a "token"

really on deep water here  

but a least transmission is downloading again

Hey Mrzx,

As is probably clear from my earlier posts, I'm about as far from an expert as they come, but in the spirit of paying it forward, I shall try to help!

Code:

/etc/openvpn/pia-portforward.sh: 55

I could be entirely wrong, but I think that's indicating something is going wrong with line 55 of the pia-portforward.sh script?

if you haven't tried it already, probably the best thing to do is run the script manually so you can see the full output and get a better idea of why it's failing. Sorry if this is insultingly basic, but in case you don't know, I believe you'd enter:

cd /etc/openvpn
sudo ./pia-portforward.sh -f tun0

^ that's assuming that tun0 is your VPN interface.

Try that and let us know what message is spat out?

Also - super super basic stuff, but if you're not even seeing the token file has been created in the folder (i.e. "pia-token.dat") that could suggest something as simple as you've got your username and password wrong - so maybe just check you've added them to the pia-portforward.sh script correctly.

Hopefully we can get you over the line with this!

[Mrzx]

(Nov 13, 2020, 02:11 PM)Pyrhic Wrote:

(Nov 12, 2020, 10:06 PM)Mrzx Wrote: Heey guys, thanks you soo much for this post.
But i having some trouble get it to run, and i got no clue how to get it working, im so new to this  

i get this when i run systemctl status pia-pf.service

Code:

● pia-pf.service - PIA Port Forwarding Daemon
  Loaded: loaded (/etc/systemd/system/pia-pf.service; enabled)
  Active: active (running) since Thu 2020-11-12 22:37:55 CET; 8ms ago
Main PID: 1354 (pia-portforward)
  CGroup: /system.slice/pia-pf.service
          └─1354 /bin/sh /etc/openvpn/pia-portforward.sh -f tun0 -p /etc/openvpn/port.dat -s /etc/openvp...

Nov 12 22:37:55 raspberrypi1 systemd[1]: Starting PIA Port Forwarding Daemon...
Nov 12 22:37:55 raspberrypi1 systemd[1]: Started PIA Port Forwarding Daemon.
Nov 12 22:37:55 raspberrypi1 pia-pf[1354]: trap: SIGTERM: bad trap
Nov 12 22:37:55 raspberrypi1 pia-pf[1354]: /etc/openvpn/pia-portforward.sh: 55: /etc/openvpn/pia-port...ound
Hint: Some lines were ellipsized, use -l to show in full.
root@raspberrypi1:~# sudo systemctl status pia-pf.service


● pia-pf.service - PIA Port Forwarding Daemon
  Loaded: loaded (/etc/systemd/system/pia-pf.service; enabled)
  Active: activating (auto-restart) (Result: exit-code) since Thu 2020-11-12 22:38:00 CET; 2s ago
 Process: 1354 ExecStart=/etc/openvpn/pia-portforward.sh -f tun0 -p /etc/openvpn/port.dat -s /etc/openvpn/portforward.sh (code=exited, status=1/FAILURE)
Main PID: 1354 (code=exited, status=1/FAILURE)

and i don´t see anything in `/etc/openvpn/port.dat`
not sure i even get a "token"

really on deep water here  

but a least transmission is downloading again

Hey Mrzx,

As is probably clear from my earlier posts, I'm about as far from an expert as they come, but in the spirit of paying it forward, I shall try to help!

Code:

/etc/openvpn/pia-portforward.sh: 55

I could be entirely wrong, but I think that's indicating something is going wrong with line 55 of the pia-portforward.sh script?

if you haven't tried it already, probably the best thing to do is run the script manually so you can see the full output and get a better idea of why it's failing. Sorry if this is insultingly basic, but in case you don't know, I believe you'd enter:

cd /etc/openvpn
sudo ./pia-portforward.sh -f tun0

^ that's assuming that tun0 is your VPN interface.

Try that and let us know what message is spat out?

Also - super super basic stuff, but if you're not even seeing the token file has been created in the folder (i.e. "pia-token.dat") that could suggest something as simple as you've got your username and password wrong - so maybe just check you've added them to the pia-portforward.sh script correctly.

Hopefully we can get you over the line with this!

Heey Pyrhic, thank you so much for replying, im really grateful and appreciate the all the super super basic stuff

Yes im not even seeing the token file has been created in the folder (`/etc/openvpn/pia-token.dat` or `/etc/openvpn/port.dat`)

/etc/openvpn/pia-portforward.sh: 55
that line is:

Code:

[ $? -ne 0 ] && echo "Failed to acquire new auth token" && exit 1

So i must fined out why im not getting the token, did check the username and password and it looks right.
We need the  

Code:

"  

  
in-front and after username and password right ?


Also this is what happens when i do sudo ./pia-portforward.sh -f tun0

Code:

root@raspberrypi1:/etc/openvpn# sudo ./pia-portforward.sh -f tun0
trap: SIGTERM: bad trap
./pia-portforward.sh: 54: ./pia-portforward.sh: jq: not found
(23) Failed writing body
Failed to acquire new auth token
root@raspberrypi1:/etc/openvpn#

And yes, i do use tun0 as VPN interface, just like in the guide