[Support] binhex - DelugeVPN

[binhex]

42 minutes ago, craigr said:

If you have time to answer, has every version you have released done this?

yep, PIA requires a poll to keep the port open and has done for some time (years).

[binhex]

45 minutes ago, craigr said:

Also binhex, I have been meaning to ask, is your Q&A number 21 and 22 up to date?  I can't get rid of the cypher error for example.

 

2024-07-23 23:49:40,899 DEBG 'start-script' stdout output:
2024-07-23 23:49:40 DEPRECATED OPTION: --cipher set to 'aes-256-gcm' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 
2024-07-23 23:49:40 WARNING: file 'credentials.conf' is group or others accessible

 

well strictly speaking its not an error, its a deprecation ;-), not sure of the fix for that off the top of my head tbh.

[binhex]

52 minutes ago, craigr said:

Also binhex, I have been meaning to ask, is your Q&A number 21 and 22 up to date?  I can't get rid of the cypher error for example.

 

2024-07-23 23:49:40,899 DEBG 'start-script' stdout output:
2024-07-23 23:49:40 DEPRECATED OPTION: --cipher set to 'aes-256-gcm' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 
2024-07-23 23:49:40 WARNING: file 'credentials.conf' is group or others accessible

 

try this, open your openvpn config file, change this line:-

cipher aes-256-gcm

to:-

data-ciphers AES-256-GCM

taken from here:- https://discuss.freedombox.org/t/solved-openvpn-depreciated-cipher/2625

[binhex]

7 hours ago, Penurious said:

No worries, I appreciate you taking a look. I might have to try a new vendor. My subscription with IPVanish is about to expire end of August anyway.

PIA are still doing OK in my opinion, cheap and more importantly have a track record for 0 logging, their latest transparency report is out:- 

 

[jermcel]

Having issues with PIA Port Forwarding OVPN's.  They just stopped working in the last few days and I don't know why.  I was using CA Toronto. 

I queried the API to get valid port forward endpoints using the following:

 

$ curl -s https://serverlist.piaservers.net/vpninfo/servers/v6 | head -n1 | jq -r '.regions | .[] | select(.port_forward) | .name' | sort

 

I have tried every other Canada endpoint as well as Netherlands, Berlin and Mexico, but I get this in the log each time.

 

2024-07-26 08:11:36,228 DEBG 'start-script' stdout output:
[info] Script started to assign incoming port for 'pia'
[info] Port forwarding is enabled
[info] Checking endpoint 'de-berlin.privacy.network' is port forward enabled...

2024-07-26 08:11:37,275 DEBG 'start-script' stdout output:
[info] PIA endpoint 'de-berlin.privacy.network' is NOT in the list of endpoints that support port forwarding shown below:-

2024-07-26 08:11:38,324 DEBG 'start-script' stdout output:
[info] List of PIA endpoints that support port forwarding:-
[info] Script finished to assign incoming port

 

Am I missing something that has changed at PIA?  Can someone point me in the right direction?

[strike]

@binhex Do you use tailscale by any chance, or know the solution to this? It seems like when magic dns is enabled in tailscale I get no name resolution. When I disable magic dns it works. Delugevpn runs on custom bridge if that helps. I want to be able to use magic dns AND run containers on my custom bridge. When magic dns is on I just get this in the log:

 

2024-07-27 17:45:20.608155 [info] Host is running unRAID
2024-07-27 17:45:20.619784 [info] System information Linux 240d22a544ac 6.1.99-Unraid #1 SMP PREEMPT_DYNAMIC Tue Jul 16 10:06:03 PDT 2024 x86_64 GNU/Linux
2024-07-27 17:45:20.632875 [info] SHARED_NETWORK not defined (via -e SHARED_NETWORK), defaulting to 'no'
2024-07-27 17:45:20.645890 [info] PUID defined as '99'
2024-07-27 17:45:20.663483 [info] PGID defined as '100'
2024-07-27 17:45:20.688469 [warn] UMASK not defined (via -e UMASK), defaulting to '000'
2024-07-27 17:45:20.705787 [info] Permissions already set for '/config'
2024-07-27 17:45:20.719737 [info] Deleting files in /tmp (non recursive)...
2024-07-27 17:45:20.741498 [info] VPN_ENABLED defined as 'yes'
2024-07-27 17:45:20.755572 [warn] VPN_CLIENT not defined (via -e VPN_CLIENT), defaulting to 'openvpn'
2024-07-27 17:45:20.769771 [info] VPN_PROV defined as 'airvpn'
2024-07-27 17:45:20.786684 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/AirVPN_Netherlands_UDP-443-Entry3_linux.ovpn
2024-07-27 17:45:20.818304 [info] VPN remote server(s) defined as 'nl3.vpn.airdns.org,'
2024-07-27 17:45:20.831414 [info] VPN remote port(s) defined as '443,'
2024-07-27 17:45:20.844451 [info] VPN remote protcol(s) defined as 'udp,'
2024-07-27 17:45:20.861209 [info] VPN_DEVICE_TYPE defined as 'tun0'
2024-07-27 17:45:20.877452 [info] VPN_OPTIONS not defined (via -e VPN_OPTIONS)
2024-07-27 17:45:20.890771 [info] NAME_SERVERS defined as '84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1'
2024-07-27 17:45:20.904216 [debug] iptables default policies available, setting policy to drop...
2024-07-27 17:45:20.919792 [debug] ip6tables default policies available, setting policy to drop...
2024-07-27 17:45:24.947585 [debug] Having issues resolving name 'nl3.vpn.airdns.org', sleeping before retry...
2024-07-27 17:45:33.980620 [debug] Having issues resolving name 'nl3.vpn.airdns.org', sleeping before retry...

 

[binhex]

26 minutes ago, strike said:

Do you use tailscale by any chance

sorry no, what is 'magic dns'?

[strike]

3 minutes ago, binhex said:

sorry no, what is 'magic dns'?

I just found the solution myself, working now. Magic dns is an option in tailscale that let you use hostnames instead of IP adresses to access your devices in an tailscale network when remote.  In other words, it works just as you where on that particular network. If somebody else stumbles upon this. The solution was to run 

tailscale up --accept-dns=false

 

When set to false it will use your local dns and if set to true it will use tailescale dns servers and overwrite /etc/resolv.conf which get copied to all freshly started containers from the host.

 

I just tested this now and both magic dns (on the other tailscale clients) and local dns on the unraid server is now working. I suspect magic dns will not work on the server when I have this set to false. But it isn't really needed on the server as all the clients connect to the server and not the other way around.

[craigr]

On 7/24/2024 at 10:41 AM, binhex said:

well strictly speaking its not an error, its a deprecation ;-), not sure of the fix for that off the top of my head tbh.

 

On 7/24/2024 at 10:50 AM, binhex said:

try this, open your openvpn config file, change this line:-

cipher aes-256-gcm

to:-

data-ciphers AES-256-GCM

taken from here:- https://discuss.freedombox.org/t/solved-openvpn-depreciated-cipher/2625

 

Thanks for trying 🙂

 

2024-07-28 03:05:45,045 DEBG 'start-script' stdout output:
2024-07-28 03:05:45 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.

 

It just kinda cracks me up that it's the same "deprecation" message

 

"Computer says noooo... cough"

Edited July 28 by craigr

[craigr]

On 7/24/2024 at 10:41 AM, binhex said:

well strictly speaking its not an error, its a deprecation ;-), not sure of the fix for that off the top of my head tbh.

 

What's crazy is PIA doesn't seem to allow any cipher to be defined due to their own errors.

[EDACerton]

On 7/27/2024 at 2:39 PM, strike said:

I just tested this now and both magic dns (on the other tailscale clients) and local dns on the unraid server is now working. I suspect magic dns will not work on the server when I have this set to false. But it isn't really needed on the server as all the clients connect to the server and not the other way around.

This is correct on both counts -- setting accept-dns to false will prevent MagicDNS from working on the server, but that's almost never needed.

 

My usual recommendation for anyone running Tailscale is to turn MagicDNS off for the Unraid server unless you have a specific need to use it.

[heisenberg06]

Hello,

I've been switching from surfshark to ProtonVPN on my delugeVPN container (especially to enable port forwarding and seed properly), and i believe i configured everything as described in the help page Q31/A31 from vpn.md in github.

In my deluge configuration under Network,

 

• in the Incoming ports the port is maintained automatically (as per history of "supervisord.log")
• in the Outgoing ports, "use random ports" is ticked
• in the Network Extras all the check boxes are ticked (UPNP, NAT-PMP, Peer Exchange, LSD, DHT)

Is my configuration optimized, should i untick anything ?

Because I have a fiber internet connexion and i have 8Gb in upload and download and would like to maximize also the upload rate as much as possible, i only see peaks around 1.3MiB/s , and in download i can reach 65 MiB/s.

 

Let me know if anything could be adjusted to maximize especially the upload speed (to also maximize my ratio)

 

Cheers!

[binhex]

52 minutes ago, heisenberg06 said:

Hello,

I've been switching from surfshark to ProtonVPN on my delugeVPN container (especially to enable port forwarding and seed properly), and i believe i configured everything as described in the help page Q31/A31 from vpn.md in github.

In my deluge configuration under Network,

 

• in the Incoming ports the port is maintained automatically (as per history of "supervisord.log")
• in the Outgoing ports, "use random ports" is ticked
• in the Network Extras all the check boxes are ticked (UPNP, NAT-PMP, Peer Exchange, LSD, DHT)

Is my configuration optimized, should i untick anything ?

Because I have a fiber internet connexion and i have 8Gb in upload and download and would like to maximize also the upload rate as much as possible, i only see peaks around 1.3MiB/s , and in download i can reach 65 MiB/s.

 

Let me know if anything could be adjusted to maximize especially the upload speed (to also maximize my ratio)

 

Cheers!

That all sounds correct to me, not sure why you are suffering low ul rates, just double check the incoming port is visible from the outside, Please see Q9 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

[heisenberg06]

I went to the website to test the port and it is opened. The only discrepancy i see is : at the bottom right of WebUI of Deluge i have an IP that is slightly different from IP mentionned in supervisord.log. The one specificed in supervisord.log is the correct one as the port is opened on this IP and not on the IP seen at the bottom in the UI of deluge.

 

Also i see these warnings in the supervisord.log:

 

• 2024-08-06 13:02:48,025 DEBG 'watchdog-script' stdout output:
• [warn] Incoming port site 'https://canyouseeme.org/' failed to web scrape, marking as failed
•  
• [warn] Incoming port site 'https://ifconfig.co/port/64055' failed json download, marking as failed

 

Don't know if this could be problematic but these warnings are happening quite often

Edit: I also used the OVPN file with TCP and not UDP, could it be problematic ?

Edited August 6 by heisenberg06

[medmad]

Just upgraded to unraid 6.12.11 and starting up all my plugins and dockers and I am having problems with setting up the binhex delugevpn docker. I am using a disk installed with unassigned devices as the storage location for my download location. Once the container starts and you get to the web interface for deluge it shows an error in the bottom left corner of the interface (freespace in download folder). I think my problem is in the way that I have configured the SMB shares but not sure how to correct the problem. I cannot seem to configure the unassigned device that I want to use as an SMB share. Any help would be great. I posted this in unRaid general support but not sure if I should post in delugevpn support or unassigned device plugin support.

[strike]

5 hours ago, medmad said:

Just upgraded to unraid 6.12.11 and starting up all my plugins and dockers and I am having problems with setting up the binhex delugevpn docker. I am using a disk installed with unassigned devices as the storage location for my download location. Once the container starts and you get to the web interface for deluge it shows an error in the bottom left corner of the interface (freespace in download folder). I think my problem is in the way that I have configured the SMB shares but not sure how to correct the problem. I cannot seem to configure the unassigned device that I want to use as an SMB share. Any help would be great. I posted this in unRaid general support but not sure if I should post in delugevpn support or unassigned device plugin support.

Post your docker run command or a screenshot of your delugvpn docker template settings. And also a screenshot of the download section in the deluge webui. 

[jermcel]

On 7/26/2024 at 8:23 AM, jermcel said:

Having issues with PIA Port Forwarding OVPN's.  They just stopped working in the last few days and I don't know why.  I was using CA Toronto. 

I queried the API to get valid port forward endpoints using the following:

 

$ curl -s https://serverlist.piaservers.net/vpninfo/servers/v6 | head -n1 | jq -r '.regions | .[] | select(.port_forward) | .name' | sort

 

I have tried every other Canada endpoint as well as Netherlands, Berlin and Mexico, but I get this in the log each time.

 

2024-07-26 08:11:36,228 DEBG 'start-script' stdout output:
[info] Script started to assign incoming port for 'pia'
[info] Port forwarding is enabled
[info] Checking endpoint 'de-berlin.privacy.network' is port forward enabled...

2024-07-26 08:11:37,275 DEBG 'start-script' stdout output:
[info] PIA endpoint 'de-berlin.privacy.network' is NOT in the list of endpoints that support port forwarding shown below:-

2024-07-26 08:11:38,324 DEBG 'start-script' stdout output:
[info] List of PIA endpoints that support port forwarding:-
[info] Script finished to assign incoming port

 

Am I missing something that has changed at PIA?  Can someone point me in the right direction?

Bumping this.  I still have not resolved this issue and I am not sure what the problem is.  Can someone point me in the right direction.  Regardless of what PIA endpoint I choose, DelugeVPN says it is not in the list of endpoints that support port forwarding.

[binhex]

1 hour ago, jermcel said:

Bumping this.  I still have not resolved this issue and I am not sure what the problem is.  Can someone point me in the right direction.  Regardless of what PIA endpoint I choose, DelugeVPN says it is not in the list of endpoints that support port forwarding.

set STRICT_PORT_FORWARD to 'no' if you do not want an incoming port or switch to one of the endpoints listed in the log that does support port forwarding.

[jermcel]

1 hour ago, binhex said:

set STRICT_PORT_FORWARD to 'no' if you do not want an incoming port or switch to one of the endpoints listed in the log that does support port forwarding.

This is going to sound dumb, but here goes.  I am looking in the supervisord.log but I don't know where the "list" of approved items are at.  It is only showing "Info" level logs and I am not sure where to find this or how to elevate the supervisord.log to be verbose.  Am I looking in the wrong spot?  I tried setting the config for Debug to true, but that does not increase or provide the info in the log either.

Edited August 8 by jermcel

[JonathanM]

21 minutes ago, jermcel said:

I am looking in the supervisord.log

Attach the log, be sure to redact your VPN credentials.

[jermcel]

Attached

supervisord.log.txt

[JonathanM]

@jermcel, which version of Unraid are you running?

 

@binhexThere are several things in the supervisord file that look strange to me, first is the ipmangle, I thought that was no longer an issue, also since I use wireguard I can't compare my logs directly.

[binhex]

6 minutes ago, JonathanM said:

, first is the ipmangle, I thought that was no longer an issue

mangle is still checked for and it CAN be dynamically loaded so generally that can be ignored, i may remove that from being logged.

The real weird issue here is that the list of port forward enabled endpoints is not being generated, which is leading to a false detection of the endpoint NOT being in the list, i need to account for that in the code, but the strange thing is i literally just restarted my container now and i got the list of port forward enabled endpoints no issue, so maybe it is a transitory issue, from @jermcel log:-
 

2024-08-08 12:46:41,868 DEBG 'start-script' stdout output:
[info] PIA endpoint 'ca-toronto.privacy.network' is NOT in the list of endpoints that support port forwarding shown below:-

2024-08-08 12:46:42,607 DEBG 'start-script' stdout output:
[info] List of PIA endpoints that support port forwarding:-

2024-08-08 12:46:42,608 DEBG 'start-script' stdout output:
[info] Script finished to assign incoming port

 

[jermcel]

Okay...I have resolved this issue finally.  It is always something small.  

 

In my ovpn file I have several remote access points that allow port forwarding

 

******

remote ca-toronto.privacy.network 1198
remote ca-montreal.privacy.network 1198
remote ca-vancouver.privacy.network 1198
remote de-berlin.privacy.network 1198
remote de-frankfurt.privacy.network 1198
remote france.privacy.network 1198
remote czech.privacy.network 1198
remote ro.privacy.network 1198

************

 

I did this incase an endpoint goes down that it would go to the next one.

 

I did a double check against PIA servers again for port forward enabled endpoints using this Curl command.  

curl.exe -s https://serverlist.piaservers.net/vpninfo/servers/v6 | head -n1 | jq -r '.regions | .[] | select(.port_forward) | .name' | sort

 

I checked the results against my ovpn list and it appears that Spain was removed from the port forward enabled endpoints.  

So the lesson learned here is that if your ovpn file has multiple endpoints and one of those is removed from the list in PIA, it will not connect correctly.  Once I removed Spain, it connected just fine.

[binhex]

Just now, jermcel said:

I checked the results against my ovpn list and it appears that Spain was removed from the port forward enabled endpoints.  

That is a good catch!, but ultimately the list of endpoints should of been shown, so something else was going on here - unless you removed them from the log file?.