[Support] binhex - DelugeVPN


Recommended Posts

Note that I got past the WebUI issue by doing the following

 

"The alternative to this is to set env var 'STRICT_PORT_FORWARD' value to 'no', this will then skip any port forwarding and allow you to connect to ANY PIA endpoint independent of whether it supports port forwarding or not (not recommended)."

 

However, the original issue is still there. At this point I'm wondering if its an ISP policy causing port forwarding issues.

Link to comment

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?

Screen Shot 2020-09-08 at 7.21.11 PM.png

deluge logs.rtf

Link to comment
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.

Screen Shot 2020-09-08 at 9.04.18 PM.png

Link to comment
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?

Screen Shot 2020-09-08 at 7.21.11 PM.png

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.

Link to comment
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.

Link to comment
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.

Link to comment

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!.

  • Like 1
  • Thanks 2
Link to comment

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

 

  • Like 1
  • Thanks 4
Link to comment

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.

 

Link to comment
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.

Link to comment

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?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.