4 minutes ago, worldspawn said:

Yeah, been through that document already, if it were something that simple, I wouldn't be posting here.

 

Your subscription has run out - double check this on the vpn providers website.

-nope, logged into the site today, I have over a year left

 

You have not typed in your username and/or password - do not copy and paste, type it in manually to prevent whitespace issues.

-nope, copy/pasted, manually entered, regenerated credentials, and retried several times, this is not the issue

 

You are using the wrong credentials - ensure the credentials are for openvpn/wireguard, NOT proxy servers etc.

-this is the only 'maybe' here, I can't tell if PIA uses different credentials for wireguard, and if so, I can't find them, but I was getting the error for openvpn as well as wireguard, so either way this isn't the issue for at least one of my attempts and both are having the same issue.

 

Your password contains a character which may cause issues - please ensure it only contains letters a-z (upper case or lower case) and numbers 0-9.

-nope, using credentials generated by PIA, no unusual characters

 

Out of date openvpn config file (ovpn extension) - ensure you download the latest ovpn file from your vpn provider.

-nope, fresh download, files are dated 8-11-20, from the next-gen zip file

 

The vpn provider you have signed up with is having authentication issues - try another endpoint, failing that contact the vpn provider and explain you are having authenticaiton issues when using native openvpn/wireguard clients with AUTH_FAILED shown.

-maybe, but I'd expect a company as big as PIA to have that somewhere public if their connections have been down for days...  Tried about 5 different endpoints, all give the same issue.

 

 

Yoy've said a couple of times now you've 'regenerated credentials': what credentials are you using, your main username/password that you log in to the PIA website with or these?

 

It should be your main username (pXXXXXX) & password you use, not the generated SOCKS ones.

 

2 hours ago, superkrups20056 said:

1) Is the itconfig plugin really necessary for faster speeds like the FAQ says when     

 

    "enable_incoming_tcp": false,
    "enable_incoming_utp": false,
    "enable_outgoing_utp": false,

yes

2 hours ago, superkrups20056 said:

is included in the core.conf file?

no

2 hours ago, superkrups20056 said:

2) Why don't plugins persist between turning on and off the container on Synology DS218+? Scheduler keeps turning off when I restart the container.

see Q4 here:- https://github.com/binhex/documentation/blob/master/docker/faq/delugevpn.md

 

 

1 hour ago, xxDeadbolt said:

Yoy've said a couple of times now you've 'regenerated credentials': what credentials are you using, your main username/password that you log in to the PIA website with or these?

 

It should be your main username (pXXXXXX) & password you use, not the generated SOCKS ones.

 

Hey! That was it, when did that change?  The last several versions I've used required the generated password set.

Hey! That was it, when did that change?  The last several versions I've used required the generated password set.

Honestly, I thought it was always the main log on info. I was never aware of ever being able to use the SOCKS credentials... but I only set up my server at end of March so could’ve been a thing around/before then.


Sent from my iPhone using Tapatalk

18 minutes ago, worldspawn said:

Hey! That was it, when did that change?  The last several versions I've used required the generated password set.

I believe it changed with the new endpoint setup.  I was using the generated user and password, but a few weeks ago in this thread we discovered you need to use the main user and password.  Hopefully others will see these posts. 😉

1 minute ago, xxDeadbolt said:

19 minutes ago, worldspawn said:

Hey! That was it, when did that change?  The last several versions I've used required the generated password set.

Honestly, I thought it was always the main log on info. I was never aware of ever being able to use the SOCKS credentials...

this images has always been based off the pia website credentials, never the socks credentials, but obviously that is up to pia as to what they do or do not accept, perhaps pia now prevent socks credentials being used for wireguard/openvpn authentication? *shrug*, all i can tell you is main website credentials has been working since this image was created.

4 minutes ago, Burizado said:

I believe it changed with the new endpoint setup.  I was using the generated user and password, but a few weeks ago in this thread we discovered you need to use the main user and password.  Hopefully others will see these posts. 😉

thats interesting!, so pia have changed things on their end to prevent socks being used for wireguard/openvpn, that makes sense then, i have enhanced Q16 a little so that hopefully the next person will see my 'Note'.

Thanks for the help and insight, FYI, after I got the web interface going, my downloads weren't connecting, turning off the proxy in the deluge preferences fixed that though.  Proxy should be redundant anyway going through VPN, right?

1 minute ago, worldspawn said:

Proxy should be redundant anyway going through VPN, right?

yes, you will only slow things down when using a proxy over a vpn tunnel, its unnecessary. 

On 10/19/2020 at 9:58 AM, binhex said:

remove everything in the repository field and replace with:-

binhex/arch-delugevpn

 

ok sorry, its me again...apparently my torrent site doesnt like the newest version yet.  Is there somewhere I can go to get the build names to put in to the Repository field?  I'm going to start moving it back a build at a time until I find one it likes again.

I was looking here, but i'm not sure what part of the name I would actually put in the Repository field.  

https://hub.docker.com/r/binhex/arch-delugevpn/builds?page=2

14 minutes ago, coltonc18 said:

was looking here, but i'm not sure what part of the name I would actually put in the Repository field.  

https://hub.docker.com/r/binhex/arch-delugevpn/builds?page=2

If you click the “tags” tab it gives you the build number to use.

Example- binhex/arch-delugevpn:1.3.15_18_ge050905b2-1-04

FYI- These versions do not support the next-gen servers.

Edited October 22, 20205 yr by wgstarks

Just now, wgstarks said:

If you click the “tags” tab it gives you the build number to use.

FYI- These versions do not support the next-gen servers.

thanks, i'll play around with it and see what I can get to work.

13 hours ago, binhex said:

ive seen a couple of people report this but i have been unable to replicate so unsure as to the cause, you could try another endpoint and see if that helps.

I am also getting this. I tried both US Atlanta and US Florida, neither worked. What endpoint(s) have you tested that work for you?

 

[warn] Unable to successfully download PIA json payload from URL 'https://10.13.112.1:19999/getSignature' using token

 

Thanks guys. Some final questions. Is there a way to:

 

1) Disable the deluge password login

2) Get a Mobile UI working

3) Use start and stop times x:15 and x:45 rather than just the x:00 on Scheduler?

My Internet connection went down for six hours.  When it came back, DelugeVPN didn't re-establish the VPN automatically.

On restarting the container, the VPN came up quickly and started transferring data again.

 

The log file shows lots of repeated:

2020-10-23 09:32:19,037 DEBG 'watchdog-script' stdout output:
[info] DNS failure, creating file '/tmp/dnsfailure' to indicate failure...

2020-10-23 09:32:19,061 DEBG 'watchdog-script' stdout output:
[warn] VPN IP not detected, VPN tunnel maybe down

2020-10-23 09:32:21,053 DEBG 'start-script' stdout output:
[info] Sending 'down' command to WireGuard due to dns failure...
[info] Attempting to bring WireGuard interface 'down'...

2020-10-23 09:32:21,068 DEBG 'start-script' stderr output:
Warning: `/config/wireguard/wg0.conf' is world accessible

2020-10-23 09:32:21,071 DEBG 'start-script' stderr output:
wg-quick: `wg0' is not a WireGuard interface

2020-10-23 09:32:21,071 DEBG 'start-script' stdout output:
[info] WireGuard interface stopped

2020-10-23 09:33:44,203 DEBG 'watchdog-script' stdout output:
[info] DNS failure, creating file '/tmp/dnsfailure' to indicate failure...

2020-10-23 09:33:44,227 DEBG 'watchdog-script' stdout output:
[warn] VPN IP not detected, VPN tunnel maybe down

2020-10-23 09:33:51,077 DEBG 'start-script' stdout output:
[info] Sending 'down' command to WireGuard due to dns failure...

2020-10-23 09:33:51,077 DEBG 'start-script' stdout output:
[info] Attempting to bring WireGuard interface 'down'...

2020-10-23 09:33:51,092 DEBG 'start-script' stderr output:
Warning: `/config/wireguard/wg0.conf' is world accessible

2020-10-23 09:33:51,094 DEBG 'start-script' stderr output:
wg-quick: `wg0' is not a WireGuard interface

2020-10-23 09:33:51,095 DEBG 'start-script' stdout output:
[info] WireGuard interface stopped

 

6 hours ago, PeterB said:

My Internet connection went down for six hours.  When it came back, DelugeVPN didn't re-establish the VPN automatically.

On restarting the container, the VPN came up quickly and started transferring data again.

 

The log file shows lots of repeated:

2020-10-23 09:32:19,037 DEBG 'watchdog-script' stdout output:
[info] DNS failure, creating file '/tmp/dnsfailure' to indicate failure...

2020-10-23 09:32:19,061 DEBG 'watchdog-script' stdout output:
[warn] VPN IP not detected, VPN tunnel maybe down

2020-10-23 09:32:21,053 DEBG 'start-script' stdout output:
[info] Sending 'down' command to WireGuard due to dns failure...
[info] Attempting to bring WireGuard interface 'down'...

2020-10-23 09:32:21,068 DEBG 'start-script' stderr output:
Warning: `/config/wireguard/wg0.conf' is world accessible

2020-10-23 09:32:21,071 DEBG 'start-script' stderr output:
wg-quick: `wg0' is not a WireGuard interface

2020-10-23 09:32:21,071 DEBG 'start-script' stdout output:
[info] WireGuard interface stopped

i think i see the issue @PeterB i will do some testing and if it looks good will release a new image with the fix.

5 minutes ago, binhex said:

i think i see the issue @PeterB i will do some testing and if it looks good will release a new image with the fix.

Thank you, sir!

15 hours ago, LumberJackGeek said:

I am also getting this. I tried both US Atlanta and US Florida, neither worked. What endpoint(s) have you tested that work for you?

 

[warn] Unable to successfully download PIA json payload from URL 'https://10.13.112.1:19999/getSignature' using token

 

Bump, still not having any luck with the next gen stuff  

1 hour ago, LumberJackGeek said:

Bump, still not having any luck with the next gen stuff  

please do this:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md

1 hour ago, binhex said:

please do this:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md

Thanks! See attached.

supervisord.log

55 minutes ago, LumberJackGeek said:

Thanks! See attached.

supervisord.log 99.79 kB · 2 downloads

from your log:-

[warn] PIA endpoint 'us-atlanta.privacy.network' is not in the list of endpoints that support port forwarding, DL/UL speeds maybe slow
[info] Please consider switching to one of the endpoints shown below

so either set STRICT_PORT_FORWARD to 'no' or choose one of the dozens of other endpoints shown in your log that do support port forwarding.

43 minutes ago, binhex said:

from your log:-

[warn] PIA endpoint 'us-atlanta.privacy.network' is not in the list of endpoints that support port forwarding, DL/UL speeds maybe slow
[info] Please consider switching to one of the endpoints shown below

so either set STRICT_PORT_FORWARD to 'no' or choose one of the dozens of other endpoints shown in your log that do support port forwarding.

Ahh so those endpoints do not support port forwarding? I suspect that's the issue others are hitting. I assumed (wrongly) since it was in that next-gen pack that meant it supported port forward Thanks for the info!

26 minutes ago, LumberJackGeek said:

Ahh so those endpoints do not support port forwarding? I suspect that's the issue others are hitting. I assumed (wrongly) since it was in that next-gen pack that meant it supported port forward Thanks for the info!

Here's the list of what supports port forwarding in the nextgen servers:

 

[info] List of PIA endpoints that support port forwarding:-

2020-10-23 12:26:12,506 DEBG 'start-script' stdout output:
[info] al.privacy.network
[info] ad.privacy.network
[info] austria.privacy.network
[info] brussels.privacy.network
[info] ba.privacy.network

2020-10-23 12:26:12,506 DEBG 'start-script' stdout output:
[info] sofia.privacy.network
[info] czech.privacy.network
[info] denmark.privacy.network
[info] ee.privacy.network
[info] fi.privacy.network
[info] france.privacy.network
[info] de-berlin.privacy.network
[info] de-frankfurt.privacy.network
[info] gr.privacy.network
[info] hungary.privacy.network
[info] is.privacy.network
[info] ireland.privacy.network
[info] man.privacy.network
[info] italy.privacy.network
[info] lv.privacy.network
[info] liechtenstein.privacy.network
[info] lt.privacy.network
[info] lu.privacy.network
[info] mk.privacy.network
[info] malta.privacy.network
[info] md.privacy.network
[info] monaco.privacy.network
[info] montenegro.privacy.network

2020-10-23 12:26:12,506 DEBG 'start-script' stdout output:
[info] nl-amsterdam.privacy.network
[info] no.privacy.network
[info] poland.privacy.network
[info] pt.privacy.network
[info] ro.privacy.network
[info] rs.privacy.network
[info] sk.privacy.network
[info] spain.privacy.network
[info] sweden.privacy.network
[info] swiss.privacy.network
[info] ua.privacy.network
[info] uk-london.privacy.network
[info] uk-southampton.privacy.network
[info] uk-manchester.privacy.network
[info] bahamas.privacy.network
[info] ca-vancouver.privacy.network
[info] ca-ontario.privacy.network
[info] ca-toronto.privacy.network
[info] ca-montreal.privacy.network
[info] greenland.privacy.network
[info] mexico.privacy.network
[info] panama.privacy.network
[info] ar.privacy.network
[info] br.privacy.network

2020-10-23 12:26:12,506 DEBG 'start-script' stdout output:
[info] venezuela.privacy.network
[info] yerevan.privacy.network
[info] cambodia.privacy.network
[info] china.privacy.network
[info] cyprus.privacy.network
[info] georgia.privacy.network
[info] hk.privacy.network
[info] in.privacy.network
[info] israel.privacy.network
[info] japan.privacy.network
[info] kazakhstan.privacy.network
[info] philippines.privacy.network
[info] qatar.privacy.network
[info] saudiarabia.privacy.network
[info] sg.privacy.network
[info] srilanka.privacy.network
[info] taiwan.privacy.network
[info] tr.privacy.network
[info] ae.privacy.network
[info] vietnam.privacy.network

2020-10-23 12:26:12,506 DEBG 'start-script' stdout output:
[info] aus-perth.privacy.network
[info] au-sydney.privacy.network
[info] aus-melbourne.privacy.network
[info] nz.privacy.network
[info] dz.privacy.network
[info] egypt.privacy.network
[info] morocco.privacy.network
[info] nigeria.privacy.network
[info] za.privacy.network

 

I'm also having trouble accessing delugevpn webgui outside local. Running unraid and using wireguard to VPN into server from remote. Used to work prior to switching to wireguard. Attached is log. It doesn't appear I'm being affected by Q4.

 

https://pastebin.com/8G6TPcvx

 

On 10/22/2020 at 8:07 AM, binhex said:

ive seen a couple of people report this but i have been unable to replicate so unsure as to the cause, you could try another endpoint and see if that helps.

I was testing for hours today; almost tried all of the endpoints.... And then it hit me. What if I add the VPN_USER and VPN_PASS environment variables back (although the credentials.conf is there and set in the ovpn file). And *bam* no more "Unable to successfully download PIA json to generate token from URL". Apparently the environment variables are mandatory now. It does still work without them on the legacy endpoints.

 

Is this how it's intended to work? I can imaging more people banging their heads because of this change... Glad it's working now, though.

Edited October 23, 20205 yr by BakedPizza