[Support] binhex - DelugeVPN

sp00nman · October 5, 2016

Yes see my post above. It's required to give the -e flag, as it ignores whats in your ovpn file and overwrites it. If you leave it blank, you will give an error. I was proposing allowing us to manage it with the ovpn file so I don't have to keep rebuilding my docker containers if I want to use a different exit point with my provider. I'll probably just roll my own.

I'm trying to set up with a custom openvpn.ovpn configuration but find that it keeps being overwritten. From the logs:
   Env vars defined via docker -e flags for remote host, port and protocol, writing values to ovpn file...
If I remove these variables then I get the following error instead:
   [crit] VPN provider remote gateway not defined (via -e VPN_REMOTE), exiting...
If I set them to blank it still happens. Any clues as to what's going wrong here?

DZMM · October 5, 2016

I'm having another go at getting this working. If I set the VPN to 'no' I can access the WebUI, but with 'yes' I can't connect and I get the following error:

Tue Oct 4 09:43:49 2016 WARNING: file 'credentials.conf' is group or others accessible

I've seen a few other people post this error, but no solutions have been posted. Can someone help please.

that is purely a warning, so this is not the issue, please post the entire supervisord.log file (minus username and password), oh and change your vpn provider password, you have just posted it in clear text!.

whoops! Thanks for the heads up. Log attached

My output from 'ifconfig' looks strange and might provide some answers. My router is 192.168.1.254 and my server is connected to a wireless bridge 192.168.1.11 (basically a wifi repeater). All my internal IPs should be in the 192.168.1.0-253 range, but IP addressed starting 172.7.0.x keeps popping up in supervisord and ifconfig.

Looking at supervisord all seems to be working, but my iptables keep referencing 172.17.x.x not 192.168.x.x as I'd expect:

[info] iptables defined as follows...
--------------------


2016-10-02 23:56:28,864 DEBG 'start-script' 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 1198 -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 -s 192.168.1.0/24 -i eth0 -p tcp -m tcp --dport 58846 -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 1198 -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 -d 192.168.1.0/24 -o eth0 -p tcp -m tcp --sport 58846 -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

supervisord.txt

ifconfig.txt

binhex · October 5, 2016

I'm having another go at getting this working. If I set the VPN to 'no' I can access the WebUI, but with 'yes' I can't connect and I get the following error:

Tue Oct 4 09:43:49 2016 WARNING: file 'credentials.conf' is group or others accessible

I've seen a few other people post this error, but no solutions have been posted. Can someone help please.

that is purely a warning, so this is not the issue, please post the entire supervisord.log file (minus username and password), oh and change your vpn provider password, you have just posted it in clear text!.

whoops! Thanks for the heads up. Log attached

My output from 'ifconfig' looks strange and might provide some answers. My router is 192.168.1.254 and my server is connected to a wireless bridge 192.168.1.11 (basically a wifi repeater). All my internal IPs should be in the 192.168.1.0-253 range, but IP addressed starting 172.7.0.x keeps popping up in supervisord and ifconfig.

Looking at supervisord all seems to be working, but my iptables keep referencing 172.17.x.x not 192.168.x.x as I'd expect:
[info] iptables defined as follows...
--------------------


2016-10-02 23:56:28,864 DEBG 'start-script' 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 1198 -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 -s 192.168.1.0/24 -i eth0 -p tcp -m tcp --dport 58846 -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 1198 -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 -d 192.168.1.0/24 -o eth0 -p tcp -m tcp --sport 58846 -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

again this is normal behaviour, docker uses an internal ip range which is 172.17.x.x so the iptable entries are correct. i think i have found the issue, i noticed that the ip that resolves for nl.privateinternetaccess.com is incorrect for you, snip from logs:-

2016-10-04 10:02:01,081 DEBG 'start-script' stdout output:
Tue Oct  4 10:02:01 2016 UDPv4 link local: [undef]
Tue Oct  4 10:02:01 2016 UDPv4 link remote: [AF_INET]213.120.234.114:1198

so you can see the ip above, if you do a reverse dns lookup on this or use any of the web lookup tools you will find this ip is registered with BT, which is im assuming the ISP your with. So it looks like either BT are blocking or the parental blocking stuff that BT now do is redirecting/blocking you.

you could try specifying the ip rather than the name, not ideal of course as the ip might change but worth a go, try settings your VPN_REMOTE to 46.166.190.215 the other alternative is to try and switch off the parental controls and see if that stops this redirection.

DZMM · October 5, 2016

I think i have found the issue, i noticed that the ip that resolves for nl.privateinternetaccess.com is incorrect for you, snip from logs:-
2016-10-04 10:02:01,081 DEBG 'start-script' stdout output:
Tue Oct  4 10:02:01 2016 UDPv4 link local: [undef]
Tue Oct  4 10:02:01 2016 UDPv4 link remote: [AF_INET]213.120.234.114:1198
so you can see the ip above, if you do a reverse dns lookup on this or use any of the web lookup tools you will find this ip is registered with BT, which is im assuming the ISP your with. So it looks like either BT are blocking or the parental blocking stuff that BT now do is redirecting/blocking you.

you could try specifying the ip rather than the name, not ideal of course as the ip might change but worth a go, try settings your VPN_REMOTE to 46.166.190.215 the other alternative is to try and switch off the parental controls and see if that stops this redirection.

thanks that worked!

Weird though, as I can use the PIA client with no problems so for some reason my hub (unlikely) or my wireless bridge (likely as it's causing problems) is doing something weird. I'm changing the bridge tomorrow for a different model, so will see if this fixes the problem.

if it doesn't, I'm assuming that if PIA change their IP address all torrents will stop downloading?

binhex · October 5, 2016

I think i have found the issue, i noticed that the ip that resolves for nl.privateinternetaccess.com is incorrect for you, snip from logs:-
2016-10-04 10:02:01,081 DEBG 'start-script' stdout output:
Tue Oct  4 10:02:01 2016 UDPv4 link local: [undef]
Tue Oct  4 10:02:01 2016 UDPv4 link remote: [AF_INET]213.120.234.114:1198
so you can see the ip above, if you do a reverse dns lookup on this or use any of the web lookup tools you will find this ip is registered with BT, which is im assuming the ISP your with. So it looks like either BT are blocking or the parental blocking stuff that BT now do is redirecting/blocking you.

you could try specifying the ip rather than the name, not ideal of course as the ip might change but worth a go, try settings your VPN_REMOTE to 46.166.190.215 the other alternative is to try and switch off the parental controls and see if that stops this redirection.
thanks that worked!

Weird though, as I can use the PIA client with no problems so for some reason my hub (unlikely) or my wireless bridge (likely as it's causing problems) is doing something weird. I'm changing the bridge tomorrow for a different model, so will see if this fixes the problem.

if it doesn't, I'm assuming that if PIA change their IP address all torrents will stop downloading?

Yes

Sent from my SM-G900F using Tapatalk

lionizeme · October 8, 2016

I have been trying for the last few days with little luck. I can connect to the webui when VPN is DISABLED, but when I connect to the webui when the vpn is enabled I get: cannot find us-newyork.privateinternetaccess... So obviously the culprit is with the vpn config, but when I try to change them to the settings that worked with the Windows OpenVPN GUI it just overwrites them.

Is there a firewall thing that I am overlooking?

Merijeek · October 9, 2016

...can anyone give me some insight as to what might have caused this to start up today?

2016-10-08 20:59:57,882 DEBG 'start-script' stdout output:

Sat Oct 8 20:59:57 2016 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=US, ST=OH, L=Columbus, O=Private Internet Access, CN=Private Internet Access CA, [email protected]

Sat Oct 8 20:59:57 2016 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

Sat Oct 8 20:59:57 2016 TLS_ERROR: BIO read tls_read_plaintext error

Sat Oct 8 20:59:57 2016 TLS Error: TLS object -> incoming plaintext read error

Sat Oct 8 20:59:57 2016 TLS Error: TLS handshake failed

Flurocity · October 9, 2016

I'm having another go at getting this working. If I set the VPN to 'no' I can access the WebUI, but with 'yes' I can't connect and I get the following error:

Tue Oct 4 09:43:49 2016 WARNING: file 'credentials.conf' is group or others accessible

I've seen a few other people post this error, but no solutions have been posted. Can someone help please.

that is purely a warning, so this is not the issue, please post the entire supervisord.log file (minus username and password), oh and change your vpn provider password, you have just posted it in clear text!.

whoops! Thanks for the heads up. Log attached

My output from 'ifconfig' looks strange and might provide some answers. My router is 192.168.1.254 and my server is connected to a wireless bridge 192.168.1.11 (basically a wifi repeater). All my internal IPs should be in the 192.168.1.0-253 range, but IP addressed starting 172.7.0.x keeps popping up in supervisord and ifconfig.

Looking at supervisord all seems to be working, but my iptables keep referencing 172.17.x.x not 192.168.x.x as I'd expect:
[info] iptables defined as follows...
--------------------


2016-10-02 23:56:28,864 DEBG 'start-script' 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 1198 -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 -s 192.168.1.0/24 -i eth0 -p tcp -m tcp --dport 58846 -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 1198 -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 -d 192.168.1.0/24 -o eth0 -p tcp -m tcp --sport 58846 -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
again this is normal behaviour, docker uses an internal ip range which is 172.17.x.x so the iptable entries are correct. i think i have found the issue, i noticed that the ip that resolves for nl.privateinternetaccess.com is incorrect for you, snip from logs:-
2016-10-04 10:02:01,081 DEBG 'start-script' stdout output:
Tue Oct  4 10:02:01 2016 UDPv4 link local: [undef]
Tue Oct  4 10:02:01 2016 UDPv4 link remote: [AF_INET]213.120.234.114:1198
so you can see the ip above, if you do a reverse dns lookup on this or use any of the web lookup tools you will find this ip is registered with BT, which is im assuming the ISP your with. So it looks like either BT are blocking or the parental blocking stuff that BT now do is redirecting/blocking you.

you could try specifying the ip rather than the name, not ideal of course as the ip might change but worth a go, try settings your VPN_REMOTE to 46.166.190.215 the other alternative is to try and switch off the parental controls and see if that stops this redirection.

Hi,

Pretty sure i'm having the same issue as whats detailed above. How did you find the new VPN_REMOTE address of 46.166.190.215? I'm also trying to connect to PIA's Australian servers if that helps.

Thanks.

DZMM · October 9, 2016

I'm having another go at getting this working. If I set the VPN to 'no' I can access the WebUI, but with 'yes' I can't connect and I get the following error:

Tue Oct 4 09:43:49 2016 WARNING: file 'credentials.conf' is group or others accessible

I've seen a few other people post this error, but no solutions have been posted. Can someone help please.

that is purely a warning, so this is not the issue, please post the entire supervisord.log file (minus username and password), oh and change your vpn provider password, you have just posted it in clear text!.

whoops! Thanks for the heads up. Log attached

My output from 'ifconfig' looks strange and might provide some answers. My router is 192.168.1.254 and my server is connected to a wireless bridge 192.168.1.11 (basically a wifi repeater). All my internal IPs should be in the 192.168.1.0-253 range, but IP addressed starting 172.7.0.x keeps popping up in supervisord and ifconfig.

Looking at supervisord all seems to be working, but my iptables keep referencing 172.17.x.x not 192.168.x.x as I'd expect:
[info] iptables defined as follows...
--------------------


2016-10-02 23:56:28,864 DEBG 'start-script' 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 1198 -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 -s 192.168.1.0/24 -i eth0 -p tcp -m tcp --dport 58846 -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 1198 -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 -d 192.168.1.0/24 -o eth0 -p tcp -m tcp --sport 58846 -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
again this is normal behaviour, docker uses an internal ip range which is 172.17.x.x so the iptable entries are correct. i think i have found the issue, i noticed that the ip that resolves for nl.privateinternetaccess.com is incorrect for you, snip from logs:-
2016-10-04 10:02:01,081 DEBG 'start-script' stdout output:
Tue Oct  4 10:02:01 2016 UDPv4 link local: [undef]
Tue Oct  4 10:02:01 2016 UDPv4 link remote: [AF_INET]213.120.234.114:1198
so you can see the ip above, if you do a reverse dns lookup on this or use any of the web lookup tools you will find this ip is registered with BT, which is im assuming the ISP your with. So it looks like either BT are blocking or the parental blocking stuff that BT now do is redirecting/blocking you.

you could try specifying the ip rather than the name, not ideal of course as the ip might change but worth a go, try settings your VPN_REMOTE to 46.166.190.215 the other alternative is to try and switch off the parental controls and see if that stops this redirection.
Hi,

Pretty sure i'm having the same issue as whats detailed above. How did you find the new VPN_REMOTE address of 46.166.190.215? I'm also trying to connect to PIA's Australian servers if that helps.

Thanks.

I can connect to the webUI and when I use checkmytorrent it reports the VPN IP, so all looks good. I add the sock5 proxy settings as well though for a bit of insurance.

Flurocity · October 9, 2016

Mine doesn't let me connect to the webui at all when i enable the VPN, but seems to work fine with it disabled. Any other suggestions?

binhex · October 9, 2016

Mine doesn't let me connect to the webui at all when i enable the VPN, but seems to work fine with it disabled. Any other suggestions?

I would need supervisord.log for starters to try and diagnose the issue.

Sent from my SM-G900F using Tapatalk

DZMM · October 9, 2016

Mine doesn't let me connect to the webui at all when i enable the VPN, but seems to work fine with it disabled. Any other suggestions?

See my post above yours for a potential solution

Merijeek · October 9, 2016

Has something gone funny with PIA?

My installation (which I C&P when needed) looks like this:

oot@UnRAID:~# docker run -d \
>     --cap-add=NET_ADMIN \
>     -p 8112:8112 \
>     -p 8118:8118 \
>     --name=delugevpn \
>     -v /mnt/user/Incoming:/data \
>     -v /mnt/user/config/delugevpn:/config \
>     -v /etc/localtime:/etc/localtime:ro \
>     -e VPN_ENABLED=yes \
>     -e VPN_USER=XXXX \
>     -e VPN_PASS=XXXX \
>     -e VPN_REMOTE=nl.privateinternetaccess.com \
>     -e VPN_PORT=1194 \
>     -e VPN_PROTOCOL=udp \
>     -e VPN_PROV=pia \
>     -e ENABLE_PRIVOXY=yes \
>     -e LAN_NETWORK=192.168.1.0/24 \
>     -e DEBUG=false \
>     -e PUID=0 \
>     -e PGID=0 \
>     binhex/arch-delugevpn

However, the VPN is failing over and over because of a self-signed cert in the chain.

2016-10-09 10:15:41,184 DEBG 'start-script' stdout output:
Sun Oct  9 10:15:41 2016 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=US, ST=OH, L=Columbus, O=Private Internet Access, CN=Private Internet Access CA, [email protected]
Sun Oct  9 10:15:41 2016 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Sun Oct  9 10:15:41 2016 TLS_ERROR: BIO read tls_read_plaintext error
Sun Oct  9 10:15:41 2016 TLS Error: TLS object -> incoming plaintext read error
Sun Oct  9 10:15:41 2016 TLS Error: TLS handshake failed

I'm at a loss as to what to do here. It's not like I can do anything about PIA's cert chain. Is it possible to skip the verification? And even if I could, would I want to?

binhex · October 9, 2016

Has something gone funny with PIA?

My installation (which I C&P when needed) looks like this:

oot@UnRAID:~# docker run -d \
>     --cap-add=NET_ADMIN \
>     -p 8112:8112 \
>     -p 8118:8118 \
>     --name=delugevpn \
>     -v /mnt/user/Incoming:/data \
>     -v /mnt/user/config/delugevpn:/config \
>     -v /etc/localtime:/etc/localtime:ro \
>     -e VPN_ENABLED=yes \
>     -e VPN_USER=XXXX \
>     -e VPN_PASS=XXXX \
>     -e VPN_REMOTE=nl.privateinternetaccess.com \
>     -e VPN_PORT=1194 \
>     -e VPN_PROTOCOL=udp \
>     -e VPN_PROV=pia \
>     -e ENABLE_PRIVOXY=yes \
>     -e LAN_NETWORK=192.168.1.0/24 \
>     -e DEBUG=false \
>     -e PUID=0 \
>     -e PGID=0 \
>     binhex/arch-delugevpn

However, the VPN is failing over and over because of a self-signed cert in the chain.

2016-10-09 10:15:41,184 DEBG 'start-script' stdout output:
Sun Oct  9 10:15:41 2016 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=US, ST=OH, L=Columbus, O=Private Internet Access, CN=Private Internet Access CA, [email protected]
Sun Oct  9 10:15:41 2016 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Sun Oct  9 10:15:41 2016 TLS_ERROR: BIO read tls_read_plaintext error
Sun Oct  9 10:15:41 2016 TLS Error: TLS object -> incoming plaintext read error
Sun Oct  9 10:15:41 2016 TLS Error: TLS handshake failed

I'm at a loss as to what to do here. It's not like I can do anything about PIA's cert chain. Is it possible to skip the verification? And even if I could, would I want to?

Pia port has changed from 1194 to 1198

Sent from my SM-G900F using Tapatalk

Merijeek · October 9, 2016

Has something gone funny with PIA?

My installation (which I C&P when needed) looks like this:

oot@UnRAID:~# docker run -d \
>     --cap-add=NET_ADMIN \
>     -p 8112:8112 \
>     -p 8118:8118 \
>     --name=delugevpn \
>     -v /mnt/user/Incoming:/data \
>     -v /mnt/user/config/delugevpn:/config \
>     -v /etc/localtime:/etc/localtime:ro \
>     -e VPN_ENABLED=yes \
>     -e VPN_USER=XXXX \
>     -e VPN_PASS=XXXX \
>     -e VPN_REMOTE=nl.privateinternetaccess.com \
>     -e VPN_PORT=1194 \
>     -e VPN_PROTOCOL=udp \
>     -e VPN_PROV=pia \
>     -e ENABLE_PRIVOXY=yes \
>     -e LAN_NETWORK=192.168.1.0/24 \
>     -e DEBUG=false \
>     -e PUID=0 \
>     -e PGID=0 \
>     binhex/arch-delugevpn

However, the VPN is failing over and over because of a self-signed cert in the chain.

2016-10-09 10:15:41,184 DEBG 'start-script' stdout output:
Sun Oct  9 10:15:41 2016 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=US, ST=OH, L=Columbus, O=Private Internet Access, CN=Private Internet Access CA, [email protected]
Sun Oct  9 10:15:41 2016 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Sun Oct  9 10:15:41 2016 TLS_ERROR: BIO read tls_read_plaintext error
Sun Oct  9 10:15:41 2016 TLS Error: TLS object -> incoming plaintext read error
Sun Oct  9 10:15:41 2016 TLS Error: TLS handshake failed

I'm at a loss as to what to do here. It's not like I can do anything about PIA's cert chain. Is it possible to skip the verification? And even if I could, would I want to?

Pia port has changed from 1194 to 1198

Sent from my SM-G900F using Tapatalk

That did it. Thanks.

You think PIA's support people would be aware of this...

DDock · October 12, 2016

I'm having a strange issue. First, I am currently at work using a VPN to connect into my home network. I am connected just fine. I can use the docker just fine without VPN enabled. When I try and use it with VPN enabled to my Torguard account, I am unable to access using the LAN. Looking at the logs it seems to be restarting a bunch and I'm not quite sure why. Here is the output of my log, with the last two lines repeating. Here is also the OpenVPN config that Torguard gives me to use. Time codes on the last few lines are wrong - I did copy pasta from another log to show how it repeats.

Update, I've tried a few other things like changing the openvpn.opvn file to the one that Torguard supplies. I put the certificate in the openvpn folder. But still having the same issue.

client
dev tun
proto udp
remote chi.central.usa.torguardvpnaccess.com 1912
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
tls-auth ta.key 1
auth SHA256
cipher AES-128-CBC
remote-cert-tls server
auth-user-pass
comp-lzo
verb 1
reneg-sec 0
fast-io
# Uncomment these directives if you have speed issues
;sndbuf 393216
;rcvbuf 393216
;push "sndbuf 393216"
;push "rcvbuf 393216"

usermod: no changes
[info] Env var PUID defined as 99
[info] Env var PGID defined as 100
[info] Permissions already set for /config and /data
[info] Starting Supervisor...
2016-10-12 08:47:35,980 CRIT Set uid to user 0
2016-10-12 08:47:35,980 INFO Included extra file "/etc/supervisor/conf.d/delugevpn.conf" during parsing
2016-10-12 08:47:35,984 INFO supervisord started with pid 23
2016-10-12 08:47:36,985 INFO spawned: 'start-script' with pid 26
2016-10-12 08:47:36,986 INFO spawned: 'webui-script' with pid 27
2016-10-12 08:47:36,988 INFO spawned: 'deluge-script' with pid 28
2016-10-12 08:47:36,989 INFO spawned: 'privoxy-script' with pid 29
2016-10-12 08:47:36,999 DEBG 'privoxy-script' stdout output:
[info] VPN is enabled, checking VPN tunnel local ip is valid

2016-10-12 08:47:36,999 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2016-10-12 08:47:36,999 INFO success: webui-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2016-10-12 08:47:36,999 INFO success: deluge-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2016-10-12 08:47:36,999 INFO success: privoxy-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2016-10-12 08:47:37,000 DEBG 'deluge-script' stdout output:
[info] deluge config file already exists, skipping copy

2016-10-12 08:47:37,000 DEBG 'deluge-script' stdout output:
[info] VPN is enabled, checking VPN tunnel local ip is valid

2016-10-12 08:47:37,003 DEBG 'start-script' stdout output:
[info] VPN is enabled, beginning configuration of VPN

2016-10-12 08:47:37,014 DEBG 'start-script' stdout output:
[info] VPN provider defined as custom
[info] VPN config file (ovpn extension) is located at /config/openvpn/openvpn.ovpn

2016-10-12 08:47:37,017 DEBG 'start-script' stdout output:
[info] Env vars defined via docker -e flags for remote host, port and protocol, writing values to ovpn file...

2016-10-12 08:47:37,031 DEBG 'start-script' stdout output:
[info] VPN provider remote gateway defined as chi.central.usa.torguardvpnaccess.com
[info] VPN provider remote port defined as 1912
[info] VPN provider remote protocol defined as udp

2016-10-12 08:47:37,040 DEBG 'start-script' stdout output:
[info] VPN provider username defined as <EMAIL>

2016-10-12 08:47:37,045 DEBG 'start-script' stdout output:
[warn] Username contains characters which could cause authentication issues, please consider changing this if possible

2016-10-12 08:47:37,049 DEBG 'start-script' stdout output:
[info] VPN provider password defined as <PASSWORD>

2016-10-12 08:47:37,054 DEBG 'start-script' stdout output:
[warn] Password contains characters which could cause authentication issues, please consider changing this if possible

2016-10-12 08:47:37,076 DEBG 'start-script' stdout output:
[info] Default route for container is 172.17.0.1

2016-10-12 08:47:37,084 DEBG 'start-script' stdout output:
[info] Setting permissions recursively on /config/openvpn...

2016-10-12 08:47:37,095 DEBG 'start-script' stdout output:
[info] Adding 10.32.87.0/24 as route via docker eth0

2016-10-12 08:47:37,095 DEBG 'start-script' stdout output:
[info] ip route defined as follows...
--------------------

2016-10-12 08:47:37,096 DEBG 'start-script' stdout output:
default via 172.17.0.1 dev eth0
10.##.##.0/24 via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.4

2016-10-12 08:47:37,096 DEBG 'start-script' stdout output:
--------------------

2016-10-12 08:47:37,100 DEBG 'start-script' stdout output:
[info] iptable_mangle support detected, adding fwmark for tables

2016-10-12 08:47:37,133 DEBG 'start-script' stdout output:
[info] iptables defined as follows...
--------------------

2016-10-12 08:47:37,135 DEBG 'start-script' 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 1912 -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 -s 10.##.##.0/24 -i eth0 -p tcp -m tcp --dport 58846 -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 1912 -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 -d 10.##.##.0/24 -o eth0 -p tcp -m tcp --sport 58846 -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-10-12 08:47:37,135 DEBG 'start-script' stdout output:
--------------------

2016-10-12 08:47:37,135 DEBG 'start-script' stdout output:
[info] nameservers

2016-10-12 08:47:37,136 DEBG 'start-script' stdout output:
nameserver 8.8.8.8
nameserver 8.8.4.4

2016-10-12 08:47:37,136 DEBG 'start-script' stdout output:
--------------------
[info] Starting OpenVPN...

2016-10-12 08:47:37,142 DEBG 'start-script' stdout output:
Wed Oct 12 08:47:37 2016 OpenVPN 2.3.11 x86_64-unknown-linux-gnu [sSL (OpenSSL)] [LZO] [EPOLL] [MH] [iPv6] built on May 12 2016
Wed Oct 12 08:47:37 2016 library versions: OpenSSL 1.0.2h 3 May 2016, LZO 2.09
Wed Oct 12 08:47:37 2016 WARNING: file 'credentials.conf' is group or others accessible


2016-10-12 08:47:37,185 DEBG 'start-script' stdout output:
Wed Oct 12 08:47:37 2016 UDPv4 link local: [undef]
Wed Oct 12 08:47:37 2016 UDPv4 link remote: [AF_INET]104.129.28.154:1912

2016-10-12 08:53:52,101 DEBG 'start-script' stdout output:
Wed Oct 12 08:53:52 2016 [uNDEF] Inactivity timeout (--ping-restart), restarting
Wed Oct 12 08:53:52 2016 SIGUSR1[soft,ping-restart] received, process restarting

2016-10-12 08:53:54,154 DEBG 'start-script' stdout output:
Wed Oct 12 08:53:54 2016 UDPv4 link local: [undef]
Wed Oct 12 08:53:54 2016 UDPv4 link remote: [AF_INET]104.129.29.2:1912

kbb2002 · October 12, 2016

After upgrading the docker today it will not connect to PIA. With it in this state i cannot access the webui. If i set VPN_ENABLED to no then the webui will work. Ive tried deleting the openvpn folder and letting the docker create it again, thinking it might be a permissions issue. It recreated it but i still get the same errors. Here are the errors im getting.

2016-10-12 04:49:26,745 DEBG 'start-script' stdout output:

Wed Oct 12 04:49:26 2016 UDPv4 link local: [undef]

Wed Oct 12 04:49:26 2016 UDPv4 link remote: [AF_INET]104.200.153.104:1194

2016-10-12 04:49:26,757 DEBG 'start-script' stdout output:

Wed Oct 12 04:49:26 2016 WARNING: file 'credentials.conf' is group or others accessible

2016-10-12 04:49:26,776 DEBG 'start-script' stdout output:

Wed Oct 12 04:49:26 2016 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=US, ST=OH, L=Columbus, O=Private Internet Access, CN=Private Internet Access CA, [email protected]

Wed Oct 12 04:49:26 2016 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

Wed Oct 12 04:49:26 2016 TLS_ERROR: BIO read tls_read_plaintext error

Wed Oct 12 04:49:26 2016 TLS Error: TLS object -> incoming plaintext read error

Wed Oct 12 04:49:26 2016 TLS Error: TLS handshake failed

2016-10-12 04:49:26,777 DEBG 'start-script' stdout output:

Wed Oct 12 04:49:26 2016 SIGUSR1[soft,tls-error] received, process restarting

Any Help would be appreciated.

Merijeek · October 12, 2016

Look a couple posts above you. I had the exact same issue. PIA port number changed.

kbb2002 · October 12, 2016

Changing from port 1194 to 1198 fixed PIA. Thanks!!!

grantbey · October 13, 2016

I'm having some trouble getting the downloads to go to the correct folder.

I have the following mappings:

/data -> /mnt/user/deluge

/config -> /mnt/user/appdata/deluge

My core.conf file has the following entries (in their correct positions in the file):

"download_location": "/data/incompleted"

"move_completed_path": "/data/complete"

"autoadd_location": "/data/torrent-files"

Yet still new downloads are downloaded in /home/nobody/Incompletes. I've checked the permissions of the /data folder multiple times, they're owned by nobody:users (99:100) which is the user deluge runs under.

Deluge seems to willfully ignore my instructions for some reason. Weirdly, completed downloads are moving correctly. I just don't want incomplete downloads to accumulate inside the docker image.

Does anyone have any ideas?

mr-hexen · October 13, 2016

Have you tried setting those from within the deluge web interface rather then editting the .conf?

JonathanM · October 13, 2016

I'm having some trouble getting the downloads to go to the correct folder.

Does anyone have any ideas?

Is this for manually added torrents, or automatically sent from another application like sonarr?

grantbey · October 13, 2016

Have you tried setting those from within the deluge web interface rather then editting the .conf?

Yes, I originally set it from the web interface. I double checked that the core.conf file was being updated by the web interface too.

I'm having some trouble getting the downloads to go to the correct folder.

Does anyone have any ideas?

Is this for manually added torrents, or automatically sent from another application like sonarr?

Good catch: this has been using DelugeSiphon to handle magnet links. Adding .torrent files to the watched folder results in correct behaviour.

Follow up question: how do I use DelugeSiphon, or is there a better chrome extension that others use?

Thanks!!

DDock · October 13, 2016

Seems like this may have been skipped over, I still have this issue. Is there anyone that could assist?

I'm having a strange issue. First, I am currently at work using a VPN to connect into my home network. I am connected just fine. I can use the docker just fine without VPN enabled. When I try and use it with VPN enabled to my Torguard account, I am unable to access using the LAN. Looking at the logs it seems to be restarting a bunch and I'm not quite sure why. Here is the output of my log, with the last two lines repeating. Here is also the OpenVPN config that Torguard gives me to use. Time codes on the last few lines are wrong - I did copy pasta from another log to show how it repeats.

Update, I've tried a few other things like changing the openvpn.opvn file to the one that Torguard supplies. I put the certificate in the openvpn folder. But still having the same issue.

client
dev tun
proto udp
remote chi.central.usa.torguardvpnaccess.com 1912
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
tls-auth ta.key 1
auth SHA256
cipher AES-128-CBC
remote-cert-tls server
auth-user-pass
comp-lzo
verb 1
reneg-sec 0
fast-io
# Uncomment these directives if you have speed issues
;sndbuf 393216
;rcvbuf 393216
;push "sndbuf 393216"
;push "rcvbuf 393216"

usermod: no changes
[info] Env var PUID defined as 99
[info] Env var PGID defined as 100
[info] Permissions already set for /config and /data
[info] Starting Supervisor...
2016-10-12 08:47:35,980 CRIT Set uid to user 0
2016-10-12 08:47:35,980 INFO Included extra file "/etc/supervisor/conf.d/delugevpn.conf" during parsing
2016-10-12 08:47:35,984 INFO supervisord started with pid 23
2016-10-12 08:47:36,985 INFO spawned: 'start-script' with pid 26
2016-10-12 08:47:36,986 INFO spawned: 'webui-script' with pid 27
2016-10-12 08:47:36,988 INFO spawned: 'deluge-script' with pid 28
2016-10-12 08:47:36,989 INFO spawned: 'privoxy-script' with pid 29
2016-10-12 08:47:36,999 DEBG 'privoxy-script' stdout output:
[info] VPN is enabled, checking VPN tunnel local ip is valid

2016-10-12 08:47:36,999 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2016-10-12 08:47:36,999 INFO success: webui-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2016-10-12 08:47:36,999 INFO success: deluge-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2016-10-12 08:47:36,999 INFO success: privoxy-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2016-10-12 08:47:37,000 DEBG 'deluge-script' stdout output:
[info] deluge config file already exists, skipping copy

2016-10-12 08:47:37,000 DEBG 'deluge-script' stdout output:
[info] VPN is enabled, checking VPN tunnel local ip is valid

2016-10-12 08:47:37,003 DEBG 'start-script' stdout output:
[info] VPN is enabled, beginning configuration of VPN

2016-10-12 08:47:37,014 DEBG 'start-script' stdout output:
[info] VPN provider defined as custom
[info] VPN config file (ovpn extension) is located at /config/openvpn/openvpn.ovpn

2016-10-12 08:47:37,017 DEBG 'start-script' stdout output:
[info] Env vars defined via docker -e flags for remote host, port and protocol, writing values to ovpn file...

2016-10-12 08:47:37,031 DEBG 'start-script' stdout output:
[info] VPN provider remote gateway defined as chi.central.usa.torguardvpnaccess.com
[info] VPN provider remote port defined as 1912
[info] VPN provider remote protocol defined as udp

2016-10-12 08:47:37,040 DEBG 'start-script' stdout output:
[info] VPN provider username defined as <EMAIL>

2016-10-12 08:47:37,045 DEBG 'start-script' stdout output:
[warn] Username contains characters which could cause authentication issues, please consider changing this if possible

2016-10-12 08:47:37,049 DEBG 'start-script' stdout output:
[info] VPN provider password defined as <PASSWORD>

2016-10-12 08:47:37,054 DEBG 'start-script' stdout output:
[warn] Password contains characters which could cause authentication issues, please consider changing this if possible

2016-10-12 08:47:37,076 DEBG 'start-script' stdout output:
[info] Default route for container is 172.17.0.1

2016-10-12 08:47:37,084 DEBG 'start-script' stdout output:
[info] Setting permissions recursively on /config/openvpn...

2016-10-12 08:47:37,095 DEBG 'start-script' stdout output:
[info] Adding 10.32.87.0/24 as route via docker eth0

2016-10-12 08:47:37,095 DEBG 'start-script' stdout output:
[info] ip route defined as follows...
--------------------

2016-10-12 08:47:37,096 DEBG 'start-script' stdout output:
default via 172.17.0.1 dev eth0
10.##.##.0/24 via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.4

2016-10-12 08:47:37,096 DEBG 'start-script' stdout output:
--------------------

2016-10-12 08:47:37,100 DEBG 'start-script' stdout output:
[info] iptable_mangle support detected, adding fwmark for tables

2016-10-12 08:47:37,133 DEBG 'start-script' stdout output:
[info] iptables defined as follows...
--------------------

2016-10-12 08:47:37,135 DEBG 'start-script' 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 1912 -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 -s 10.##.##.0/24 -i eth0 -p tcp -m tcp --dport 58846 -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 1912 -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 -d 10.##.##.0/24 -o eth0 -p tcp -m tcp --sport 58846 -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-10-12 08:47:37,135 DEBG 'start-script' stdout output:
--------------------

2016-10-12 08:47:37,135 DEBG 'start-script' stdout output:
[info] nameservers

2016-10-12 08:47:37,136 DEBG 'start-script' stdout output:
nameserver 8.8.8.8
nameserver 8.8.4.4

2016-10-12 08:47:37,136 DEBG 'start-script' stdout output:
--------------------
[info] Starting OpenVPN...

2016-10-12 08:47:37,142 DEBG 'start-script' stdout output:
Wed Oct 12 08:47:37 2016 OpenVPN 2.3.11 x86_64-unknown-linux-gnu [sSL (OpenSSL)] [LZO] [EPOLL] [MH] [iPv6] built on May 12 2016
Wed Oct 12 08:47:37 2016 library versions: OpenSSL 1.0.2h 3 May 2016, LZO 2.09
Wed Oct 12 08:47:37 2016 WARNING: file 'credentials.conf' is group or others accessible


2016-10-12 08:47:37,185 DEBG 'start-script' stdout output:
Wed Oct 12 08:47:37 2016 UDPv4 link local: [undef]
Wed Oct 12 08:47:37 2016 UDPv4 link remote: [AF_INET]104.129.28.154:1912

2016-10-12 08:53:52,101 DEBG 'start-script' stdout output:
Wed Oct 12 08:53:52 2016 [uNDEF] Inactivity timeout (--ping-restart), restarting
Wed Oct 12 08:53:52 2016 SIGUSR1[soft,ping-restart] received, process restarting

2016-10-12 08:53:54,154 DEBG 'start-script' stdout output:
Wed Oct 12 08:53:54 2016 UDPv4 link local: [undef]
Wed Oct 12 08:53:54 2016 UDPv4 link remote: [AF_INET]104.129.29.2:1912

mr-hexen · October 13, 2016

Have you tried setting those from within the deluge web interface rather then editting the .conf?

Yes, I originally set it from the web interface. I double checked that the core.conf file was being updated by the web interface too.

I'm having some trouble getting the downloads to go to the correct folder.

Does anyone have any ideas?

Is this for manually added torrents, or automatically sent from another application like sonarr?

Good catch: this has been using DelugeSiphon to handle magnet links. Adding .torrent files to the watched folder results in correct behaviour.

Follow up question: how do I use DelugeSiphon, or is there a better chrome extension that others use?

Thanks!!

I just copy/paste the links into Deluge "+Add" button.

[Support] binhex - DelugeVPN

Recommended Posts

Link to comment

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

Ryanoc3ros

Dad_Rage

binhex

Posted Images

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Join the conversation