[Support] binhex - DelugeVPN


Recommended Posts

well i havent made any changes to the PIA client in W10 and i just connect to the irish server and ran a speedtest. so im guessing whatever default one is on it. well the server is connected to the same gigabit network as this pc and is capable of using it as i have transferred files at ~100MB. so it is capable of much higher speeds. it literally just has something to do with either deluge or the connection it has to the VPN.

Link to comment

Hey guys,

I've got the image up and running, but I can't access deluge web-ui from other clients, than my host using localhost:8112.

 

This is how I created the docker:

 

docker create --cap-add=NET_ADMIN -p 8112:8112 -p 8118:8118 -p 58846:58846 --name=delugevpn -v /media:/media -v /opt/delugevpn/config:/config -v /etc/localtime:/etc/localtime:ro -e VPN_ENABLED=yes -e VPN_USER=MYUSER-e VPN_PASS=MYPASS-e VPN_REMOTE=nl.privateinternetaccess.com -e VPN_PORT=1194 -e VPN_PROTOCOL=udp -e VPN_PROV=pia -e ENABLE_PRIVOXY=no -e LAN_RANGE=192.168.1.1-192.168.1.254 -e DEBUG=false binhex/arch-delugevpn

 

I can't see any errors in the supervisord.log, so got no clue what is wrong :/

 

Anyone able to help?

Link to comment

Hey guys,

I've got the image up and running, but I can't access deluge web-ui from other clients, than my host using localhost:8112.

 

This is how I created the docker:

 

docker create --cap-add=NET_ADMIN -p 8112:8112 -p 8118:8118 -p 58846:58846 --name=delugevpn -v /media:/media -v /opt/delugevpn/config:/config -v /etc/localtime:/etc/localtime:ro -e VPN_ENABLED=yes -e VPN_USER=MYUSER-e VPN_PASS=MYPASS-e VPN_REMOTE=nl.privateinternetaccess.com -e VPN_PORT=1194 -e VPN_PROTOCOL=udp -e VPN_PROV=pia -e ENABLE_PRIVOXY=no -e LAN_RANGE=192.168.1.1-192.168.1.254 -e DEBUG=false binhex/arch-delugevpn

 

I can't see any errors in the supervisord.log, so got no clue what is wrong :/

 

Anyone able to help?

 

Makes it a lot easier if you're using Unraid tbh....

Link to comment

Thank you for this docker!

 

At first, I did order a 3 months of AirVPN.  Now that my 3 months is almost over, I was about to renew when I remember that my Usenet Provider included VPN! So i'm using newshosting.com.  I looked inside my client area, and they had openVPN support :)  So I just follow the custom VPN and it worked at the first try ! :)

 

Super easy, and free VPN (bundled with my Usenet sub.), way to go !

Link to comment

Dang, thought it was the same to get it working on ubuntu :/

 

Edit:

 

Well now I found out it is something to do with the VPN, as when I disable the vpn and only run deluge, I can perfectly access it

 

unraid makes things easier as it has a nice webui which does all the hard work of constructing the docker run command for you, having said that, the run command you posted above looks fine, can you post your supervisord.log file please, minus any sensitive info, also the contents of your ovpn config file.

Link to comment

Dang, thought it was the same to get it working on ubuntu :/

 

Edit:

 

Well now I found out it is something to do with the VPN, as when I disable the vpn and only run deluge, I can perfectly access it

 

unraid makes things easier as it has a nice webui which does all the hard work of constructing the docker run command for you, having said that, the run command you posted above looks fine, can you post your supervisord.log file please, minus any sensitive info, also the contents of your ovpn config file.

 

 

Aaah, I've attached the log file and here is the contents of the ovpn file:

 

client

dev tun

remote nl.privateinternetaccess.com 1194 udp

resolv-retry infinite

nobind

persist-key

ca ca.crt

tls-client

remote-cert-tls server

auth-user-pass credentials.conf

comp-lzo

verb 1

reneg-sec 0

crl-verify crl.pem

supervisord.txt

Link to comment

Dang, thought it was the same to get it working on ubuntu :/

 

Edit:

 

Well now I found out it is something to do with the VPN, as when I disable the vpn and only run deluge, I can perfectly access it

 

unraid makes things easier as it has a nice webui which does all the hard work of constructing the docker run command for you, having said that, the run command you posted above looks fine, can you post your supervisord.log file please, minus any sensitive info, also the contents of your ovpn config file.

 

 

Aaah, I've attached the log file and here is the contents of the ovpn file:

 

client

dev tun

remote nl.privateinternetaccess.com 1194 udp

resolv-retry infinite

nobind

persist-key

ca ca.crt

tls-client

remote-cert-tls server

auth-user-pass credentials.conf

comp-lzo

verb 1

reneg-sec 0

crl-verify crl.pem

 

ok i see nothing wrong with this at all, the log is reporting success, the tunnel is established, deluge looks to start correctly and the incoming port is set, are you sure you cant connect to deluge webui on http://<your hosts ip>:8112

Link to comment

Dang, thought it was the same to get it working on ubuntu :/

 

Edit:

 

Well now I found out it is something to do with the VPN, as when I disable the vpn and only run deluge, I can perfectly access it

 

unraid makes things easier as it has a nice webui which does all the hard work of constructing the docker run command for you, having said that, the run command you posted above looks fine, can you post your supervisord.log file please, minus any sensitive info, also the contents of your ovpn config file.

 

 

Aaah, I've attached the log file and here is the contents of the ovpn file:

 

client

dev tun

remote nl.privateinternetaccess.com 1194 udp

resolv-retry infinite

nobind

persist-key

ca ca.crt

tls-client

remote-cert-tls server

auth-user-pass credentials.conf

comp-lzo

verb 1

reneg-sec 0

crl-verify crl.pem

 

ok i see nothing wrong with this at all, the log is reporting success, the tunnel is established, deluge looks to start correctly and the incoming port is set, are you sure you cant connect to deluge webui on http://<your hosts ip>:8112

 

I can connect to it on my server using hostname:8112 but as soon as i try from another client i got no success

Link to comment

Dang, thought it was the same to get it working on ubuntu :/

 

Edit:

 

Well now I found out it is something to do with the VPN, as when I disable the vpn and only run deluge, I can perfectly access it

 

unraid makes things easier as it has a nice webui which does all the hard work of constructing the docker run command for you, having said that, the run command you posted above looks fine, can you post your supervisord.log file please, minus any sensitive info, also the contents of your ovpn config file.

 

 

Aaah, I've attached the log file and here is the contents of the ovpn file:

 

client

dev tun

remote nl.privateinternetaccess.com 1194 udp

resolv-retry infinite

nobind

persist-key

ca ca.crt

tls-client

remote-cert-tls server

auth-user-pass credentials.conf

comp-lzo

verb 1

reneg-sec 0

crl-verify crl.pem

 

ok i see nothing wrong with this at all, the log is reporting success, the tunnel is established, deluge looks to start correctly and the incoming port is set, are you sure you cant connect to deluge webui on http://<your hosts ip>:8112

 

I can connect to it on my server using hostname:8112 but as soon as i try from another client i got no success

 

ok so the other client is on your lan yes?, and your attempting to connect to the webui NOT the daemon right?, if it is the webui then yes you should be able to connect to this from any machine on the lan, do you have any firewall rules defined on your host?.

 

edit - are you attempting to connect using hostname or ip address?, if hostname then make sure you can resolve the name on the clients your attempting to connect with, maybe try ip address of your host instead of name.

Link to comment

Dang, thought it was the same to get it working on ubuntu :/

 

Edit:

 

Well now I found out it is something to do with the VPN, as when I disable the vpn and only run deluge, I can perfectly access it

 

unraid makes things easier as it has a nice webui which does all the hard work of constructing the docker run command for you, having said that, the run command you posted above looks fine, can you post your supervisord.log file please, minus any sensitive info, also the contents of your ovpn config file.

 

 

Aaah, I've attached the log file and here is the contents of the ovpn file:

 

client

dev tun

remote nl.privateinternetaccess.com 1194 udp

resolv-retry infinite

nobind

persist-key

ca ca.crt

tls-client

remote-cert-tls server

auth-user-pass credentials.conf

comp-lzo

verb 1

reneg-sec 0

crl-verify crl.pem

 

ok i see nothing wrong with this at all, the log is reporting success, the tunnel is established, deluge looks to start correctly and the incoming port is set, are you sure you cant connect to deluge webui on http://<your hosts ip>:8112

 

I can connect to it on my server using hostname:8112 but as soon as i try from another client i got no success

 

ok so the other client is on your lan yes?, and your attempting to connect to the webui NOT the daemon right?, if it is the webui then yes you should be able to connect to this from any machine on the lan, do you have any firewall rules defined on your host?.

 

edit - are you attempting to connect using hostname or ip address?, if hostname then make sure you can resolve the name on the clients your attempting to connect with, maybe try ip address of your host instead of name.

 

Yes, trying to connect to the webui from other machines on my lan. Tried used both hostname and IP = no luck :/

 

I'm not certain whether I have firewall rules defined though, how do I check?

Link to comment

Dang, thought it was the same to get it working on ubuntu :/

 

Edit:

 

Well now I found out it is something to do with the VPN, as when I disable the vpn and only run deluge, I can perfectly access it

 

unraid makes things easier as it has a nice webui which does all the hard work of constructing the docker run command for you, having said that, the run command you posted above looks fine, can you post your supervisord.log file please, minus any sensitive info, also the contents of your ovpn config file.

 

 

Aaah, I've attached the log file and here is the contents of the ovpn file:

 

client

dev tun

remote nl.privateinternetaccess.com 1194 udp

resolv-retry infinite

nobind

persist-key

ca ca.crt

tls-client

remote-cert-tls server

auth-user-pass credentials.conf

comp-lzo

verb 1

reneg-sec 0

crl-verify crl.pem

 

ok i see nothing wrong with this at all, the log is reporting success, the tunnel is established, deluge looks to start correctly and the incoming port is set, are you sure you cant connect to deluge webui on http://<your hosts ip>:8112

 

I can connect to it on my server using hostname:8112 but as soon as i try from another client i got no success

 

ok so the other client is on your lan yes?, and your attempting to connect to the webui NOT the daemon right?, if it is the webui then yes you should be able to connect to this from any machine on the lan, do you have any firewall rules defined on your host?.

 

edit - are you attempting to connect using hostname or ip address?, if hostname then make sure you can resolve the name on the clients your attempting to connect with, maybe try ip address of your host instead of name.

 

Yes, trying to connect to the webui from other machines on my lan. Tried used both hostname and IP = no luck :/

 

I'm not certain whether I have firewall rules defined though, how do I check?

 

type this on your host:-

 

iptables -L

 

This will list out all iptable entries.

Link to comment

Dang, thought it was the same to get it working on ubuntu :/

 

Edit:

 

Well now I found out it is something to do with the VPN, as when I disable the vpn and only run deluge, I can perfectly access it

 

unraid makes things easier as it has a nice webui which does all the hard work of constructing the docker run command for you, having said that, the run command you posted above looks fine, can you post your supervisord.log file please, minus any sensitive info, also the contents of your ovpn config file.

 

 

Aaah, I've attached the log file and here is the contents of the ovpn file:

 

client

dev tun

remote nl.privateinternetaccess.com 1194 udp

resolv-retry infinite

nobind

persist-key

ca ca.crt

tls-client

remote-cert-tls server

auth-user-pass credentials.conf

comp-lzo

verb 1

reneg-sec 0

crl-verify crl.pem

 

ok i see nothing wrong with this at all, the log is reporting success, the tunnel is established, deluge looks to start correctly and the incoming port is set, are you sure you cant connect to deluge webui on http://<your hosts ip>:8112

 

I can connect to it on my server using hostname:8112 but as soon as i try from another client i got no success

 

ok so the other client is on your lan yes?, and your attempting to connect to the webui NOT the daemon right?, if it is the webui then yes you should be able to connect to this from any machine on the lan, do you have any firewall rules defined on your host?.

 

edit - are you attempting to connect using hostname or ip address?, if hostname then make sure you can resolve the name on the clients your attempting to connect with, maybe try ip address of your host instead of name.

 

Yes, trying to connect to the webui from other machines on my lan. Tried used both hostname and IP = no luck :/

 

I'm not certain whether I have firewall rules defined though, how do I check?

 

type this on your host:-

 

iptables -L

 

This will list out all iptable entries.

 

root@ubuntu:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (1 references)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             172.17.0.9           tcp dpt:8112
ACCEPT     tcp  --  anywhere             172.17.0.9           tcp dpt:8118

Link to comment

Dang, thought it was the same to get it working on ubuntu :/

 

Edit:

 

Well now I found out it is something to do with the VPN, as when I disable the vpn and only run deluge, I can perfectly access it

 

unraid makes things easier as it has a nice webui which does all the hard work of constructing the docker run command for you, having said that, the run command you posted above looks fine, can you post your supervisord.log file please, minus any sensitive info, also the contents of your ovpn config file.

 

 

Aaah, I've attached the log file and here is the contents of the ovpn file:

 

client

dev tun

remote nl.privateinternetaccess.com 1194 udp

resolv-retry infinite

nobind

persist-key

ca ca.crt

tls-client

remote-cert-tls server

auth-user-pass credentials.conf

comp-lzo

verb 1

reneg-sec 0

crl-verify crl.pem

 

ok i see nothing wrong with this at all, the log is reporting success, the tunnel is established, deluge looks to start correctly and the incoming port is set, are you sure you cant connect to deluge webui on http://<your hosts ip>:8112

 

I can connect to it on my server using hostname:8112 but as soon as i try from another client i got no success

 

ok so the other client is on your lan yes?, and your attempting to connect to the webui NOT the daemon right?, if it is the webui then yes you should be able to connect to this from any machine on the lan, do you have any firewall rules defined on your host?.

 

edit - are you attempting to connect using hostname or ip address?, if hostname then make sure you can resolve the name on the clients your attempting to connect with, maybe try ip address of your host instead of name.

 

Yes, trying to connect to the webui from other machines on my lan. Tried used both hostname and IP = no luck :/

 

I'm not certain whether I have firewall rules defined though, how do I check?

 

type this on your host:-

 

iptables -L

 

This will list out all iptable entries.

 

root@ubuntu:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (1 references)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             172.17.0.9           tcp dpt:8112
ACCEPT     tcp  --  anywhere             172.17.0.9           tcp dpt:8118

 

ok so nothing blocking there, its very odd, have you tried another browser on your client machines?, or tried forcing a clear down of caching, what error are you seeing on the client machines?

Link to comment

Dang, thought it was the same to get it working on ubuntu :/

 

Edit:

 

Well now I found out it is something to do with the VPN, as when I disable the vpn and only run deluge, I can perfectly access it

 

unraid makes things easier as it has a nice webui which does all the hard work of constructing the docker run command for you, having said that, the run command you posted above looks fine, can you post your supervisord.log file please, minus any sensitive info, also the contents of your ovpn config file.

 

 

Aaah, I've attached the log file and here is the contents of the ovpn file:

 

client

dev tun

remote nl.privateinternetaccess.com 1194 udp

resolv-retry infinite

nobind

persist-key

ca ca.crt

tls-client

remote-cert-tls server

auth-user-pass credentials.conf

comp-lzo

verb 1

reneg-sec 0

crl-verify crl.pem

 

ok i see nothing wrong with this at all, the log is reporting success, the tunnel is established, deluge looks to start correctly and the incoming port is set, are you sure you cant connect to deluge webui on http://<your hosts ip>:8112

 

I can connect to it on my server using hostname:8112 but as soon as i try from another client i got no success

 

ok so the other client is on your lan yes?, and your attempting to connect to the webui NOT the daemon right?, if it is the webui then yes you should be able to connect to this from any machine on the lan, do you have any firewall rules defined on your host?.

 

edit - are you attempting to connect using hostname or ip address?, if hostname then make sure you can resolve the name on the clients your attempting to connect with, maybe try ip address of your host instead of name.

 

Yes, trying to connect to the webui from other machines on my lan. Tried used both hostname and IP = no luck :/

 

I'm not certain whether I have firewall rules defined though, how do I check?

 

type this on your host:-

 

iptables -L

 

This will list out all iptable entries.

 

root@ubuntu:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (1 references)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             172.17.0.9           tcp dpt:8112
ACCEPT     tcp  --  anywhere             172.17.0.9           tcp dpt:8118

 

ok so nothing blocking there, its very odd, have you tried another browser on your client machines?, or tried forcing a clear down of caching, what error are you seeing on the client machines?

 

Tried both :)

 

Getting this error in chrome:

 

This webpage is not available

 

ERR_CONNECTION_REFUSED

 

Edit:

 

Okay, I finally got it working, though not quite sure on how as I don't understand iptables :D

If I run "iptables -t nat -A POSTROUTING -j MASQUERADE" then it works, but now I need to figure out how to get this run at each boot

Link to comment

Thank you for this docker!

 

At first, I did order a 3 months of AirVPN.  Now that my 3 months is almost over, I was about to renew when I remember that my Usenet Provider included VPN! So i'm using newshosting.com.  I looked inside my client area, and they had openVPN support :)  So I just follow the custom VPN and it worked at the first try ! :)

 

Super easy, and free VPN (bundled with my Usenet sub.), way to go !

 

It seems I spoke too soon :)

 

My private tracker told me that my port 32767 is closed.  How can I open that on the docker? Do I just map this port on the host and then forward that port from my router ?  (don't think so, the port is closed from my VPN IP...)

 

Link to comment

Thank you for this docker!

 

At first, I did order a 3 months of AirVPN.  Now that my 3 months is almost over, I was about to renew when I remember that my Usenet Provider included VPN! So i'm using newshosting.com.  I looked inside my client area, and they had openVPN support :)  So I just follow the custom VPN and it worked at the first try ! :)

 

Super easy, and free VPN (bundled with my Usenet sub.), way to go !

 

It seems I spoke too soon :)

 

My private tracker told me that my port 32767 is closed.  How can I open that on the docker? Do I just map this port on the host and then forward that port from my router ?  (don't think so, the port is closed from my VPN IP...)

 

This is going to be down to your vpn provider, as you rightly said above changing the port forward on your router will have no affect on deluge, as this is using a vpn tunnel with port forwarding defined by the end point, i.e. the provider, so you would need to see if you can specify the incoming port for your connection. I know airvpn does give you some configuration for this, PIA doesnt allow you define a static port number, not sure about your provider.

 

Basically you need to investigate how your provider hands out incoming ports (some providers dont allow incoming ports at all), and manually configure deluge to use this, good luck.

Link to comment

Edit:

 

Okay, I finally got it working, though not quite sure on how as I don't understand iptables :D

If I run "iptables -t nat -A POSTROUTING -j MASQUERADE" then it works, but now I need to figure out how to get this run at each boot

 

yeah i too have been investigating this further for you, i have tested this on my openelec appliance and i can see the same issue, so thats good, took me a while but i have a fix for this by adding in an additional route, im still investigating at this point as i want to get this as tight as possible, i cannot allow any ip leakage so this will be nailed.

Link to comment

Edit:

 

Okay, I finally got it working, though not quite sure on how as I don't understand iptables :D

If I run "iptables -t nat -A POSTROUTING -j MASQUERADE" then it works, but now I need to figure out how to get this run at each boot

 

yeah i too have been investigating this further for you, i have tested this on my openelec appliance and i can see the same issue, so thats good, took me a while but i have a fix for this by adding in an additional route, im still investigating at this point as i want to get this as tight as possible, i cannot allow any ip leakage so this will be nailed.

 

Sounds great! :)

Hopefully my temporary fix won't result in any leaks :)

Link to comment

I am having trouble getting the VPN to connect.  When I have VPN set to off, everything runs as expected.  When I turn it on, it looks like it connects, but then I get an AUTH_FAILED.  I cant tell if thats for deluge or vpn.  I am using PIA as my vpn provider.  I have verified the username/passwd.  I turned on debug and this is the startup log I get.

 

EDIT* for clarification, when I start it with VPN enabled, it appears to run.  However, I cannot connect to the webui, or the daemon.  When I start it without VPN enabled, I can connect to both fine.  I am connecting via a computer on the LAN.  Also, it seems that privoxy is being started despite having the setting set to no.

 

2016-02-01 17:00:10,026 CRIT Set uid to user 0
2016-02-01 17:00:10,026 WARN Included extra file "/etc/supervisor/conf.d/delugevpn.conf" during parsing
2016-02-01 17:00:10,029 INFO supervisord started with pid 1
2016-02-01 17:00:11,032 INFO spawned: 'privoxy' with pid 7
2016-02-01 17:00:11,034 INFO spawned: 'start' with pid 8
2016-02-01 17:00:11,035 INFO spawned: 'webui' with pid 9
2016-02-01 17:00:11,037 INFO spawned: 'deluge' with pid 10
2016-02-01 17:00:11,044 DEBG 'privoxy' stdout output:
[info] VPN is enabled, checking VPN tunnel local ip is valid

2016-02-01 17:00:11,044 INFO success: privoxy entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2016-02-01 17:00:11,044 INFO success: start entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2016-02-01 17:00:11,045 DEBG 'privoxy' stdout output:
[info] checking VPN tunnel local ip is valid...

2016-02-01 17:00:11,048 DEBG 'deluge' stdout output:
[info] VPN enabled, configuring Deluge...

2016-02-01 17:00:11,049 DEBG 'deluge' stdout output:
[info] checking VPN tunnel local ip is valid...

2016-02-01 17:00:11,054 DEBG 'start' stdout output:
[info] VPN is enabled, beginning configuration of VPN

2016-02-01 17:00:11,067 DEBG 'start' stdout output:
[info] VPN provider defined as pia

2016-02-01 17:00:11,067 DEBG 'start' stdout output:
[info] VPN config file (ovpn extension) is located at /config/openvpn/openvpn.ovpn

2016-02-01 17:00:11,070 DEBG 'start' stdout output:
[info] Env vars defined via docker -e flags for remote host, port and protocol, writing values to ovpn file...

2016-02-01 17:00:11,093 DEBG 'start' stdout output:
[debug] Contents of ovpn file /config/openvpn/openvpn.ovpn as follows...

2016-02-01 17:00:11,094 DEBG 'start' stdout output:
client
dev tun
remote us-east.privateinternetaccess.com 1194 udp
resolv-retry infinite
nobind
persist-key
ca ca.crt
tls-client
remote-cert-tls server
auth-user-pass credentials.conf
comp-lzo
verb 1
reneg-sec 0
crl-verify crl.pem



2016-02-01 17:00:11,094 DEBG 'start' stdout output:
[debug] Environment variables defined as follows...

2016-02-01 17:00:11,095 DEBG 'start' stdout output:
LAN_RANGE=192.168.1.1-192.168.1.254
HOSTNAME=0bd56e14739c
TERM=xterm
VPN_PORT=1194
VPN_USER=***********
VPN_PASS=****************
VPN_ENABLED=yes
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
SUPERVISOR_GROUP_NAME=start
PWD=/
LANG=en_GB.UTF-8
TZ=America/New_York
VPN_PROTOCOL=udp
SUPERVISOR_ENABLED=1
SHLVL=1
HOME=/home/nobody
VPN_REMOTE=us-east.privateinternetaccess.com
SUPERVISOR_PROCESS_NAME=start
DEBUG=true
VPN_PROV=pia
ENABLE_PRIVOXY=no
_=/usr/sbin/printenv

2016-02-01 17:00:11,095 DEBG 'start' stdout output:
[info] VPN provider remote gateway defined as us-east.privateinternetaccess.com
[info] VPN provider remote port defined as 1194
[info] VPN provider remote protocol defined as udp

2016-02-01 17:00:11,104 DEBG 'start' stdout output:
[info] VPN provider username defined as **************

2016-02-01 17:00:11,108 DEBG 'start' stdout output:
[info] VPN provider password defined as ************

2016-02-01 17:00:11,127 DEBG 'start' stdout output:
[info] ip routing table

2016-02-01 17:00:11,127 DEBG 'start' stdout output:
default via 172.17.42.1 dev eth0 

2016-02-01 17:00:11,128 DEBG 'start' stdout output:
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.27 
--------------------

2016-02-01 17:00:11,159 DEBG 'start' stdout output:
[info] iptables

2016-02-01 17:00:11,161 DEBG 'start' stdout output:
-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT DROP
-A INPUT -i tun0 -j ACCEPT
-A INPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 1194 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8112 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --sport 8112 -j ACCEPT
-A INPUT -i eth0 -m iprange --src-range 192.168.1.1-192.168.1.254 -j ACCEPT
-A INPUT -i eth0 -m iprange --dst-range 192.168.1.1-192.168.1.254 -j ACCEPT
-A INPUT -p udp -m udp --sport 53 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 1194 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --dport 8112 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8112 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT

2016-02-01 17:00:11,161 DEBG 'start' stdout output:
--------------------

2016-02-01 17:00:11,161 DEBG 'start' stdout output:
[info] nameservers

2016-02-01 17:00:11,161 DEBG 'start' stdout output:
nameserver 8.8.8.8
nameserver 8.8.4.4

2016-02-01 17:00:11,162 DEBG 'start' stdout output:
--------------------

2016-02-01 17:00:11,171 DEBG 'start' stdout output:
[info] Starting OpenVPN...

2016-02-01 17:00:11,176 DEBG 'start' stdout output:
Mon Feb 1 17:00:11 2016 OpenVPN 2.3.9 x86_64-unknown-linux-gnu [sSL (OpenSSL)] [LZO] [EPOLL] [MH] [iPv6] built on Dec 24 2015
Mon Feb 1 17:00:11 2016 library versions: OpenSSL 1.0.2e 3 Dec 2015, LZO 2.09
Mon Feb 1 17:00:11 2016 WARNING: file 'credentials.conf' is group or others accessible

2016-02-01 17:00:11,194 DEBG 'start' stdout output:
Mon Feb 1 17:00:11 2016 UDPv4 link local: [undef]
Mon Feb 1 17:00:11 2016 UDPv4 link remote: [AF_INET]66.55.134.201:1194

2016-02-01 17:00:11,207 DEBG 'start' stdout output:
Mon Feb 1 17:00:11 2016 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

2016-02-01 17:00:11,267 DEBG 'start' stdout output:
Mon Feb 1 17:00:11 2016 [Private Internet Access] Peer Connection Initiated with [AF_INET]66.55.134.201:1194

2016-02-01 17:00:12,269 INFO success: webui entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2016-02-01 17:00:12,269 INFO success: deluge entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2016-02-01 17:00:13,640 DEBG 'start' stdout output:
Mon Feb 1 17:00:13 2016 AUTH: Received control message: AUTH_FAILED

2016-02-01 17:00:13,640 DEBG 'start' stdout output:
Mon Feb 1 17:00:13 2016 SIGTERM[soft,auth-failure] received, process exiting

2016-02-01 17:00:13,641 DEBG fd 9 closed, stopped monitoring (stdout)>
2016-02-01 17:00:13,641 DEBG fd 14 closed, stopped monitoring (stderr)>
2016-02-01 17:00:13,641 INFO exited: start (exit status 0; expected)
2016-02-01 17:00:13,641 DEBG received SIGCLD indicating a child quit

Link to comment

The username & password is the same as one used to log onto the website correct?

The same username & password combo work when using openvpn from my desktop to connect to PIA, so I am fairly sure that the password is correct.  Do I need to overwrite the ca.crt or crl.pem files with the PIA ones?

 

PIA login/password isn't right.

 

Mon Feb 1 17:00:13 2016 SIGTERM[soft,auth-failure] received, process exiting

Link to comment

Ok, apparently it didn't like my password for some reason and would fail with it.  I used a randomly generated 20 digit password.  I changed the password and the new password works fine. 

 

Any idea why 4l%3OsZb0$sX$^K0GKPy would cause it to fail?

 

 

 

Double and triple checked, no trailing spaces on username/password.

 

are you copy/pasting the username/pass, if so watch for trailing spaces.

Link to comment

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.