Add support for more VPN providers #22

haugene · 2015-08-07T23:29:58Z

Support for more OpenVPN providers, other than PIA, was proposed in the comments on the Docker registry.

The container should be expanded so that the OpenVPN provider is customizable and the solution should make it as easy and flexible as possible to add more providers later.

An implementation has been done on the dev branch, awaiting some testing before merging to master.

Bumped to version 1.2 after changes for issue #22

raidersan · 2015-08-08T11:23:32Z

Hi Kristian, many thanks for doing this. I get the following error:

VPN PROVIDER: BTGUARD
No VPN configuration provided. Using default.
Setting OPENVPN credentials...
Sat Aug 8 12:20:38 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Sat Aug 8 12:20:38 2015 WARNING: file '/config/openvpn-credentials.txt' is group or others accessible
Sat Aug 8 12:20:38 2015 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Sat Aug 8 12:20:38 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat Aug 8 12:20:38 2015 Socket Buffers: R=[212992->131072] S=[212992->131072]
Sat Aug 8 12:20:38 2015 UDPv4 link local: [undef]
Sat Aug 8 12:20:38 2015 UDPv4 link remote: [AF_INET]109.201.137.166:1194
Sat Aug 8 12:20:38 2015 TLS: Initial packet from [AF_INET]109.201.137.166:1194, sid=fd2b08d9 9b8cc476
Sat Aug 8 12:20:38 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Aug 8 12:20:38 2015 VERIFY OK: depth=1, C=DE, ST=Hesse-Nassau, L=Frankfurt, O=BTGuard, CN=BTGuard CA, emailAddress=[email protected]
Sat Aug 8 12:20:38 2015 VERIFY OK: depth=0, C=DE, ST=Hesse-Nassau, L=Frankfurt, O=BTGuard, CN=server, emailAddress=[email protected]
Sat Aug 8 12:20:38 2015 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Aug 8 12:20:38 2015 NOTE: --mute triggered...
Sat Aug 8 12:20:38 2015 4 variation(s) on previous 3 message(s) suppressed by --mute
Sat Aug 8 12:20:38 2015 [server] Peer Connection Initiated with [AF_INET]109.201.137.166:1194
Sat Aug 8 12:20:40 2015 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Sat Aug 8 12:20:40 2015 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,redirect-gateway,route 10.10.10.1,topology net30,ping 10,ping-restart 120,ifconfig 10.10.10.122 10.10.10.121'
Sat Aug 8 12:20:40 2015 OPTIONS IMPORT: timers and/or timeouts modified
Sat Aug 8 12:20:40 2015 NOTE: --mute triggered...
Sat Aug 8 12:20:40 2015 3 variation(s) on previous 3 message(s) suppressed by --mute
Sat Aug 8 12:20:40 2015 ROUTE_GATEWAY 172.17.42.1/255.255.0.0 IFACE=eth0 HWADDR=02:42:ac:11:00:08
Sat Aug 8 12:20:40 2015 ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)
Sat Aug 8 12:20:40 2015 Exiting due to fatal error

haugene · 2015-08-08T11:31:40Z

Hmm. Which command are you using to run this container? Are you providing the --privileged flag?

raidersan · 2015-08-08T11:53:44Z

I run from the UNRAID NAS system. I have got privilged on, yes
Here is the command (user and pwd obfuscated):

/usr/bin/docker run -d --name="TransmissionVPNDEV" --net="bridge" --privileged="true" -e OPENVPN_PROVIDER="BTGUARD" -e OPENVPN_USERNAME="xxxxx" -e OPENVPN_PASSWORD="xxxxxxx" -e TZ="Europe/London" -p 9092:9092/tcp -p 54322:54322/tcp -v "/mnt/user/Downloads/":"/mnt/user/Downloads/":rw -v "/mnt/cache/.apps/transmissionVPN":"/config":rw haugene/transmission-openvpn:dev

haugene · 2015-08-08T12:49:58Z

Ok. The reason I asked was that I reproduced the error message by switching off privileged here. But if you have that flag it's not that.

I see that others have the same problem with OpenVPN in docker:
kylemanna/docker-openvpn#39
http://serverfault.com/questions/429461/no-tun-device-in-lxc-guest-for-openvpn

It seems it might have to do with your host platform or kernel version. Does the /dev/net/tun device exist on your host? The privileged flag is necessary to modify the tun device on the host machine. So when I switch my privileged flag off I get the same error, but I guess that your error comes because it actually isn't there.

haugene · 2015-08-08T13:31:16Z

And btw. It should not have anything to do with this error but you should probably change your volume mount from -v "/mnt/user/Downloads/":"/mnt/user/Downloads/":rw to -v "/mnt/user/Downloads/":"/data":rw

This is because the container will store stuff in /data. Also you shouldn't have to mount anything to the /config directory if you don't have some plan for it. It's only a directory for storing transmission and openvpn credentials but it will be rewritten on each container startup as these are read from environment variables. Don't think you need the --net="bridge" either, but all this comes second to getting your /dev/net/tun device up and running.

raidersan · 2015-08-08T13:57:32Z

I am going to try to sound not too stupid here!
UNRAID is based on slackware and I have a 4.0.4 kernel through the 6.0.1 release of UNRAID.
The full name is as follows

Linux version 4.0.4-unRAID (root@develop64) (gcc version 4.8.2 (GCC) ) #5 SMP PREEMPT Fri Jun 19 22:47:24 PDT 2015

I have played in the past (before Docker) with an openvpn plugin and that worked, but I didn't want the whole machine going through the tunnel, and Docker suddenly open the possibilities

Here is my list of devices:

ls /dev
X0R@ fd@ loop1 memory_bandwidth nbd4 pts/ sda sg2 tty12 tty23 tty34 tty45 tty56 ttyS0 vcs10 vcsa5
aer_inject full loop2 mouse@ nbd5 ptyp0 sda1 sg3 tty13 tty24 tty35 tty46 tty57 ttyp0 vcs2 vcsa6
block/ fuse loop3 nbd0 nbd6 ptyp1 sdb sg4 tty14 tty25 tty36 tty47 tty58 ttyp1 vcs3 vfio /bsg/ hpet loop4 nbd1 nbd7 ptyp2 sdb1 shm/ tty15 tty26 tty37 tty48 tty59 ttyp2 vcs4 vga_arbiter
btrfs-control hwrng loop5 nbd10 nbd8 ptyp3 sdc stderr@ tty16 tty27 tty38 tty49 tty6 ttyp3 vcs5 vhost-net
bus/ initctl| loop6 nbd11 nbd9 ptyp4 sdc1 stdin@ tty17 tty28 tty39 tty5 tty60 ttyp4 vcs6 xconsole|
char/ input/ loop7 nbd12 network_latency ptyp5 sdd stdout@ tty18 tty29 tty4 tty50 tty61 ttyp5 vcsa zero
console kmem mapper/ nbd13 network_throughput ptyp6 sdd1 tty tty19 tty3 tty40 tty51 tty62 ttyp6 vcsa1
core@ kmsg mcelog nbd14 null ptyp7 sde tty0 tty2 tty30 tty41 tty52 tty63 ttyp7 vcsa10
cpu/ log= md1 nbd15 port random sde1 tty1 tty20 tty31 tty42 tty53 tty7 urandom vcsa2
cpu_dma_latency loop-control md2 nbd2 ppp rtc@ sg0 tty10 tty21 tty32 tty43 tty54 tty8 vcs vcsa3
disk/ loop0 mem nbd3 ptmx rtc0 sg1 tty11 tty22 tty33 tty44 tty55 tty9 vcs1 vcsa4

tun is not there but I always assumed it was created on the fly by openvpn??

haugene · 2015-08-08T14:27:56Z

I'm not sure here either. I think the OpenVPN inside the container will create a tun interface, namely tun0. But to do so it needs to modify the tun device on the host.

So I guess you need to have the TUN/TAP driver installed. Maybe if you install the openvpn plugin then that will also install the necessary drivers? You will not be using the OpenVPN plugin itself but that might create the needed /dev/net/tun device.

If not you have to try to create the device some other way, maybe by quanta's suggestion in the serverfault lik above. Don't know.

raidersan · 2015-08-08T17:19:29Z

You were right, I have re-installed but disabled an openvpn plugin and it does create the tun device
Now it looks like Transmission is running, here is the log

VPN PROVIDER: BTGUARD
No VPN configuration provided. Using default.
Setting OPENVPN credentials...
Sat Aug 8 15:34:31 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Sat Aug 8 15:34:31 2015 WARNING: file '/config/openvpn-credentials.txt' is group or others accessible
Sat Aug 8 15:34:31 2015 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Sat Aug 8 15:34:31 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat Aug 8 15:34:31 2015 Socket Buffers: R=[212992->131072] S=[212992->131072]
Sat Aug 8 15:34:31 2015 UDPv4 link local: [undef]
Sat Aug 8 15:34:31 2015 UDPv4 link remote: [AF_INET]109.201.137.163:1194
Sat Aug 8 15:34:31 2015 TLS: Initial packet from [AF_INET]109.201.137.163:1194, sid=2eeec825 03e0cdd7
Sat Aug 8 15:34:31 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Aug 8 15:34:31 2015 VERIFY OK: depth=1, C=DE, ST=Hesse-Nassau, L=Frankfurt, O=BTGuard, CN=BTGuard CA, [email protected]
Sat Aug 8 15:34:31 2015 VERIFY OK: depth=0, C=DE, ST=Hesse-Nassau, L=Frankfurt, O=BTGuard, CN=server, [email protected]
Sat Aug 8 15:34:31 2015 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Aug 8 15:34:31 2015 NOTE: --mute triggered...
Sat Aug 8 15:34:31 2015 4 variation(s) on previous 3 message(s) suppressed by --mute
Sat Aug 8 15:34:31 2015 [server] Peer Connection Initiated with [AF_INET]109.201.137.163:1194
Sat Aug 8 15:34:34 2015 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Sat Aug 8 15:34:34 2015 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,redirect-gateway,route 10.10.10.1,topology net30,ping 10,ping-restart 120,ifconfig 10.10.10.14 10.10.10.13'
Sat Aug 8 15:34:34 2015 OPTIONS IMPORT: timers and/or timeouts modified
Sat Aug 8 15:34:34 2015 NOTE: --mute triggered...
Sat Aug 8 15:34:34 2015 3 variation(s) on previous 3 message(s) suppressed by --mute
Sat Aug 8 15:34:34 2015 ROUTE_GATEWAY 172.17.42.1/255.255.0.0 IFACE=eth0 HWADDR=02:42:ac:11:00:0b
Sat Aug 8 15:34:34 2015 TUN/TAP device tun0 opened
Sat Aug 8 15:34:34 2015 TUN/TAP TX queue length set to 100
Sat Aug 8 15:34:34 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Aug 8 15:34:34 2015 /sbin/ip link set dev tun0 up mtu 1500
Sat Aug 8 15:34:34 2015 /sbin/ip addr add dev tun0 local 10.10.10.14 peer 10.10.10.13
Sat Aug 8 15:34:34 2015 /etc/transmission-daemon/start.sh tun0 1500 1541 10.10.10.14 10.10.10.13 init
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to tun0 ip: 10.10.10.14
Generating transmission settings.json from env variables
STARTING TRANSMISSION
NO PORT UPDATER FOR THIS PROVIDER
Transmission startup script complete.
Sat Aug 8 15:34:34 2015 /sbin/ip route add 109.201.137.163/32 via 172.17.42.1
Sat Aug 8 15:34:34 2015 /sbin/ip route del 0.0.0.0/0
Sat Aug 8 15:34:34 2015 /sbin/ip route add 0.0.0.0/0 via 10.10.10.13
Sat Aug 8 15:34:34 2015 /sbin/ip route add 10.10.10.1/32 via 10.10.10.13
Sat Aug 8 15:34:34 2015 Initialization Sequence Completed
Sat Aug 8 15:46:29 2015 TLS Error: local/remote TLS keys are out of sync: [AF_INET]109.201.137.163:1194 [2]
Sat Aug 8 16:34:31 2015 VERIFY OK: depth=1, C=DE, ST=Hesse-Nassau, L=Frankfurt, O=BTGuard, CN=BTGuard CA, [email protected]
Sat Aug 8 16:34:31 2015 VERIFY OK: depth=0, C=DE, ST=Hesse-Nassau, L=Frankfurt, O=BTGuard, CN=server, [email protected]
Sat Aug 8 16:34:31 2015 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Aug 8 16:34:31 2015 NOTE: --mute triggered...

I then install nginx, with the following config

events {
    worker_connections 1024;
}

http {
    server {
        listen 8080;
        location / {
            proxy_pass http://192.168.1.250:9092;
        }
    }
}

But I get a bad gateway when I try to access though the 8080 port. Then I realised that I have allowed port 9092 through to this container but nowhere have I specified which port should Transmission listen to. Did I miss that?

haugene · 2015-08-08T20:43:38Z

Aha. But this is looking good! 👍
Transmission is running on port 9091 inside the container, so you have two choices. From the run command you posted earlier I see you specify the port bindings like this:
-p 9092:9092/tcp

You could either change it for 9091:9091, and update your nginx.conf to 9091 as well. Or you could map port 9092 on your host to 9091 in the container by writing -p 9092:9091/tcp and then your nginx should be OK.

Try it out and let me know.

raidersan · 2015-08-09T01:04:07Z

Of course! and now that works, I can see the UI through the proxy.
But I now have to find out why it is not allowing traffic through, that will be for tomorrow...

raidersan · 2015-08-09T17:12:02Z

I am struggling with my very limited understanding of Docker!
Could you comment on the following?

KEEP_TRANSMISSION_STATE=YES does not keep my torrents between restart. I understood it should, no?
It seems to ignore my settings.json, whatever port change or download-dir I put in there they are ignore. And I do stop the container before updating settings.json
it looks like something is not right, I run docker run --privileged -it haugene/transmission-openvpn:dev bash and when I type ls /config or ls /data it is empty. Am I being stupid here?
Is transmission set to log anywhere, I cannot seem to find its log file?

Here is the command line that is generated by UNRAID after setting the docker up in the UNRADI UI:
/usr/bin/docker run -d --name="TransmissionVPNDEV" --net="bridge" --privileged="true" -e OPENVPN_PROVIDER="BTGUARD" -e OPENVPN_USERNAME="xxxxx" -e OPENVPN_PASSWORD="yyyyy" -e KEEP_TRANSMISSION_STATE="YES" -e TZ="Europe/London" -p 9092:9091/tcp -p 51413:51413/tcp -v "/mnt/user/Downloads/Torrents":"/data":rw -v "/mnt/cache/.apps/transmissionVPN":"/config":rw haugene/transmission-openvpn:dev

Thanks!

haugene · 2015-08-09T18:38:01Z

I get it, Docker is a lot of magic :)

1a) The KEEP_TRANSMISSION_STATE flag has been removed, it was an option before but wasn't done in a good way and it went away. I think I know a better way to fix it now, so I could add that again.

It will ignore your settings.json changes. The settings.json file is generated on each container startup from a template that reads environment variables from the container. See the "Transmission configuration options" of the README. Short version; to set download-dir add the following environment variable: -e TRANSMISSION_DOWNLOAD_DIR="/data/your/path" and so on. You can see all the settings listed in the Dockerfile.
/config and /data will be empty when you run it like that. /data isn't mounted to anything, so that's that. Secondly since you're overriding the containers entry point, the scripts that writes openvpn-credentials.txt and transmission-credentials.txt (which usually resides here) are never run. As I commented earlier, the /config directory is not an important one and unless you're doing something fancy stuff you don't need to think about it or mount it.
Hmm. Don't think it is, no. Looks like transmission have to be started with the logfile flag in that case (transmission-daemon --logfile /your/path/to/transmission.log). Could also be an enhancement for the image, will concider adding it. At least to see how fast it grows (accumulating hundreds of MB logfile would probably not be a good default). Could also be an option I guess.

1b )I'll have a look at how to keep the transmission state. Probably I'll just juggle some of the scripts out of /etc/transmission-daemon/ folder and then that folder could be mounted in order to keep daemon state. Right now the container depends on some scripts there, so mounting it would fail.

…his allows mounting of /etc/transmission-daemon to keep state, ref issue #22

haugene · 2015-08-09T19:10:57Z

OK, so I've updated the code to let you keep the transmission state. I moved all transmission control scripts to /etc/transmission, which leaves /etc/transmission-daemon only containing the settings.json (generated on each startup) plus the transmission state. You can now mount a folder on your host to keep the state. That is: -v /your/state/storage/location:/etc/transmission-daemon:rw

The state will be kept in the directory you mount to the container. The settings.json file will also be written to this directory, but remember that you can't change it there...

The code is built and if you pull the image again from docker registry it should work.

raidersan · 2015-08-10T17:51:38Z

Thanks Kristian, the state is now saved and that is a great advantage.
My torrents can still get no peers, as if they cannot contact the trackers. I have a docker with another (non-VPN) Transmission that connects fine so I am at a loss as to what is different. Maybe having the log might give us a clue?
I just tried to set the TRANSMISSION_PORT_FORWARDING_ENABLED=YES and that must have failed as nginx reported a bad gateway, meaning transmission's UI is not working. Is this to do with the VPN?

haugene · 2015-08-10T18:25:12Z

Sounds like it has something to do with the VPN yes. You could exec into your container and check that you have internet connectivity from there.
So:
docker exec -it bash
And from there: ping cnn.com or your-tracker.com

If you want the logs, you could add this yourself. Edit the file /etc/transmission/start
Change this line:
exec /usr/bin/transmission-daemon -g /etc/transmission-daemon/ &

For something like this:
exec /usr/bin/transmission-daemon -g /etc/transmission-daemon/ --logfile /etc/transmission-daemon/transmission.log &

After changing that, stop and start the container and it should start with logging enabled.

PS: And if nginx says bad gateway it probably means that the openvpn container startup failed, so it would be nice to see the logs from that startup to know the problem.

raidersan · 2015-08-10T18:33:40Z

Pls disregard the PORT_FORWARDING issue, it seems to fail as I had TRUE instead of true. Now fixed.
I can see the blacklist doesn't get recorded when I submit it, but that is not a big problem.
But I am stuck when no trackers being reachable, I have tried magnets and torrents, to no avail... Is there an easy way for me to get in the current Docker container , stop transmission and restart it with a log?

raidersan · 2015-08-10T18:34:05Z

Sorry missed your last one, let me try

raidersan · 2015-08-10T18:43:49Z

OK I am starting the see the problem, the tun device is up but nothing is going through. Ping does not work on anything. This is my ifconfig:

root@4015305b6799:/etc/transmission-daemon# ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:ac:11:00:40  
          inet addr:172.17.0.64  Bcast:0.0.0.0  Mask:255.255.0.0
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:418 errors:0 dropped:0 overruns:0 frame:0
          TX packets:540 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:84937 (84.9 KB)  TX bytes:237891 (237.8 KB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.10.10.70  P-t-P:10.10.10.69  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:169 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:48 (48.0 B)  TX bytes:11047 (11.0 KB)

I cannot see a log for openvpn either, do I need a similar trick to start it with one?

haugene · 2015-08-10T18:50:00Z

You've got no docker0 interface. And you should have an interface named something like this: veth45878ea per container. Its a virtual ethernet interface that is created per container.

Upgrade and/or restart your docker service? Give it sudo? I don't know, might be it's not behaving right.

raidersan · 2015-08-10T19:04:05Z

I am thinking that this is how Docker behaves on this version, maybe UNRAID specific, but I just went into my Plex container and I can definitely ping there, and I only see eth0 and lo as well.
I am starting to think it has got to do with the openvpn config file. I have a working one on Raspberry pi that I will dig out. When I go into the container and make change, how do I go back to a fresh image later without all my changes?

haugene · 2015-08-10T20:45:33Z

Ok, so docker is probably working alright. And I agree, the config file would be a prime suspect.

Well, depends on the command you use. "docker run" will always create a fresh container from the image. docker start/stop will start and stop an existing container.

raidersan · 2015-08-13T23:45:42Z

I have been looking at the openvpn config but cannot see anything wrong. But looking a the log file, I see a route with a mention of "via 172.17.42.1". That doesn't look familiar. Here is the relevant portion of the log file showing that tun0 is opened successfully. Could you check yours to compare the routing?

Mon Aug 10 20:12:06 2015 TUN/TAP device tun0 opened
Mon Aug 10 20:12:06 2015 TUN/TAP TX queue length set to 100
Mon Aug 10 20:12:06 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Aug 10 20:12:06 2015 /sbin/ip link set dev tun0 up mtu 1500
Mon Aug 10 20:12:06 2015 /sbin/ip addr add dev tun0 local 10.10.10.26 peer 10.10.10.25
Mon Aug 10 20:12:06 2015 /etc/transmission/start.sh tun0 1500 1541 10.10.10.26 10.10.10.25 init
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to tun0 ip: 10.10.10.26
Generating transmission settings.json from env variables
STARTING TRANSMISSION
NO PORT UPDATER FOR THIS PROVIDER
Transmission startup script complete.
Mon Aug 10 20:12:06 2015 /sbin/ip route add 109.201.137.164/32 via 172.17.42.1
Mon Aug 10 20:12:06 2015 /sbin/ip route del 0.0.0.0/0
Mon Aug 10 20:12:06 2015 /sbin/ip route add 0.0.0.0/0 via 10.10.10.25
Mon Aug 10 20:12:06 2015 /sbin/ip route add 10.10.10.1/32 via 10.10.10.25
Mon Aug 10 20:12:06 2015 Initialization Sequence Completed

Below is the equivalent on my Rpi, although the version is slightly older so messages are a bit different, but I cannot see this 172 address in there

ROUTE default_gateway=192.168.1.1
TUN/TAP device tun0 opened
TUN/TAP TX queue length set to 100
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
/sbin/ifconfig tun0 10.10.10.198 pointopoint 10.10.10.197 mtu 1500
ormally on 3 tun0 10.10.10.198 UDP 123
/sbin/route add -net 109.201.137.164 netmask 255.255.255.255 gw 192.168.1.1
/sbin/route del -net 0.0.0.0 netmask 0.0.0.0
/sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.10.10.197
WARNING: potential route subnet conflict between local LAN [10.10.10.0/255.255.255.0] and remote VPN [10.10.10.1/255.255.255.255]
/sbin/route add -net 10.10.10.1 netmask 255.255.255.255 gw 10.10.10.197
Initialization Sequence Completed

Below are the differences between your btguard.conf and the one on my Rpi

script-security, yours on 2, mine on 3
I have route-delay 5 that you dont
I have keepalive 10 60 that you dont

haugene · 2015-08-14T13:22:46Z

The 172.17.42.1 address is the Docker daemon. All your docker containers will have IP address 172.17.42.xxx

You could play around with the three differences in btguard.conf. Read about what they do here: https://openvpn.net/index.php/open-source/documentation/manuals/69-openvpn-21.html
I just use the default btguard.conf that I downloaded from btguard.com/btguard.conf I think. Just renamed it to btguard.ovpn

Can you test the container on a regular linux box? Or if you could find me on facebook or something and borrow me your BTGuard credentials I could do more testing myself as well.
I don't have a BTGuard account and can't test it with BTGuard on my server. I get the following log with PIA.

VPN PROVIDER: PIA
Starting OpenVPN using config Netherlands.ovpn
Setting OPENVPN credentials...
Mon Aug 10 23:14:24 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Mon Aug 10 23:14:24 2015 WARNING: file '/config/openvpn-credentials.txt' is group or others accessible
Mon Aug 10 23:14:24 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mon Aug 10 23:14:24 2015 UDPv4 link local: [undef]
Mon Aug 10 23:14:24 2015 UDPv4 link remote: [AF_INET]109.201.154.187:1194
Mon Aug 10 23:14:24 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Aug 10 23:14:24 2015 [Private Internet Access] Peer Connection Initiated with [AF_INET]109.201.154.187:1194
Mon Aug 10 23:14:27 2015 TUN/TAP device tun0 opened
Mon Aug 10 23:14:27 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Aug 10 23:14:27 2015 /sbin/ip link set dev tun0 up mtu 1500
Mon Aug 10 23:14:27 2015 /sbin/ip addr add dev tun0 local 10.199.1.6 peer 10.199.1.5
Mon Aug 10 23:14:27 2015 /etc/transmission/start.sh tun0 1500 1542 10.199.1.6 10.199.1.5 init
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to tun0 ip: 10.199.1.6
Generating transmission settings.json from env variables
STARTING TRANSMISSION
STARTING PORT UPDATER
Transmission startup script complete.
Mon Aug 10 23:14:27 2015 Initialization Sequence Completed

haugene · 2015-08-15T15:57:31Z

I figured I'd check out a month of BTGUARD, and do some testing. Container starts without problem on my host. Your host does something different when adding routes though. And you get a warning on addressing.

VPN PROVIDER: BTGUARD
No VPN configuration provided. Using default.
Setting OPENVPN credentials...
Sat Aug 15 17:53:19 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Sat Aug 15 17:53:19 2015 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Sat Aug 15 17:53:19 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat Aug 15 17:53:19 2015 Socket Buffers: R=[212992->131072] S=[212992->131072]
Sat Aug 15 17:53:19 2015 UDPv4 link local: [undef]
Sat Aug 15 17:53:19 2015 UDPv4 link remote: [AF_INET]109.201.137.166:1194
Sat Aug 15 17:53:19 2015 TLS: Initial packet from [AF_INET]109.201.137.166:1194, sid=cdd8156d e606e551
Sat Aug 15 17:53:19 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Aug 15 17:53:19 2015 VERIFY OK: depth=1, C=DE, ST=Hesse-Nassau, L=Frankfurt, O=BTGuard, CN=BTGuard CA, emailAddress=[email protected]
Sat Aug 15 17:53:19 2015 VERIFY OK: depth=0, C=DE, ST=Hesse-Nassau, L=Frankfurt, O=BTGuard, CN=server, emailAddress=[email protected]
Sat Aug 15 17:53:19 2015 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Aug 15 17:53:19 2015 NOTE: --mute triggered...
Sat Aug 15 17:53:19 2015 4 variation(s) on previous 3 message(s) suppressed by --mute
Sat Aug 15 17:53:19 2015 [server] Peer Connection Initiated with [AF_INET]109.201.137.166:1194
Sat Aug 15 17:53:22 2015 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Sat Aug 15 17:53:22 2015 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,redirect-gateway,route 10.10.10.1,topology net30,ping 10,ping-restart 120,ifconfig 10.10.10.218 10.10.10.217'
Sat Aug 15 17:53:22 2015 OPTIONS IMPORT: timers and/or timeouts modified
Sat Aug 15 17:53:22 2015 NOTE: --mute triggered...
Sat Aug 15 17:53:22 2015 3 variation(s) on previous 3 message(s) suppressed by --mute
Sat Aug 15 17:53:22 2015 ROUTE_GATEWAY 172.17.42.1/255.255.0.0 IFACE=eth0 HWADDR=02:42:ac:11:01:07
Sat Aug 15 17:53:22 2015 TUN/TAP device tun0 opened
Sat Aug 15 17:53:22 2015 TUN/TAP TX queue length set to 100
Sat Aug 15 17:53:22 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Aug 15 17:53:22 2015 /sbin/ip link set dev tun0 up mtu 1500
Sat Aug 15 17:53:22 2015 /sbin/ip addr add dev tun0 local 10.10.10.218 peer 10.10.10.217
Sat Aug 15 17:53:22 2015 /etc/transmission/start.sh tun0 1500 1541 10.10.10.218 10.10.10.217 init
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to tun0 ip: 10.10.10.218
Generating transmission settings.json from env variables
STARTING TRANSMISSION
NO PORT UPDATER FOR THIS PROVIDER
Transmission startup script complete.
Sat Aug 15 17:53:22 2015 /sbin/ip route add 109.201.137.166/32 via 172.17.42.1
Sat Aug 15 17:53:22 2015 /sbin/ip route del 0.0.0.0/0
Sat Aug 15 17:53:22 2015 /sbin/ip route add 0.0.0.0/0 via 10.10.10.217
Sat Aug 15 17:53:22 2015 /sbin/ip route add 10.10.10.1/32 via 10.10.10.217
Sat Aug 15 17:53:22 2015 Initialization Sequence Completed

haugene · 2015-08-16T13:08:25Z

The container now supports BTGuard, closing this issue. If you still have problems running the container on your NAS or on your Rpi, I suggest you create a new issue for that.

haugene added the enhancement label Aug 7, 2015

haugene added a commit that referenced this issue Aug 7, 2015

Update Dockerfile

f5baa63

Bumped to version 1.2 after changes for issue #22

haugene added a commit that referenced this issue Aug 9, 2015

moved scripts and templates out of transmission daemon home folder. t…

0949d82

…his allows mounting of /etc/transmission-daemon to keep state, ref issue #22

haugene closed this as completed Aug 16, 2015

TobogganMD mentioned this issue Mar 29, 2023

Unzipping error in script - Ubuntu/ARM-related? #2565

Closed

8 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for more VPN providers #22

Add support for more VPN providers #22

haugene commented Aug 7, 2015

raidersan commented Aug 8, 2015

haugene commented Aug 8, 2015

raidersan commented Aug 8, 2015

haugene commented Aug 8, 2015

haugene commented Aug 8, 2015

raidersan commented Aug 8, 2015

haugene commented Aug 8, 2015

raidersan commented Aug 8, 2015

haugene commented Aug 8, 2015

raidersan commented Aug 9, 2015

raidersan commented Aug 9, 2015

haugene commented Aug 9, 2015

haugene commented Aug 9, 2015

raidersan commented Aug 10, 2015

haugene commented Aug 10, 2015

raidersan commented Aug 10, 2015

raidersan commented Aug 10, 2015

raidersan commented Aug 10, 2015

haugene commented Aug 10, 2015

raidersan commented Aug 10, 2015

haugene commented Aug 10, 2015

raidersan commented Aug 13, 2015

haugene commented Aug 14, 2015

haugene commented Aug 15, 2015

haugene commented Aug 16, 2015

Add support for more VPN providers #22

Add support for more VPN providers #22

Comments

haugene commented Aug 7, 2015

raidersan commented Aug 8, 2015

haugene commented Aug 8, 2015

raidersan commented Aug 8, 2015

haugene commented Aug 8, 2015

haugene commented Aug 8, 2015

raidersan commented Aug 8, 2015

haugene commented Aug 8, 2015

raidersan commented Aug 8, 2015

haugene commented Aug 8, 2015

raidersan commented Aug 9, 2015

raidersan commented Aug 9, 2015

haugene commented Aug 9, 2015

haugene commented Aug 9, 2015

raidersan commented Aug 10, 2015

haugene commented Aug 10, 2015

raidersan commented Aug 10, 2015

raidersan commented Aug 10, 2015

raidersan commented Aug 10, 2015

haugene commented Aug 10, 2015

raidersan commented Aug 10, 2015

haugene commented Aug 10, 2015

raidersan commented Aug 13, 2015

haugene commented Aug 14, 2015

haugene commented Aug 15, 2015

haugene commented Aug 16, 2015