I give up with this container. I use PIA finally got it working but now the speeds are unbelievably slow. Luck to get 1mb on a 500mb/s connection. Tried to change the verb # as I saw on here now when I pull the logs up it freezes the whole server. Guess Nzbts only for me. I would include the logs but ...

On 11/30/2020 at 10:14 PM, binhex said:

i would suspect Deluge, even if the connection was dropped by PIA, it would be re-created automatically by my watchdog scripts.

So I can consistently get this no connectivity situation to occur now, all I need to do is schedule a pause.

BUT, if I schedule it near the end of the hour, or I change the schedule midway through the hour (so it pauses for less than an hour), all connectivity resumes normally.

 

I really believe the connection is being dropped on PIA side due to inactivity, but is staying open (or similar) on the docker side so watchdog scripts aren't kicking in.  If there is a way I can check or log this theory, let me know..

@Liam_Galt, @Seraph91P

I joined for a similar reason to move from not being connectable to being connectable due to PF. Honestly ill give PIA a week to fix it if they dont ill ask for a refund. Hopefully they'll fix whatever is stopping the auth from occurring. Had the same idea lets use wireguard but have the same line 4 error. I have tried all the checklists throughout the thread with no love.

 

Is there a log i could provide around the wireguard line 4 error? I suspect its to go with auth too but no way to be sure at the moment. I suspect. Its only a 2 element json reply not the expected 4+? 

 

 

Yeah, just signed up with PIA today and getting most of the same isseus posted in the last 24 hours.

 - Locking up web pages

 - Recived controll message: AUTH_Failed

 - PIA working on all other devices.

 

How confident is everyone this is a PIA issue?

@chris.warren.melb Given most new PIA users who are using this configuration are having issues. Seems more then coincidence. For example my old VPN provider is still working albeit without PF'ing which is why the move to PIA was done.

 

I believe @binhex has confirmed above he and others in the post are able to log into their existing PIA accounts with PF both on OpenVPN and Wireguard with no issue.

 

I have used it in both binhex-delugevpn and binhex-qbittorrentvpn (not to discuss that here)  and the behaviour described above is identical. If someone can come up with another suggestion i am all ears to try it.

28 minutes ago, chris.warren.melb said:

Yeah, just signed up with PIA today and getting most of the same isseus posted in the last 24 hours.

 - Locking up web pages

 - Recived controll message: AUTH_Failed

 - PIA working on all other devices.

 

How confident is everyone this is a PIA issue?

23 hours ago, Liam_Galt said:

Yeah I've been asking support and they just tell me to make sure my credentials are correct. You're definitely not the only one. I think this is on their server side, credentials aren't propagating correctly or something. You can follow my Reddit post for some other info, but there's not anything really helpful there, either lol. 

 

Tried now everything from that post aswell. 

No luck so far atleast I now know how to use the cert file and not the integrated one.

But still AUTH_FAILED. As far as I can read it it literaly says that my credentials are wrong. 
I checked now many times changed the password 3 times. I use the correct ones.

Dunno what to do probaply refund is the only option.

 

2020-12-06 15:16:57 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2020-12-06 15:16:57 VERIFY EKU OK
2020-12-06 15:16:57 VERIFY OK: depth=0, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=frankfurt410, name=frankfurt410
2020-12-06 15:16:57 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
2020-12-06 15:16:57 [frankfurt410] Peer Connection Initiated with [AF_INET]212.102.57.191:1198
2020-12-06 15:16:58 AUTH: Received control message: AUTH_FAILED
2020-12-06 15:16:58 SIGUSR1[soft,auth-failure] received, process restarting
2020-12-06 15:17:05 ERROR: could not read Auth username/password/ok/string from management interface
2020-12-06 15:17:05 Exiting due to fatal error

 

I just want to chime in and say that I'm running PIA with WireGuard as per the instructions, and it works just fine. 👍

20 hours ago, tjb_altf4 said:

I really believe the connection is being dropped on PIA side due to inactivity, but is staying open (or similar) on the docker side so watchdog scripts aren't kicking in.

there are two mechanism's i have in place to prevent this, firstly the openvpn client has its own built in ping mechanism, if it cannot ping the remote end of the vpn tunnel then it will auto reconnect, and if that fails i have a backup mechanism where i do a dns lookup of www.google.com every 30 secs, if the connection is dropped this will fail causing the openvpn client process to be killed and re-created, so its unlikely that the connection is dropping without being noticed by either of these mechanism's, possible but highly unlikely :-).

 

Quote

If there is a way I can check or log this theory, let me know..

simply get to the containers console and run a continuous ping, if you see the ping drop then you know the connection was severed, if this happens you should see the connection re-stablished after a short period, normally 30 secs.

Edited December 6, 20205 yr by binhex

hmm ok guys i see a lot of chat about AUTH_FAILED, please can you detail which endpoints you are attempting connection to, i want to verify with a completely clean container that there are no issues on my side, i do believe at present this is all PIA, as this reddit post seems to indicate, new accounts are balked on authentication for PIA:-

https://www.reddit.com/r/PrivateInternetAccess/comments/k60kon/openvpn_auth_failed_issues/?ref=share&ref_source=embed&utm_content=body&utm_medium=post_embed&utm_name=50ba78c8d6d4483ebc726ab1240d3fb9&utm_source=embedly&utm_term=k60kon

 

just to be 100% clear here, i am using a wireguard connection to PIA and its stable for me, uptime on the container is currently 7 days and its still has a working PF and dl/ul are fine.

 

edit - interestingly, a completely different docker image developer has the same AUTH_FAILED issue reported by a end user for PIA, that points the finger of blame quite firmly at PIA:- 

https://github.com/haugene/docker-transmission-openvpn/issues/1590

Edited December 6, 20205 yr by binhex

I don't want to jinx it, but I have been up successfully for months after switching to the Wireguard setup.  My container does restart nightly for backups, so it is restarted often and still works.

 

I will go find some wood to touch now.  If I come back tomorrow stating it is not working, I will only blame myself.

Hi @binhex,

I believe the reddit post reflects a number of the users already in this thread. As we can all see PIA isnt answering the thread with little more then check your password which is weak.

 

When using the wireguard method,

I have not been able to get it to generate the wireguard config thus no endpoint that im aware of is actually set as yet, i.e. should default to Netherlands;

 

2020-12-07 09:20:05,192 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token from URL 'https://143.244.43.129/authv3/generateToken'
[info] Retrying in 10 secs...

2020-12-07 09:20:15,218 DEBG 'start-script' stderr output:
parse error: Invalid numeric literal at line 4, column 0

 

When using the OpenVPN method;

Each of the following default PIA .opvn files have been tried in conjunction with ca.rsa.2048.crt & crl.rsa.2048.pem.

1. netherlands.opvn (nl-amsterdam.privacy.network)

2. au_sydney.opvn (au-sydney.privacy.network)

3. ca_montreal.opvn (ca-montreal.privacy.network)

 

All presented with the AUTH_FAILED issue. With the standard associated cipher warning as i have used stock standard PIA opvn files;

2020-12-07 09:33:32 DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'aes-128-cbc' to --data-ciphers or change --cipher 'aes-128-cbc' to --data-ciphers-fallback 'aes-128-cbc' to silence this warning.

 

 

I have noticed something new an Invalid prefix issue not sure where its cropping up from heres the extract of the log;

2020-12-07 09:33:32,086 DEBG 'start-script' stdout output:
[info] Docker network defined as 172.17.0.0/16

2020-12-07 09:33:32,088 DEBG 'start-script' stdout output:
[info] Adding 10.1.1.1/24 as route via docker eth0

2020-12-07 09:33:32,089 DEBG 'start-script' stderr output:
Error: Invalid prefix for given prefix length.

2020-12-07 09:33:32,089 DEBG 'start-script' stdout output:
[info] ip route defined as follows...

 

Any help would be amazing.

 

KR,

BW

Edited December 6, 20205 yr by bwobba
Wording

Started having a strange issue out of the blue, the docker seems to no longer be respecting the set /data path, which I've had mapped to an unassigned disk for ever. Now downloads are downloading into the appdata folder for the docker??  Any ideas?

8 minutes ago, Magaman said:

which I've had mapped to an unassigned disk for ever.

There have been a lot of changes for mount points in the UD plugin recently (especially remote mount points). Are you sure the path you set is still valid?

40 minutes ago, Magaman said:

Started having a strange issue out of the blue, the docker seems to no longer be respecting the set /data path, which I've had mapped to an unassigned disk for ever. Now downloads are downloading into the appdata folder for the docker??  Any ideas?

data is not the same path as /data. Add the leading slash and you should be fine.

4 minutes ago, jonathanm said:

data is not the same path as /data. Add the leading slash and you should be fine.

 

24 minutes ago, wgstarks said:

There have been a lot of changes for mount points in the UD plugin recently (especially remote mount points). Are you sure the path you set is still valid?

 

Thank you both, A I feel like an idiot removing that leading slash, been fighting with the latest Radarr dockers complaining about the mappings... Well based off the suggestion to look at UD, I found it out dated, updated and all is back to normal!

There looks to be a suggestion to try the latest version of OpenVPN 2.4.x. I am no docker pro but am happy to test if someone can tell me what command to include to pull OpenVPN 2.4 instead of OpenVPN 2.5 to rule in or out of the issue.

10 hours ago, bwobba said:

I have noticed something new an Invalid prefix issue not sure where its cropping up from heres the extract of the log;

i would need to see a full log to debug that, please do the following:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md

Hi, I have done it for both scenarios, OpenVPN and wireguard. Please see attachments. Let me know if i can provide anything else.

supervisord-wireguard.log supervisord-OpenVPN.log

14 minutes ago, bwobba said:

Hi, I have done it for both scenarios, OpenVPN and wireguard. Please see attachments. Let me know if i can provide anything else.

supervisord-wireguard.log 51.52 kB · 1 download supervisord-OpenVPN.log 279.16 kB · 1 download

as i suspected the issue is badly configured LAN_NETWORK, taken from your log:-

 

2020-12-07 20:39:45.117865 [info] LAN_NETWORK defined as '10.1.1.1/24'

see Q4 here on how to correctly configure it:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

13 hours ago, binhex said:

hmm ok guys i see a lot of chat about AUTH_FAILED, please can you detail which endpoints you are attempting connection to, i want to verify with a completely clean container that there are no issues on my side, i do believe at present this is all PIA, as this reddit post seems to indicate, new accounts are balked on authentication for PIA:-

https://www.reddit.com/r/PrivateInternetAccess/comments/k60kon/openvpn_auth_failed_issues/?ref=share&ref_source=embed&utm_content=body&utm_medium=post_embed&utm_name=50ba78c8d6d4483ebc726ab1240d3fb9&utm_source=embedly&utm_term=k60kon

 

just to be 100% clear here, i am using a wireguard connection to PIA and its stable for me, uptime on the container is currently 7 days and its still has a working PF and dl/ul are fine.

 

edit - interestingly, a completely different docker image developer has the same AUTH_FAILED issue reported by a end user for PIA, that points the finger of blame quite firmly at PIA:- 

https://github.com/haugene/docker-transmission-openvpn/issues/1590

PIA Support finally answered. Treid alot with them nothing seems to have worked. Tested alot of connections like all over the world nothing seems to work.

They also mentioned to use OpenVpn 2.4.9 since I tried to use it from my pc also no luck. Wireguard does not work either Times out or Line 4 error.

5 minutes ago, Seraph91P said:

or Line 4 error.

if by this you mean the following error then that can be ignored, its caused by PIA being dumb and shoving non json content into the respaonse from their api which jq then trips over:-

2020-12-06 20:52:43,603 DEBG 'start-script' stderr output:
parse error: Invalid numeric literal at line 4, column 0

 

33 minutes ago, binhex said:

as i suspected the issue is badly configured LAN_NETWORK, taken from your log:-

 

2020-12-07 20:39:45.117865 [info] LAN_NETWORK defined as '10.1.1.1/24'

see Q4 here on how to correctly configure it:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

  Cheers!, I have the correct setting in my live container using qbit instead... Overlooked it, removes the warning but the same final errors occur. i.e. Failed Auth / numeric literal at line 4

1 minute ago, bwobba said:

Failed Auth / numeric literal at line 4

those are two separate issues, AUTH_FAILED is an ongoing issue that looks to be related to PIA and new accounts (no fix yet), numeric literal as shown in my post above is a non issue caused by PIA's API containing non json data (it can be ignored).

2 minutes ago, binhex said:

those are two separate issues, AUTH_FAILED is an ongoing issue that looks to be related to PIA and new accounts (no fix yet), numeric literal as shown in my post above is a non issue caused by PIA's API containing non json data (it can be ignored).

Yes correct two issues as im testing both wireguard and openvpn both are not working.

OpenVPN as you mention look to be PIA with new accounts (me yaya!).

Wireguard gives me the numeric literal at line 4 (supervisord-wireguard log attached earlier). Then fails to generate the token required for auth. Which then loops continuously. 

 

Lucky for me i can use my current VPN w/o PF but sucks as it seems to be PIA.

 

I've never had an issue with your great containers! Thanks for all the hard work.

 

5 hours ago, binhex said:

if by this you mean the following error then that can be ignored, its caused by PIA being dumb and shoving non json content into the respaonse from their api which jq then trips over:-

2020-12-06 20:52:43,603 DEBG 'start-script' stderr output:
parse error: Invalid numeric literal at line 4, column 0

 

Yes refers to this:

 

2020-12-07 17:02:00,691 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token from URL 'https://212.102.35.1/authv3/generateToken'
[info] Retrying in 10 secs...

2020-12-07 17:02:10,724 DEBG 'start-script' stderr output:
parse error: Invalid numeric literal at line 4, column 0

2020-12-07 17:02:10,982 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token from URL 'https://212.102.35.1/authv3/generateToken'
[info] Retrying in 10 secs...