[Support] binhex - DelugeVPN

[wgstarks]

14 minutes ago, cmrabe said:

Anyone have any ideas on why this isn't working?

Many PIA endpoints no longer work with port forwarding. Try using CA Vancouver.

[cmrabe]

1 hour ago, wgstarks said:

Many PIA endpoints no longer work with port forwarding. Try using CA Vancouver.

I went to PIAs site and downloaded the most recent openVPN files and tried multiple different ones that say they are supported and no luck, same error. just tried CA Vancouver, no luck.

[dukiethecorgi]

CA Vancouver is working, but it took a lot of tries before it would give me a port 

[cmrabe]

3 minutes ago, dukiethecorgi said:

CA Vancouver is working, but it took a lot of tries before it would give me a port 

what do you do to “try”? just restart deluge and open webui? 

[dukiethecorgi]

3 minutes ago, cmrabe said:

what do you do to “try”? just restart deluge and open webui? 

I looked in the logs.  When it connects, it tries 10 times to get a port, then disconnects and tries again.  I took a LONG time before it finally got assigned a port

[Lumpy_BD]

7 hours ago, cmrabe said:

Hello -

I am trying to get Deluge VPN setup with PIA. My end goal is to be using this with Sonarr and Radarr.

I basically followed this video exactly (https://www.youtube.com/watch?v=5AEzm5y2EvM&t=309s) except that I copied over Switzerland certificate instead of Netherlands (I read in the comments Netherlands is no longer supported and checked on PIA that Switz is...)

After I copied the cert files over, in the video he is able to get right into the web GUI, but mine did not start up, I get the error:

 

This site can’t be reached

192.168.1.30 refused to connect.

Try:

Checking the connection

Checking the proxy and the firewall

ERR_CONNECTION_REFUSED.

 

Attaching logs and screenshot of appdata. 

 

Anyone have any ideas on why this isn't working?

deluge logs.rtf 18.41 kB · 3 downloads

I'm having the exact same issue - would appreciate it if someone could point us in the right direction please.

[wgstarks]

2 hours ago, Lumpy_BD said:

I'm having the exact same issue - would appreciate it if someone could point us in the right direction please.

Which ovpn files did you download?

[Lumpy_BD]

1 minute ago, wgstarks said:

Which ovpn files did you download?

I've figured it out - I was using France.ovpn as per the list from the Deluge logs, but reading back in this thread further it appears that's no longer correct either. I switched to CA Vancouver.ovpn and now its all up and running.

[RealIPSec]

Another one in Europe maybe ?

[wgstarks]

26 minutes ago, RealIPSec said:

Another one in Europe maybe ?

You would probably need to try each one to test. I know CA Vancouver is working for me. Others have reported that CA Toronto is also still working. Hopefully at some point PIA will fix their new NextGen servers so that we can resume using them with port forwarding enabled.

[RealIPSec]

De Berlin is working

[gweari]

After the latest update I am no longer able to connect to deluge

 

When i look at the logs this stands out:

WARNING: file 'credentials.conf' is group or others accessible

Edited September 9, 2020 by gweari

[chris_netsmart]

58 minutes ago, RealIPSec said:

De Berlin is working

Which opn files did you download.  Fourth version ?

[binhex]

As you all are probably aware PIA has issues with regards to port forwarding on their legacy network, i have raised a support ticket and i have just gone through the pain of checking each endpoint and thought i would share my email as it details the results, things are slightly better than i thought but still not great!:-

 

Quote

The port forwarding api is NOT 'fully functional' on the legacy network, i am well aware of the 2 minute limit to hit the api and also of the limited locations that support port forwarding, which at the time of writing is as follows (taken from the same api your app uses to get the locations that support port forwarding), the bold indicates the state of each location, tested at the time of this email:-

 

[info] ca-toronto.privateinternetaccess.com        working
[info] ca-montreal.privateinternetaccess.com.     broken, curl responds with exit code 56
[info] ca-vancouver.privateinternetaccess.com.   working
[info] de-berlin.privateinternetaccess.com           broken, curl responds with exit code 56 and exit code 52 on retries
[info] de-frankfurt.privateinternetaccess.com.     broken, curl responds with exit code 52
[info] france.privateinternetaccess.com.             working
[info] czech.privateinternetaccess.com.              broken, curl responds with exit code 52
[info] spain.privateinternetaccess.com.               broken, curl responds with exit code 52
[info] ro.privateinternetaccess.com                     working

[info] israel.privateinternetaccess.com                working

 

So as you can see a lot of the locations are broken right now, an example curl output with verbose flag set is as follows:-

 

for exit code 56:-

 

<console>

[root@232fa9c65bd8 /]# client_id=$(head -n 100 /dev/urandom | sha256sum | tr -d " -")
[root@232fa9c65bd8 /]# curl -v "http://209.222.18.222:2000/?client_id=${client_id}"
*   Trying 209.222.18.222:2000...
* Connected to 209.222.18.222 (209.222.18.222) port 2000 (#0)
> GET /?client_id=1e47fd35b915f9e86670806155dc45ef71c5b0490e0cae6dee6134b63bf5900d HTTP/1.1
> Host: 209.222.18.222:2000
> User-Agent: curl/7.71.0
> Accept: */*
>
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer
[root@232fa9c65bd8 /]# echo $?
56
</console>

 

and for exit code 52:-

 

<console>

[root@232fa9c65bd8 /]# client_id=$(head -n 100 /dev/urandom | sha256sum | tr -d " -")
[root@232fa9c65bd8 /]# curl -v "http://209.222.18.222:2000/?client_id=${client_id}"
*   Trying 209.222.18.222:2000...
* Connected to 209.222.18.222 (209.222.18.222) port 2000 (#0)
> GET /?client_id=deba3a6e69192961c98551279dd6ed08d3df6a9d09c19cd455438694b304eb6d HTTP/1.1
> Host: 209.222.18.222:2000
> User-Agent: curl/7.71.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host 209.222.18.222 left intact
curl: (52) Empty reply from server
[root@232fa9c65bd8 /]# echo $?
52

</console>

 

The above was well within the 2 minute limitation, so the connection reset is not due to that, please can you check and verify on your end as i think you will find the same results.

i will let you know what the response is from the PIA tech support, i am not holding my breath!.

[xxDeadbolt]

Cheers, @binhex! I've found PIA's support to be somewhat useless, but I've not been anywhere near as helpful in the info I gave them, so that may be a reflection on the questions asked & limited details I've been able to provide!😂

[binhex]

ok progress with PIA!, they now at least accept there is an issue, email just received:-

 

Quote

Thank you for providing these details.

 

In testing from this end I had coincidentally used servers that are not experiencing issues. I have since been able to confirm what you report and have notified the server operations team. They will address this as soon as possible. In the mean time, you will need to utilize the shorter list of functioning port forwarding servers you have identified. We are sorry for any inconvenience this may cause.

 

Please let us know if we can assist you with anything else.

 

Regards

Joseph C.
Customer Support Agent

 

[dukiethecorgi]

I got this from PIA today

 

Quote

You can still utilize port forwarding on legacy servers — the method for doing so, and list of available servers are the same, with the exception of a handful of servers that have had the feature temporarily pulled while maintenance is performed. Until the other servers are adjusted, you can still use legacy Toronto, Vancouver, France, Romania, and Israel for successful port forwarding requests with the API.

 

[jedimstr]

Unfortunately I'm hitting the Exit code '56' from all the port-forward capable endpoints on the list.  Tried ca-vancouver and ca-toronto first (I'm usually on ca-toronto anyway) but they've been on a constant retry loop for the last few hours.  None of the others are working either.

[elcapitano]

Wow PIA is really taking their time fixing this

[TheDon]

4 minutes ago, jedimstr said:

Unfortunately I'm hitting the Exit code '56' from all the port-forward capable endpoints on the list.  Tried ca-vancouver and ca-toronto first (I'm usually on ca-toronto anyway) but they've been on a constant retry loop for the last few hours.  None of the others are working either.

I can confirm myself, and a colleague are also getting having an issue with Exit code '56' using ca-vancouver as @jedimstr indicates above.

[wgstarks]

Same here. Tried all the working servers that @binhex listed earlier except ro. I don’t have an ovpn for that one. Finally had to just set strict port forwarding to no to get Deluge running.

[sigfreund]

I have tried all the listed "port forwarding servers" and was able to briefly connect to Toronto only to have that connection fail but when I set Container Variable: STRICT_PORT_FORWARD to no it connects fine and everything seems to be working normally. What is the danger of doing this?  Am I potentially exposing my ip?

[JasonK]

43 minutes ago, sigfreund said:

I have tried all the listed "port forwarding servers" and was able to briefly connect to Toronto only to have that connection fail but when I set Container Variable: STRICT_PORT_FORWARD to no it connects fine and everything seems to be working normally. What is the danger of doing this?  Am I potentially exposing my ip?

No - but the torrent client works best with port forwarding operable.

[acosmichippo]

yep, Toronto is my default but that is giving me exit code 56 as well.

[Hoopster]

CA Vancouver was working for me yesterday but now the WebUI will not even load.

 

Switched to Toronto and now that works for me.

 

There seems to be no rhyme or reason to what works and what does not.

Edited September 9, 2020 by Hoopster