Port forwarding Deluge Spit Tunnel Script Error?

[Lt Hawk]

(Mar 10, 2017, 08:53 AM)drake Wrote: @wowbutters@gmail.com
I sent you a PM!

I know about the routing rule, but first we need to make it work without Split Tunnel. Don't even try to add Deluge change, just complicates things. Just try to get the port number with the new script on a base OpenVPN configuration (for example, print the port number to a port.log file). If that works, we already have a new script that will take care of Transmission and Deluge port change.

At the moment, we can't make the new PIA script work with OpenVPN up call.

I'll just reply here, no need for pm and public. Haha.

The only thing I have found, was to just set the port on a 30-60 sleep cron after boot. Based on what the OP for the new API there is no need to refresh unless you change countries. In fact, even with the old API and when i was still using the client, I kept the same port across reboots, d/c's and IP changes, as long as i stayed on the same country server. So, in theory, running it from OpenVPN, may not even be necessary anymore? The way this is set up in order to change the server you would have to reboot anyway correct? In that case, cron would handle it from there. Or, I've wasted all this typing and the error we are getting is writing the new ports to the up call and I'm just being silly . 

[drake]

Well, we have too little information regarding the new API and port assignment, and PIA is not too fast to react.

Cron is good and was the way to go with the old API. It should work with the new API, but how will you handle a situation like VPN connection brakes or you stop the service manually, and then you reconnect to the same or for example a different server? Then you will need to manually trigger the script as we will have the cron job set to run only once after system boot (with some delay). 

And the other thing is: some people reported they managed to run in with OpenVPN up. But reporting that it works doesn't mean anything if they don't provide the exact script they used and how they run it. 

In my point of view, cron is a very good option for the new API but not the final solution. That would be the up call, as then on each OpenVPN service (re)start the port would be checked, updated.

[Lt Hawk]

(Mar 10, 2017, 09:13 AM)drake Wrote: Well, we have too little information regarding the new API and port assignment, and PIA is not too fast to react.

Cron is good and was the way to go with the old API. It should work with the new API, but how will you handle a situation like VPN connection brakes or you stop the service manually, and then you reconnect to the same or for example a different server? Then you will need to manually trigger the script as we will have the cron job set to run only once after system boot (with some delay). 

And the other thing is: some people reported they managed to run in with OpenVPN up. But reporting that it works doesn't mean anything if they don't provide the exact script they used and how they run it. 

In my point of view, cron is a very good option for the new API but not the final solution. That would be the up call, as then on each OpenVPN service (re)start the port would be checked, updated.

This is true, regardless of my experiences, and what PIA claims, things happen and the up call would be the right way to go. What I don't get is why doesn't it work in the first place? I don't really understand why calling it directly from OVPN an issue? Could it be the way it handles calling the script? could it be something as silly as permissions/ownership and the PIA script thinks it is being called outside of the tunnel/vpn? Although, you said you tried it on a clean boot no split right? I haven't had the opportunity yet, I have a spare laptop already loaded with a clean 16.04, but i had somethings going on with nginx/deluge with this set up. I actually posted about it in the guide about 30 mins ago. Still having problems with Transdrone.
 =(  Anyway, I'll try and work on it with the clean install tomorrow or Saturday, and i'll report back in. Let me know if you find anything new yourself. 

P.S. how do i change my username so it is not my email? Haha, I was not able to locate it in profile settings.

[Lt Hawk]

Give me about 30mins and I'll upload to solution. It's so simple...

Sent from my SM-G935V using Tapatalk

[drake]

Looking forward to see the solution!

Sent from Tapatalk from my Z5 Compact

[Lt Hawk]

So here we go:

In order to resolve this we have to understand how both OpenVPN and the new api work, and how they can work together.

We'll start with the easy one, PIA:
In order pull a request from, curl "http://209.222.18.222:2000/\?client_id=$client_id" 2>/dev/null, obviously we need to be connected to a port forward enabled PIA server. 
We all have seen that the provided .sh works if called directly, after we are connected. But not within OpenVPN as an up call.

Now, for OpenVPN:
After a few hours of tinkering and several cups of espresso, I had no idea what was happening, so i started building test scripts basically one line at a time until i found the fail point. In this case the only portion that failed on its own was, of course, the actual port request. 

Eventually I decided to try this up call:

Code:

#! /bin/bash
#this is the test of theory

/path/to/PIA_portforward.sh
#check ip
curl ipinfo.io

Output:

Code:

OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb  2 2016
library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08
WARNING: file '/etc/openvpn/login.txt' is group or others accessible
NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
UDPv4 link local: [undef]
UDPv4 link remote: [AF_INET]PIA_SWISS_IP:1198
[d641a859e9520a418150e085f9b29c12] Peer Connection Initiated with [AF_INET]PIA_SWISS_IP:1198
TUN/TAP device tun0 opened
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
/sbin/ip link set dev tun0 up mtu 1500
/sbin/ip addr add dev tun0 local 10.31.10.10 peer 10.31.10.9
/etc/openvpn/up_call tun0 1500 1558 10.31.10.10 10.31.10.9 init
{
 "ip": "MY_ACTUAL_IP",
 "hostname": "MY_ISP",
 "city": "SOME CITY",
 "region": "ON EARTH",
 "country": "MY",
 "loc": "lat,long",
 "org": "MORE ISP INFO"
}Failure
Initialization Sequence Completed

Notice, that the IP test is still returning my ISP assigned IP. Followed by, "Failure" (this was my quickie way of reporting the portforward failed) and OpenVPN itself reporting "Initialization Sequence Completed". So what does this tell us? Anything that is called by an OpenVPN up call is processed before the connection is actually made. That is why we cannot grab a port, and why the IP test is reporting back MY IP and not PIA's. Now what do we do? Well, its actually quite simple really. 
The first problem we actually face, is if we call portforward.sh directly as an up call. OVPN passes 6 variables to the provided script which breaks it before it even tries to check the port. ( Sorry, I didn't save output for this. but please take my word for it, we don't even get the sorry it failed that we are sick of seeing). This is why we need a "middle man" script, which also gives us a little more room for IPTABLES, and anything else the end-user may wish to task once we are connected.


We see that in this line: 

Code:

/etc/openvpn/up_call tun0 1500 1558 10.31.10.10 10.31.10.9 init

 
Here are the three scripts I have put together that leave us with a positive result.

OpenVPN config:

Code:

client
dev tun
proto udp
remote swiss.privateinternetaccess.com 1198
resolve-retry infinite
nobind
persist-key
persist-tun
cipher aes-128-cbc
auth sha1
tls-client
remote-cert-tls server
auth-user-pass /etc/openvpn/login.txt
comp-lzo
verb 1
reneg-sec 0
crl-verify crl.rsa.2048.pem
ca ca.rsa.2048.crt
disable-ooc
script-security 2
auth-nocache

up /path/to/upcall

The middle man:

Code:

#! /bin/bash
#Fixed up call for new PIA API

#call the portforward in the background after 30seconds
sleep 30 && /path/to/PIA_portforward.sh &
#check ip
curl ipinfo.io

And finally, the actual port forward script:

Code:

#! /bin/bash

client_id=`head -n 100 /dev/urandom | sha256sum | tr -d " -"`
F_PORT=`curl "http://209.222.18.222:2000/\?client_id=$client_id" 2>/dev/null | awk -F ':' '{ print $2 }'| awk -F '}' '{ print $1 }'`

if [ "$F_PORT" == "" ]; then
    echo "Failure"
    echo $(date) >> /path/to/a/log    
    echo "Failure" >> /path/to/a/log
    echo $client_id >> /path/to/a/log
else
    echo $F_PORT
    echo $(date) >> /path/to/a/log    
    echo $F_PORT >> /path/to/a/log

fi

I stripped this down to bare bones and added a simple log for giggles.
I found that the rest of the script seemed rather unnecessary for our application, and was the part breaking the file prior to calling the port.

So what we have done is, called the port forward script in the background after a 30 second wait, and forced the system to continue to the next line before the sleep timer is even complete.
What this means is OpenVPN basically forgets about this line and moves to the IP check. 

And this is what we see when all is said and done:

Code:

OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb  2 2016
library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08
WARNING: file '/etc/openvpn/login.txt' is group or others accessible
NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
UDPv4 link local: [undef]
UDPv4 link remote: [AF_INET]PIA  SWISS IP:1198
[d641a859e9520a418150e085f9b29c12] Peer Connection Initiated with [AF_INET]PIA_SWISS_IP:1198
TUN/TAP device tun0 opened
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
/sbin/ip link set dev tun0 up mtu 1500
/sbin/ip addr add dev tun0 local 10.31.10.10 peer 10.31.10.9
/etc/openvpn/up_call tun0 1500 1558 10.31.10.10 10.31.10.9 init
Initialization Sequence Completed
{
 "ip": "PIA  SWISS IP",
 "hostname": "No Hostname",
 "city": "",
 "region": "",
 "country": "CH",
 "loc": "47.1449,8.1551",
 "org": "AS51852 Private Layer INC"
}SOMEPORT

Notice where the "Initialization Sequence Completed" line is in relation to the IP info and our port return. 
SUCCESS!! *confetti*

I have tested the sleep timer as low as 5 seconds (mostly out of impatience), although I would not recommend any less than 5 or 10 seconds to cover for lag.

I cannot, unfortunately, confirm anything further on this. I did it on a clean install of Ubuntu 16.04.02-LTS.
I will now leave the rest to you, as I am still a bit weak in the iptables area. 

And I can't wait for it, as the old API keeps breaking my tunnel. Probably why they replaced it in the first place as it is unreliable. 

Let me know how this works out for everyone else. 

Regards, 
        Bob

[drake]

Nice job!
It was indeed the fact that OpenVPN executes the script before the final initialization completes, therefore the port forwarding script was not able to get the port number. With the introduction of a postpone script with a delay of 30 seconds this is indeed resolved. As somebody already mentioned in the PIA forums, but didn't exactly outline how he did it.
For split tunnel I had to add a routing rule that all the calls to the new PIA API are directed over tun0 interface, this ensures that the script is always routed over VPN, done.
I tested in VM with Transmission, and with some modifications it does seam to work. I will fine tune the script with Mike, after I can update both the Transmission and Deluge guides.

Let's hope PIA won't change anything further now.

Again, your help is very much appreciated, you will be certainly credited in the guide and in the script. Just let me know by which name you want to appear

[Lt Hawk]

(Mar 11, 2017, 07:21 PM)drake Wrote: Nice job!
It was indeed the fact that OpenVPN executes the script before the final initialization completes, therefore the port forwarding script was not able to get the port number. With the introduction of a postpone script with a delay of 30 seconds this is indeed resolved. As somebody already mentioned in the PIA forums, but didn't exactly outline how he did it.
For split tunnel I had to add a routing rule that all the calls to the new PIA API are directed over tun0 interface, this ensures that the script is always routed over VPN, done.
I tested in VM with Transmission, and with some modifications it does seam to work. I will fine tune the script with Mike, after I can update both the Transmission and Deluge guides.

Let's hope PIA won't change anything further now.

Again, your help is very much appreciated, you will be certainly credited in the guide and in the script. Just let me know by which name you want to appear

I knew something was up. As I said I'm still weak in ip tables. So mine still isnt working on the split. Would you mind tossing me the rule so I can implement until the guide is updated with a cleaner script?



Sent from my SM-G935V using Tapatalk

[RudyBzh]

Hi all,
Am I missing something or the new script including these informations not yet uploaded (the deluge and transmission portforward guides are still pointing/using old PIA IPA) ?
Thank you so much for your guides and, of course, users helping you solving issues
Regards

[Lt Hawk]

There is a fix in the works for the new api. It's a little 'dirty' right now, Mike and drake are working on the new tut. Patience grasshopper. =) If the old version still works for you, use that for now. The new version won't be much work to change it.

Sent from my SM-G935V using Tapatalk