exposed port 9091 inaccessible on host between openvpn-client-pia and transmission
pyunramura opened this issue · comments
I've been having problems getting the firecat53/openvpn-client-pia service to play nicely with any other service that connects to its container network. The firecat53/transmission service on port 9091 becomes inaccessible when the container is connected to the VPN container's network stack but is accessible when started in its own stack. The images were built without issue and the containers seem to be running fine either in the vpn container network or outside of it judging by the docker logs command output. Just to make sure it wasn't a volume mapping issue I tried creating volumes for each service and also bind mounting them to corresponding directories with no joy. I tried proxying the exposed port through a separate service and docker network connect to join the vpn containers network too. I've attached my docker run commands and log outputs below, any help with this issue would be greatly appreciated.
commands:
docker run -d --rm \
--cap-add=NET_ADMIN \
--device=/dev/net/tun \
--net=vpn \ # created this network in attempt to proxy into the webservice
-v /path/to/vpn/config:/config \
-v pia_port:/var/run/pia/ \
-p 9091:9091 \
--name=openvpn_run \
openvpn-client
docker run -d --rm \
--net=container:openvpn_run \
-v /path/to/transmission/config:/config \
-v pia_port:/var/run/pia \
-v /path/to/torrent/data:/data \
-v /etc/localtime:/etc/localtime:ro \
--name transmission_run \
transmission
logs for vpn
Fri Jan 4 11:18:27 2019 OpenVPN 2.4.6 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4 [EPOLL] [MH/PKTINFO] [AEAD] built on Jul 8 2018
Fri Jan 4 11:18:27 2019 library versions: LibreSSL 2.7.4, LZO 2.10
Fri Jan 4 11:18:27 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Fri Jan 4 11:18:27 2019 TCP/UDP: Preserving recently used remote address [AF_INET]172.98.67.90:1198
Fri Jan 4 11:18:27 2019 UDP link local: (not bound)
Fri Jan 4 11:18:27 2019 UDP link remote: [AF_INET]172.98.67.90:1198
Fri Jan 4 11:18:27 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Jan 4 11:18:27 2019 [3587aa6b4db509fb071d1fc99096531a] Peer Connection Initiated with [AF_INET]172.98.67.90:1198
Fri Jan 4 11:18:28 2019 TUN/TAP device tun0 opened
Fri Jan 4 11:18:28 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Fri Jan 4 11:18:28 2019 /sbin/ip link set dev tun0 up mtu 1500
Fri Jan 4 11:18:28 2019 /sbin/ip addr add dev tun0 local 10.45.10.6 peer 10.45.10.5
Fri Jan 4 11:18:28 2019 /usr/local/bin/up.sh tun0 1500 1558 10.45.10.6 10.45.10.5 init
Fri Jan 4 11:18:30 2019 Initialization Sequence Completed
logs for torrent
[2019-01-04 11:32:39.301] Transmission 2.94 (d8e60ee44f) started (session.c:740)
[2019-01-04 11:32:39.301] RPC Server Adding address to whitelist: 127.0.0.1 (rpc-server.c:971)
[2019-01-04 11:32:39.301] RPC Server Serving RPC and Web requests on port 127.0.0.1:9091/transmission/ (rpc-server.c:1213)
[2019-01-04 11:32:39.301] UDP Failed to set receive buffer: requested 4194304, got 425984 (tr-udp.c:84)
[2019-01-04 11:32:39.301] UDP Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf (tr-udp.c:89)
[2019-01-04 11:32:39.301] UDP Failed to set send buffer: requested 1048576, got 425984 (tr-udp.c:95)
[2019-01-04 11:32:39.301] UDP Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf (tr-udp.c:100)
[2019-01-04 11:32:39.301] DHT Reusing old id (tr-dht.c:307)
[2019-01-04 11:32:39.301] DHT Bootstrapping from 112 IPv4 nodes (tr-dht.c:156)
[2019-01-04 11:32:39.301] Using settings from "/config" (daemon.c:528)
[2019-01-04 11:32:39.301] Saved "/config/settings.json" (variant.c:1266)
[2019-01-04 11:32:39.301] Transmission 2.94 (d8e60ee44f) started (session.c:740)
[2019-01-04 11:32:39.301] RPC Server Adding address to whitelist: 127.0.0.1 (rpc-server.c:971)
[2019-01-04 11:32:39.301] RPC Server Serving RPC and Web requests on port 127.0.0.1:9091/transmission/ (rpc-server.c:1213)
[2019-01-04 11:32:39.301] UDP Failed to set receive buffer: requested 4194304, got 425984 (tr-udp.c:84)
[2019-01-04 11:32:39.301] UDP Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf (tr-udp.c:89)
[2019-01-04 11:32:39.301] UDP Failed to set send buffer: requested 1048576, got 425984 (tr-udp.c:95)
[2019-01-04 11:32:39.301] UDP Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf (tr-udp.c:100)
[2019-01-04 11:32:39.301] DHT Reusing old id (tr-dht.c:307)
[2019-01-04 11:32:39.301] DHT Bootstrapping from 112 IPv4 nodes (tr-dht.c:156)
[2019-01-04 11:32:39.301] Using settings from "/config" (daemon.c:528)
[2019-01-04 11:32:39.301] Saved "/config/settings.json" (variant.c:1266)
Although it may be unrelated, the failure manifests as the webservice page continuing to load indefinitely instead of an immediate ERR_CONNECTION_REFUSED.
EDIT: Not relevant since the same error is produced when the web interface is working.
Attempting to curl the localhost:9091 results in <h1>301: Moved Permanently</h1>
I'll take a look. I use Traefik as a reverse proxy, so I haven't tried it recently from the local machine. One question: your transmission logs look like they are repeated twice (Transmission 2.94 ....started appears twice). Is that just a copy paste error, or is it rapidly restarting itself?
It's a copy paste error. Transmission was throwing a lot of errors over lacking the watch directory, combined with a ham-fisted attempt at pruning the logs of irrelevant information I must have copied it twice. Any insight you could provide though would be very appreciated.
I'm not opposed to running a reverse proxy in principal, it's just one more moving part to configure.
I'm still not able (like you) to get a local connection to the container. I have all my containers fronted with Traefik, so it's a non-issue for me. I feel there's probably a simple solution, but I'm not seeing it yet. I'll leave this open in case I (or you) end up finding a solution. Sorry I couldn't help! Thanks for the interest, though.
After looking into it a bit, I found its due to the "--route-up", "/sbin/ip route del default" line in the openvpn configuration, which makes sense as you'd want to remove the default route to avoid anything leaking outside the vpn tunnel.
In order to add a route back to your local subnet you would need to run the following command in a shell:
under cmd or entrypoint the dockerfile somehow
"route -n | grep eth* | grep 'UGH[ \t]'|awk '{print $2,$8}' | while read x y ; do ip route add $LAN_NET via $x dev $y ; done"
or in a shell script
x="route -n | grep eth* | grep 'UGH[ \t]' | awk '{print $2}'"
y="route -n | grep eth* | grep 'UGH[ \t]' | awk '{print $8}'"
ip route add $local_subnet via $x dev $y
It looks pretty cludgy but it would get the job done. It would likely go in after the entry point as a CMD in the Dockerfile, or more elegantly into a shell script run at startup under CMD or appending the entrypoint.
I have tested this with the tunnel both up and down and confirmed that I can only access my local subnet when it's passed as an environment variable, so it should do the trick. It might be worth adding to the readme or thrown into a shell script if you feel it's necessary.
Ah yes, thanks for finding that! That helped me remember that I found something similar in haugene/docker-transmission-openvpn start.sh:
if [[ -n "${LOCAL_NETWORK-}" ]]; then
if [[ -n "${GW-}" ]] && [[ -n "${INT-}" ]]; then
for localNet in ${LOCAL_NETWORK//,/ }; do
echo "adding route to local network ${localNet} via ${GW} dev ${INT}"
/sbin/ip r a "${localNet}" via "${GW}" dev "${INT}"
I never added that because I was always intending to use it with Traefik as a reverse proxy. I'll take a look at your ideas and see if I can fit it in cleanly somehow. Thanks!
I forgot to comment here a few weeks ago, but I added a snippet to the openvpn-client-pia port_forward script that allows local network access. I tested it with deluge, but it should work the same for transmission. The commit was 15a48b3.
Let me know if this works for you if you're still using this!
Closing. Please re-open if you still need some help.