[Support] binhex - DelugeVPN


Recommended Posts

53 minutes ago, binhex said:

 

excellent :-), ok should you be using ssl, most definitely if your allowing access to the webui from outside, otherwise your password is not encrypted, again a valid ssl cert is the way to go, the one that is included is purely there as a convenience to get it working (self signed), if you really want to be secure then buy a cert or consider using letsencrypt (google it).

OK ill look in to it. As of right now I can only access it locally I believe.

Thanks again!

Link to comment
9 hours ago, binhex said:

logs please guys, i can only guess without them, switch DEBUG to true, restart the container and wait a few mins and then post the log (watch out for passwords).

 

How do you turn on debug mode and get access to the correct log file?

 

(the https fix didnt work for me, nor did using a different device)

Link to comment

I've read a whole bunch of this thread and I can't figure this out.  I'm trying to connect to my provider - VPNSecure.me

..

edit:  figured out that output that was here before.. problem was I changed some variables and it reloaded the docker and replaced all the certs and stuff.  But now I'm getting this error

 

[debug] Waiting for valid IP address from tunnel...

Tue Apr  4 18:19:50 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Apr  4 18:19:50 2017 neither stdin nor stderr are a tty device and you have neither a controlling tty nor systemd - can't ask for 'Enter Private Key Password:'.  If you used --daemon, you need to use --askpass to make passphrase-protected keys work, and you can not use --auth-nocache.
Tue Apr  4 18:19:50 2017 Exiting due to fatal error

how do I un-password protect a cert :|

Edited by danith
changed things
Link to comment
46 minutes ago, danith said:

I've read a whole bunch of this thread and I can't figure this out.  I'm trying to connect to my provider - VPNSecure.me

..

edit:  figured out that output that was here before.. problem was I changed some variables and it reloaded the docker and replaced all the certs and stuff.  But now I'm getting this error

 


[debug] Waiting for valid IP address from tunnel...

Tue Apr  4 18:19:50 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Apr  4 18:19:50 2017 neither stdin nor stderr are a tty device and you have neither a controlling tty nor systemd - can't ask for 'Enter Private Key Password:'.  If you used --daemon, you need to use --askpass to make passphrase-protected keys work, and you can not use --auth-nocache.
Tue Apr  4 18:19:50 2017 Exiting due to fatal error

how do I un-password protect a cert :|

 

 

For anyone else with this, make a file with the password in /config/openvpn/, then in the docker settings set the VPN_OPTIONS key to --askpass /config/openvpn/<file with the password in it>

Link to comment
8 hours ago, danith said:

 

 

For anyone else with this, make a file with the password in /config/openvpn/, then in the docker settings set the VPN_OPTIONS key to --askpass /config/openvpn/<file with the password in it>

 

interesting!, so does this actually prevent any prompt to type the pass phrase for the private key then?.

Link to comment
7 hours ago, binhex said:

 

interesting!, so does this actually prevent any prompt to type the pass phrase for the private key then?.

 

Yup!  After a bunch of googling I ran into this page http://stackoverflow.com/questions/11240184/pass-private-key-password-to-openvpn-command-directly-in-ubuntu-10-10 which said the --askpass <password file> thing was added in openvpn 2.0 beta so I tried it out and it worked.

 

I can get logs with it off and on if you need them.  Maybe you can add that flag as a part of the docker container? :P

 

 

Edited by danith
Link to comment

Well, shit, it's my turn.

 

Had to reboot today and it won't come up.  I don't see any error in the logs, just this coming over and over:

Thu Apr  6 23:23:12 2017 Server poll timeout, restarting
Thu Apr  6 23:23:12 2017 SIGUSR1[soft,server_poll] received, process restarting
Thu Apr  6 23:23:12 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Thu Apr  6 23:23:12 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]91.231.84.93:1194
Thu Apr  6 23:23:12 2017 Socket Buffers: R=[212992->212992] S=[212992->212992]
Thu Apr  6 23:23:12 2017 UDP link local: (not bound)
Thu Apr  6 23:23:12 2017 UDP link remote: [AF_INET]91.231.84.93:1194

I can ping the VPN server with IP and FQDN.  I don't see more when I try the command manually.  I redownloaded the .ovpn files from my provider.  There were a few differences but it didn't help.  I tried other VPN servers from my provider with the same result. I'm stumped.

supervisord.1.log

Link to comment
10 hours ago, Gog said:

Well, shit, it's my turn.

 

Had to reboot today and it won't come up.  I don't see any error in the logs, just this coming over and over:


Thu Apr  6 23:23:12 2017 Server poll timeout, restarting
Thu Apr  6 23:23:12 2017 SIGUSR1[soft,server_poll] received, process restarting
Thu Apr  6 23:23:12 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Thu Apr  6 23:23:12 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]91.231.84.93:1194
Thu Apr  6 23:23:12 2017 Socket Buffers: R=[212992->212992] S=[212992->212992]
Thu Apr  6 23:23:12 2017 UDP link local: (not bound)
Thu Apr  6 23:23:12 2017 UDP link remote: [AF_INET]91.231.84.93:1194

I can ping the VPN server with IP and FQDN.  I don't see more when I try the command manually.  I redownloaded the .ovpn files from my provider.  There were a few differences but it didn't help.  I tried other VPN servers from my provider with the same result. I'm stumped.

supervisord.1.log

 

looking at the log it looks like your specifying the wrong port number, you define it as:-

 

Quote

2017-04-06 23:13:55.537475 [info] VPN_PORT defined as '1194'

 

whereas the entry in the ovpn config file is:-

 

Quote

# Disabled, as we pass this value via env var
;remote ua1.ibvpn.com 1196 udp

 

so try defining VPN_PORT as 1196.

Link to comment
1 hour ago, binhex said:

 

looking at the log it looks like your specifying the wrong port number, you define it as:-

 

 

whereas the entry in the ovpn config file is:-

 

 

so try defining VPN_PORT as 1196.

 

&*(?$&/$ I swear I checked that.

 

Why the hell would that change???

 

Anyway, thanks for the catch, I'll try that tonight.

Link to comment

The sneaky bastards changed the port!

 

I redownloaded the .ovpn package last night and the one I was using before used 1194 and the new one I downloaded uses 1196.

 

My old one probably kept working until I disconnected and the server ignored me when I tried to reconnect on 1194.

 

It was not all because of what's sitting in my chair!

Link to comment

Are you kidding?  I try to help here and I'm a bona fide bonehead!

 

You configured the right port?  device type?  LAN_NETWORK address?

 

Stop the docker, set debug to true, delete the supervisor.log file, start the docker, wait 5 minutes, edit supervisor.log to remove your username and password and post it here.

Link to comment

 

Log Attached.

 

Port is 1194 (matches the details in the opvn file) 

LAN is: 192.168.1.0/24

 

Ifconfig

bond0: flags=5443<UP,BROADCAST,RUNNING,PROMISC,MASTER,MULTICAST>  mtu 1500
        ether 0c:c4:7a:32:b9:28  txqueuelen 1000  (Ethernet)
        RX packets 95157076  bytes 88056300405 (82.0 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 100092377  bytes 102601565242 (95.5 GiB)
        TX errors 0  dropped 4 overruns 0  carrier 0  collisions 0

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.115  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 0c:c4:7a:32:b9:28  txqueuelen 1000  (Ethernet)
        RX packets 91944186  bytes 86471152251 (80.5 GiB)
        RX errors 0  dropped 203992  overruns 0  frame 0
        TX packets 58758068  bytes 100176256678 (93.2 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 0.0.0.0
        ether 02:42:92:61:a3:0b  txqueuelen 0  (Ethernet)
        RX packets 30771753  bytes 3708319752 (3.4 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 50966143  bytes 73917106132 (68.8 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
        ether 0c:c4:7a:32:b9:28  txqueuelen 1000  (Ethernet)
        RX packets 95157076  bytes 88056300405 (82.0 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 100092377  bytes 102601565242 (95.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xf7400000-f747ffff

eth1: flags=6147<UP,BROADCAST,SLAVE,MULTICAST>  mtu 1500
        ether 0c:c4:7a:32:b9:28  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xf7300000-f737ffff

 

 

 

Any ideas on why the GUI is not working would be appreciated. 

 

Clipboard01.gif

supervisord.log

Link to comment
4 minutes ago, TexasDave said:

Any ideas on why the GUI is not working would be appreciated. 

 

Clipboard01.gif

supervisord.log

 

It looks like your VPN credentials are not valid:

AUTH: Received control message: AUTH_FAILED

 

Not related but it looks like the ifconfig you posted are straight from the unraid server.  To know it the vpn network interface is up, you need to run it from inside the docker, like so:

 

docker exec -it binhex-delugevpn bash
ifconfig

 

  • Upvote 1
Link to comment
Just now, TexasDave said:

@Gog - you nailed it - Thanks!

 

My account value was wrong. This service has another user name for VPN and I was using the account for the smartDNS service they provide. That sorted it. I told you I was a bonehead. :D

 

There is a bonehead in each of us.  The role of the computer is to make it shine!

Link to comment
The sneaky bastards changed the port!
 
I redownloaded the .ovpn package last night and the one I was using before used 1194 and the new one I downloaded uses 1196.
 
My old one probably kept working until I disconnected and the server ignored me when I tried to reconnect on 1194.
 
It was not all because of what's sitting in my chair!

Ah nice to know you aren't going mad eh :-) thanks for the beer money.

Sent from my SM-G900F using Tapatalk

  • Upvote 1
Link to comment

Edit: I'm stupid. My ip had same first digits as VPN and thus causing me think vpn was disabled. Thanks to binhex for help.

 

Hi, I have a major concern. I have been using this docker with PIA for about 6 months. To make sure I'm connected via VPN I have been using a torrent which reponds with your IP as tracker status ( checkmytorrentip.net). At a few start ups after system reboot the VPN did not connect. I solved this quickly by rebooting the docker and check that it connected correctly.

 

Today I checked into my deluge client and started the check ip torrent. Then I noticed that it was connected without using VPN. It has been running for two weeks plus without a check and potentially that long without a VPN. Should there not be a kill switch if VPN disconnects, and then try to reconnect?

 

Link to comment
13 minutes ago, SM411 said:

Hi, I have a major concern. I have been using this docker with PIA for about 6 months. To make sure I'm connected via VPN I have been using a torrent which reponds with your IP as tracker status ( checkmytorrentip.net). At a few start ups after system reboot the VPN did not connect. I solved this quickly by rebooting the docker and check that it connected correctly.

 

Today I checked into my deluge client and started the check ip torrent. Then I noticed that it was connected without using VPN. It has been running for two weeks plus without a check and potentially that long without a VPN. Should there not be a kill switch if VPN disconnects, and then try to reconnect?

 

hi, its not technically possible for the deluge daemon and webui to start if the tunnel isnt up, its coded in such a way that this just cant happen. secondly its secure with ip tables to prevent ip leakage when the tunnel does go down, so in essence it does have a kill switch built in. so  please could you supply me with screenshots of your deluge webui showing your isp's ip address, and supervisord.log file (located in /config) and your docker run command, pm me these if you feel uncomfortable with posting these here

 

Im assuming you dont have 'VPN_ENABLED' set to 'no' right?.

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.