Automated scripts for Private Internet Access port forwarding

ProHill

It looks like you added the lines inside a comment. In any event, try putting it in a new .conf file in /usr/local/etc/devd/

You will probably have to create the devd directory. Name the file anything you want, as long as it ends in .conf

Do a /etc/rc.d/devd restart, and it should pick up the new rule.

This is working for me in 2.4.

Andy

Hakon74

Thank you ProHill

Your solution works for me too :D :D

joelones

Great thread, saved me lots of effort.

joelones

I seem to be getting inconsistent results all of a sudden, I notice the script works fine, I get the port from PIA and update the alias, the script exits correctly but checking if the port is open results in a close port.

If I run the "/etc/rc.filter_configure" from the command line after the script runs then the port becomes open. Running 2.4.3. Thoughts on what could be going on here?

Bagpuss

Please see the second post in the thread for some new updates that take into account changes being made by PIA to the port forwarding mechanism.
My original scripts will stop working soon, as PIA are discontinuing the original API

Bagpuss

@joelones:

I seem to be getting inconsistent results all of a sudden, I notice the script works fine, I get the port from PIA and update the alias, the script exits correctly but checking if the port is open results in a close port.

If I run the "/etc/rc.filter_configure" from the command line after the script runs then the port becomes open. Running 2.4.3. Thoughts on what could be going on here?

Not sure what's going on there. I'm still running 2.4.2-p1.
I'll upgrade and see if I get the same behaviour.

You might also want to give the new v1.05 script a try, as this works with the new API that PIA have introduced for port forwarding.

Bagpuss

@joelones:

I seem to be getting inconsistent results all of a sudden, I notice the script works fine, I get the port from PIA and update the alias, the script exits correctly but checking if the port is open results in a close port.

If I run the "/etc/rc.filter_configure" from the command line after the script runs then the port becomes open. Running 2.4.3. Thoughts on what could be going on here?

Just updated to 2.4.3, and am not seeing this behaviour on my system with the 1.05 script.

Bagpuss

Please check second post for another update.
For those who use Deluge on Synology NAS, I've now provided updated scripts to support it.

joelones

I noticed that over time the PIA assigned port tends to close on me. Not sure if others experience the same. I find myself visiting port verifying sites like yougetsignal.com, etc to check whether the port is still open.

Any thoughts on how to script this check from the command line, I assume it would have to be able to use the specific interface and whatnot.

~~Just wondering if someone could put together a script to check whether the port is still open and if not, restart the vpn client.~~
EDIT: So I wrote a little script that checks the port, if closed from the exterior restarts the vpn service and sends an email. Of course, it assumes that you have installed AccountIsTaken's script (including the devd portion), email set up, and an alias for the forwarded port. I slapped it in a cron job.


#!/bin/sh
export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin

# Config file
CONFFILE=/cf/conf/config.xml

# Interface name of vpn connection
VPNCLIENT=2
INTERFACE="ovpnc$VPNCLIENT"

# Get current NAT port number using xmlstarlet to parse the config file - requires alias 'PIAPort' to be present
CURPORT=`xml sel -t -v '//alias[name="PIAPort"]/address' $CONFFILE`

# Check forwarded port from the exterior
OUTPUT=$(curl -s --interface $INTERFACE --max-time 10 -d "portNumber=$CURPORT" -X POST https://ports.yougetsignal.com/check-port.php 2>&1)
if ! echo $OUTPUT | grep -iq "open";  then
    logger "pia-port - Port ($CURPORT) is closed on VPN ($INTERFACE) on `date`"

    # Notify via email
    echo "pia-port - Port ($CURPORT) is closed on VPN ($INTERFACE) on `date`" | /usr/local/bin/php /usr/local/bin/mail.php -s"pfSense PIA Port Forward" &

    # Restart openvpn client
    /usr/local/sbin/pfSsh.php playback svc restart openvpn client $VPNCLIENT
fi

PnoT

@bagpuss None of the attachments you've linked are downloadable now. Do you have any updated links so I can give this solution a try?

Thanks

Bagpuss

@pnot Have re-uploaded the files in post 2. I'm guessing the move to new forum software broke the original links.
Apologies for not responding sooner.

cobhc

This post is deleted!

ijdod

I had to add a 'sleep 10' top the start of the script, otherwise the script would have tried to query PIA before the link was established when triggered by devd.
I also added /etc/rc.filter_configure to the end of the script to actually reload the firefall rules.

CyberDave

Can you post the details of the firewall rules again? I had it working at one point, but then switched ISPs and had to delete and recreate some interfaces and now I can't get the port-forwarding working again. Thanks.

Soloam

Hello all, I had made some adjustments to the script, I changed it to update a Alias and not the rule, I need the port to other rules. I was able to get the port and update the alias. I use transmission, so i updated the port in transmission, also working. The problem is that the port still shows as closed in transmission even with the NAT rule (the same rule that was working in the previews version of the API). I tried to add "/etc/rc.filter_configure" but with no success.

Also the devd rule is not working, I made the setup to ovpnc1 (my interface) ad still not working.

Any help?

Thank you

Bagpuss

@Soloam said in Automated scripts for Private Internet Access port forwarding:

Hello all, I had made some adjustments to the script, I changed it to update a Alias and not the rule, I need the port to other rules. I was able to get the port and update the alias. I use transmission, so i updated the port in transmission, also working. The problem is that the port still shows as closed in transmission even with the NAT rule (the same rule that was working in the previews version of the API). I tried to add "/etc/rc.filter_configure" but with no success.

Also the devd rule is not working, I made the setup to ovpnc1 (my interface) ad still not working.

Any help?

Thank you

Hi Soloam,

We really need some more detail on what changes you've made.

As a starting point, please could you attach:

Screenshot of Firewall -> NAT -> Port Forward
Screenshot of Firewall -> Rules -> whatever interface your port forward is configured on (e.g. mine is on my first VPN interface).
More details of how you're using aliases to affect the port forward.
Details on what you're doing that means you have other rules using the port.
The modified script with your changes.

If Transmission is still saying that the port is closed, then it likely is. You could try using yougetsignal.com to test if it's open. Remember, your outgoing traffic to yougetsignal.com must be coming from the same interface that the port forward is configured on, or you must put the external IP for the appropriate interface into the 'Remote Address' field.

Andy.

Soloam

@Bagpuss thank you, problem is solved! It was a typo error. Sorry

Thank You
Best Regards

HolyK

@Soloam Hi! Could you please share your updated version of the script? Thank you in advance !

dnarzi

Hi! Thanks for this very useful script. I'm having a problem where the config automatically reverts after a minute or so:

Using version 1.06 on 2.4.4-RELEASE-p3 and the devd script. Everything works fine, the port change is pulled from PIA, applied to the config, and placed in pia_port.txt. However, after a minute the config reverts to what is was prior to the script running. If I watch the webGUI Firewall/Aliases/Ports after restarting the openvpn instance, I can see the alias for my port is successfully changed to the new value, but after about a minute it goes back to what it was before running the script. Therefore, only the pia_port.txt has the new value for the port, and the config.xml still has the old one. Is this due to some config file lock or something that prevents scripts from replacing config.xml? I can't find a way around it. No matter what changes this script makes to the config, after running cp /tmp/config.pia $CONFFILE and then rm /tmp/config.cache, the changes only persist for the next 1 minute. Any ideas?

fm808

@Soloam do you mind sharing your script please?