@7thSon ive had time to do a more thorough check, trying remote lines in my ovpn file with single ip, single hostname and multi remote hostnames specified and all work as expected, please can you post your ovpn file and also do the following:-

https://github.com/binhex/documentation/blob/master/docker/faq/help.md

 

i know privacy is a big concern but please leave in resolved ip's in the log if possible, just remove any credentials/keys shown in the log.

On 9/18/2020 at 7:02 AM, binhex said:

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 image will now loop through the entire list, for example, pia port forward enabled endpoints, all you need to do is edit your ovpn config file and add the remote endpoints at the top and sort into the order you want them to be tried, an example pia ovpn file is below (mine):-

remote ca-toronto.privateinternetaccess.com 1198 udp
remote ca-montreal.privateinternetaccess.com 1198 udp
remote ca-vancouver.privateinternetaccess.com 1198 udp
remote de-berlin.privateinternetaccess.com 1198 udp
remote de-frankfurt.privateinternetaccess.com 1198 udp
remote france.privateinternetaccess.com 1198 udp
remote czech.privateinternetaccess.com 1198 udp
remote spain.privateinternetaccess.com 1198 udp
remote ro.privateinternetaccess.com 1198 udp
client
dev tun
resolv-retry infinite
nobind
persist-key
# -----faster GCM-----
cipher aes-128-gcm
auth sha256
ncp-disable
# -----faster GCM-----
tls-client
remote-cert-tls server
auth-user-pass credentials.conf
comp-lzo
verb 1
crl-verify crl.rsa.2048.pem
ca ca.rsa.2048.crt
disable-occ

 

I did look at multi ovpn file support, but this is easier to do and as openvpn supports multi remote lines, it felt like the most logical approach.

 

note:- Due to ns lookup for all remote lines, and potential failure and subsequent try of the next remote line, time to initialisation of the app may take longer.

 

p.s. I dont want to talk about how difficult this was to shoe horn in, i need to lie down in a dark room now and not think about bash for a while :-), any issues let me know!.

I notice your examples are using UDP openvpn connection.. Is there a preferred method? The PIA OpenVPN config page has many options and ive never been sure if one method is better than another? Also, is there any reason to use fourth gen config files over the third gen?

On 9/19/2020 at 3:50 AM, binhex said:

Is a tweaked version for maximum speed on pia using gcm

Sent from my CLT-L09 using Tapatalk
 

 

3 hours ago, 2Piececombo said:

I notice your examples are using UDP openvpn connection.. Is there a preferred method? The PIA OpenVPN config page has many options and ive never been sure if one method is better than another? Also, is there any reason to use fourth gen config files over the third gen?

 

guessing it has to do with max speed tweaks, which i will look into after getting constant consistent connections and activity

 

EDIT:

now that i'm finally creating a combined file, the default ones i have start with the following, so maybe its always been udp by default (thought defaults were tcp)

client
dev tun
proto udp
remote LOCATION.privateinternetaccess.com 1198

 

Edited September 21, 20205 yr by Cull2ArcaHeresy

3 hours ago, Cull2ArcaHeresy said:

guessing it has to do with max speed tweaks, which i will look into after getting constant consistent connections and activity

 

EDIT:

now that i'm finally creating a combined file, the default ones i have start with the following, so maybe its always been udp by default (thought defaults were tcp)

udp will always be faster than tcp, so that is the preferred protocol for vpn connections.

20 minutes ago, cinico said:

I'm having the exact same issue after updating to latest version. I am using privado.io VPN (wlvpn.com?) and I did not change my OVPN file at all which had been working fine. It was single-line, DNS name, being properly resolved according to docker log. 
I have since tried multi-remote too, no change. Using the OVPN client from the provider I can connect from the same location.

Please can you post your ovpn file and also do the following:-

https://github.com/binhex/documentation/blob/master/docker/faq/help.md

 

i know privacy is a big concern but please leave in resolved ip's in the log if possible, just remove any credentials/keys shown in the log.

18 minutes ago, binhex said:

Please can you post your ovpn file and also do the following:-

https://github.com/binhex/documentation/blob/master/docker/faq/help.md

 

i know privacy is a big concern but please leave in resolved ip's in the log if possible, just remove any credentials/keys shown in the log.

I deleted my post because I realized I had dumped some old ovpn files into the folder while trying to resolve this. I corrected the ovpn files and rolled the container back two versions to rtorrent-ps-1.1.r54.ga787dd9-1-16 and it is connecting now. If you would like me to go back to latest and troubleshoot I am willing to do that. Otherwise I will just try a later version when available. Sorry for wasting your time.

2 minutes ago, cinico said:

If you would like me to go back to latest and troubleshoot I am willing to do that.

yes please, otherwise you will be stuck on that version.

posted today - port forwarding for nextgen servers

 

https://www.privateinternetaccess.com/helpdesk/news/posts/introducing-next-generation-port-forwarding

6 minutes ago, morreale said:

posted today - port forwarding for nextgen servers

 

https://www.privateinternetaccess.com/helpdesk/news/posts/introducing-next-generation-port-forwarding

but sadly "Connect to OpenVPN: We are still working on this script.", which makes me assume the back end aint ready yet either

11 minutes ago, Cull2ArcaHeresy said:

but sadly "Connect to OpenVPN: We are still working on this script.", which makes me assume the back end aint ready yet either

The unofficial script below already works with OpenVPN. https://github.com/thrnz/docker-wireguard-pia/blob/master/extra/pf.sh

2020-09-22 09:39:49,769 DEBG 'start-script' stdout output:
[crit] 'entries' cannot be resolved, possible DNS issues, exiting...

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.

I'm using OpenVPN on my own remote server and by default, it includes "proto" and "remote" in the comments of the generated config file. These are being recognized as protocols and remote endpoints.

 

	vpn_remote_line=$(cat "${VPN_CONFIG}" | grep -P -o '(?<=remote\s).*' | paste -s -d, - || true)

I think you need a ^ in your regex for remote, probably the same for proto but I can't look further at the moment.

 

Edited September 22, 20205 yr by psycho_asylum

22 minutes ago, psycho_asylum said:

2020-09-22 09:39:49,769 DEBG 'start-script' stdout output:
[crit] 'entries' cannot be resolved, possible DNS issues, exiting...

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.

Startup is failing because it is recognizing "entires" as a remote endpoint in my config even though it's part of a comment. 

ok i can see the bug, its due to a regex match, for now to get it going please remove the word remote from the comment.

Edited September 22, 20205 yr by binhex

Just now, binhex said:

ok i can see the bug, its due to a regex match, for now to get it going please remove the word remote from the comment.

Thanks. I just updated my comment. It's also recognizing anywhere "proto" is present.  I've got it running now.  

35 minutes ago, psycho_asylum said:

I think you need a ^ in your regex for remote, probably the same for proto but I can't look further at the moment.

exactly!, just need to double check that lookbehind regex allows for this with grep.

18 hours ago, psycho_asylum said:

Thanks. I just updated my comment. It's also recognizing anywhere "proto" is present.  I've got it running now.  

changes are in, now anchored both remote and proto, please pull down the latest image in around an hour from this post.

On 9/18/2020 at 11:23 PM, tooviral said:

All I did was

 

1. Set up the port forward on Mullvad. 

2. Edited the .torrent.rc file and specified the port like this: network.port_range.set = xxxx-xxxx where xxxx is the port number and set "network.port_random.set = no"

 

and worked

This is what I have done, and its not working. I can't see what im missing. My torrent.rc file must be good  as its clearly trying to use the correct port. Did you make any changes to the mulvad openVPN config files. It's the only other place I can see it going wrong.

didnt make any changes to the files, added user/pass to docker variable and put these files in the openvpn folder

47 minutes ago, tooviral said:

didnt make any changes to the files, added user/pass to docker variable and put these files in the openvpn folder

And when you check the port status in rTorrent’s GUI, it shows the forwarded port as open?  I’m set up exactly the same as you other than I’m using a different VPN location and I get the exclamation mark in the status bar with the message xxxxx: Port is closed. Where xxxxx is the forwarded port. 

Seems it may have been a fluke as I am now getting the red exclamation mark too.

 

My docker start command is as follows

Quote

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='binhex-rtorrentvpn' --net='bridge' --privileged=true -e TZ="America/New_York" -e HOST_OS="Unraid" -e 'VPN_ENABLED'='yes' -e 'VPN_USER'='XXXX' -e 'VPN_PASS'='XXXX' -e 'VPN_REMOTE'='ca-tor-002.mullvad.net' -e 'VPN_PORT'='1198' -e 'VPN_PROTOCOL'='udp' -e 'VPN_INCOMING_PORT'='12528' -e 'VPN_DEVICE_TYPE'='tun' -e 'VPN_PROV'='custom' -e 'VPN_OPTIONS'='' -e 'STRONG_CERTS'='yes' -e 'ENABLE_PRIVOXY'='no' -e 'ENABLE_FLOOD'='no' -e 'LAN_NETWORK'='192.168.1.0/24' -e 'NAME_SERVERS'='192.168.1.1,8.8.8.8,8.8.4.4' -e 'DEBUG'='false' -e 'PHP_TZ'='UTC' -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -e 'WEBUI_PASS'='XXXX' -e 'RPC2_PASS'='XXXX' -p '3001:3000/tcp' -p '5000:5000/tcp' -p '9080:9080/tcp' -p '9443:9443/tcp' -p '8119:8118/tcp' -v '/mnt/cache/downloads/':'/data':'rw' -v '/mnt/cache/appdata/binhex-rtorrentvpn':'/config':'rw' --log-opt max-size=50m --log-opt max-file=1 'binhex/arch-rtorrentvpn'

 

Am I doing something wrong?

Edited September 26, 20205 yr by tooviral

So I've noticed in the logs this

 

2020-09-26 08:02:04,415 DEBG 'start-script' stdout output:
[info] Application does not require port forwarding or VPN provider is != pia, skipping incoming port assignment

 

It looks like its not setting the port forward.  Could this be my problem?

7 hours ago, tooviral said:

So I've noticed in the logs this

 

2020-09-26 08:02:04,415 DEBG 'start-script' stdout output:
[info] Application does not require port forwarding or VPN provider is != pia, skipping incoming port assignment

 

It looks like its not setting the port forward.  Could this be my problem?

it wont set the incoming port for you automatically, the only provider that i support automatic incoming port assignment is PIA, all others you need to manually assign the port using your vpn providers web portal and then set the port in the app.

8 hours ago, binhex said:

it wont set the incoming port for you automatically, the only provider that i support automatic incoming port assignment is PIA, all others you need to manually assign the port using your vpn providers web portal and then set the port in the app.

Ive done that in rtorrent.rc and added the variable  -e 'VPN_INCOMING_PORT'='12528' and it still shows a closed in rutorrent and https://portchecker.co/

14 hours ago, tooviral said:

Ive done that in rtorrent.rc and added the variable  -e 'VPN_INCOMING_PORT'='12528' and it still shows a closed in rutorrent and https://portchecker.co/

ok i have seen people report that the built in incoming port checker for rutorrent doesnt work, now it does work perfectly for me, so i can only assume its related to the vpn provider, possibly (and this is a theory at this point) mullvad (and maybe other providers) block incoming ICMP for allocated incoming ports, and therefore the built in check fails (check is done through a website and web scaped for result).

 

try this, look in the supervisord.log file to get your external ip address for the vpn connection (not your isp's external ip), and make a note of the incoming port assigned to you and then plug both of these values into this website:- https://www.yougetsignal.com/tools/open-ports/

 

if it reports open then simply ignore the rutorrent checker and be happy :-), if it reports closed then further investigation is required.

 

Its reported as closed still.

 

Noticed another container variable  "ADDITIONAL_PORTS" in logs and tried adding the incoming port and still no joy.

Latest start logs attached.

rtorrent.txt

Just now, tooviral said:

Its reported as closed still.

 

Noticed another container variable  "ADDITIONAL_PORTS" in logs and tried adding the incoming port and still no joy.

Latest start logs attached.

rtorrent.txt 19.42 kB · 0 downloads

Same here after following binhex’s recommendations.  I’m using Mullvad.