[Support] binhex - DelugeVPN


8725 posts in this topic Last Reply

Recommended Posts

Trying to find out if I'm max speeds or if I'm doing something wrong, I've read all the documentation I've come across on github. I have symmetrical gigabit and I'm maxing out at 80MiB/s, which is fine, but I've seen people saying they're getting close to 300 also with gigabit and PIA like I have. Any ideas? I tried wireguard on a few different servers but that's topping out closer to 50. Not getting any log errors.

Link to post
  • Replies 8.7k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

OK guys, multi remote endpoint support is now in for this image please pull down the new image (this change will be rolled out to all my vpn images shortly).   What this means is that the im

There has been an issue raised on GitHub related to tracker announce request IP leakage under certain circumstances, after careful review of iptables i have tightened up the rules to prevent this. A n

I wanted to summarize how I got Mullvad working with DelugeVPN as I had to piece together several "solutions" from different comments in this thread and there was some incorrect info; likely old.

Posted Images

Trying to find out if I'm max speeds or if I'm doing something wrong, I've read all the documentation I've come across on github. I have symmetrical gigabit and I'm maxing out at 80MiB/s, which is fine, but I've seen people saying they're getting close to 300 also with gigabit and PIA like I have. Any ideas? I tried wireguard on a few different servers but that's topping out closer to 50. Not getting any log errors.

I think you’re mixing Bytes and bits there. 80MiB/s is pretty close to the maximum practical speed of a 1Gb/s line.


Sent from my iPhone using Tapatalk
Link to post
Bumping this back up not sure if any of you have similar issues

Have a look at the WireGuard section here: https://github.com/binhex/arch-delugevpn

Looks like you are missing
—sysctl="net.ipv4.conf.all.src_valid_mark=1" 



Also, from your volume mappings it looks like you’re running this on a Windows host? I know wireguard relies on support in the Linux kernel, so not sure if that would cause problems when running on Windows.


Sent from my iPhone using Tapatalk

Link to post

Hello erveryone,

 

still getting the error AUTH_Failed. 

I use the credentials to login into the webinterface of pia the p000000 one.

I tried every fix I found here or via google. Even tried it on my pc itself it wont connect.

Can someone please tell me what Iam doing wrong here. Also treid wireguard which says: 

 

"

2020-12-05 13:06:40,872 DEBG 'start-script' stderr output:
parse error: Invalid numeric literal at line 4, column 0

2020-12-05 13:06:41,109 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token from URL 'https://212.102.34.129/authv3/generateToken'
[info] Retrying in 10 secs...
"

 

Tried it for days now please help. Oh and btw the pia support does not answer.

Link to post
3 hours ago, Seraph91P said:

Hello erveryone,

 

still getting the error AUTH_Failed. 

I use the credentials to login into the webinterface of pia the p000000 one.

I tried every fix I found here or via google. Even tried it on my pc itself it wont connect.

Can someone please tell me what Iam doing wrong here. Also treid wireguard which says: 

 

"

2020-12-05 13:06:40,872 DEBG 'start-script' stderr output:
parse error: Invalid numeric literal at line 4, column 0

2020-12-05 13:06:41,109 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token from URL 'https://212.102.34.129/authv3/generateToken'
[info] Retrying in 10 secs...
"

 

Tried it for days now please help. Oh and btw the pia support does not answer.

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. 

 

Link to post

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

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

Link to post

@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+? 

 

 

Link to post

@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?

Link to post
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

 

Link to post
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 by binhex
Link to post

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 by binhex
Link to post

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.

Link to post

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 by bwobba
Wording
Link to post

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?

Screen Shot 2020-12-06 at 9.46.05 PM.png

Screen Shot 2020-12-06 at 9.48.13 PM.png

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

Screen Shot 2020-12-06 at 9.46.05 PM.png

Screen Shot 2020-12-06 at 9.48.13 PM.png

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

Link to post
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!

Link to post
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

Link to post

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.