search

haugene / docker-transmission-openvpn

Docker container running Transmission torrent client with WebUI over an OpenVPN tunnel
GNU General Public License v3.0
4.14k stars 1.21k forks source link

Warning: Failed running command (--route-up) after latest dev release #2081

Closed tim0901 closed 2 years ago

tim0901 commented 2 years ago

Is there a pinned issue for this?

Is there an existing or similar issue/discussion for this?

Is there any comment in the documentation for this?

Is this related to a provider?

Are you using the latest release?

Have you tried using the dev branch latest?

Config used


version: '3.3'
services:
        transmission-openvpn:
                container_name: transmission_openvpn
                image: haugene/transmission-openvpn:dev
                restart: always
                cap_add:
                    - NET_ADMIN
                volumes:
                    - ~/data/transmission-home:/config/transmission-home
                    - ~/data/media:/data
                    - networkShare:/networkShare
                environment:
                    - PUID=1001
                    - GUID=1001
                    - OPENVPN_PROVIDER=WINDSCRIBE
                    - OPENVPN_CONFIG=${OPENVPN_CONFIG}
                    - OPENVPN_USERNAME=${OPENVPN_USERNAME}
                    - OPENVPN_PASSWORD=${OPENVPN_PASSWORD}
                    - LOCAL_NETWORK=192.168.0.0/16
                    - TRANSMISSION_SPEED_LIMIT_UP=100
                    - TRANSMISSION_SPEED_LIMIT_DOWN=2048
                    - TRANSMISSION_ALT_SPEED_UP=50
                    - TRANSMISSION_ALT_SPEED_DOWN=1024
                    - TRANSMISSION_RPC_USERNAME=${RPC_USERNAME}
                    - TRANSMISSION_RPC_PASSWORD=${RPC_PASSWORD}
                    - TRANSMISSION_RPC_AUTHENTICATION_REQUIRED=true
                    - TRANSMISSION_ALT_SPEED_TIME_BEGIN=480
                    - TRANSMISSION_ALT_SPEED_TIME_END=1320
                    - TRANSMISSION_IDLE_SEEDING_LIMIT=1
                    - TRANSMISSION_IDLE_SEEDING_LIMIT_ENABLED=true
                    - TRANSMISSION_PEER_LIMIT_GLOBAL=2000
                    - TRANSMISSION_PEER_LIMIT_PER_TORRENT=500
                    - TRANSMISSION_PEER_PORT=${TRANSMISSION_PEER_PORT}
                    - TRANSMISSION_DOWNLOAD_QUEUE_SIZE=50
                    - TZ=Europe/London
                logging:
                    driver: json-file
                    options:
                        max-size: 10m
                networks:
                  static-network-vpn:
                    ipv4_address: 172.20.0.3
                  letsencrypt_proxy-tier:

        transmission-proxy:
                container_name: transmission_proxy
                restart: always
                image: haugene/transmission-openvpn-proxy:dev
                environment:
                  - TZ=Europe/London
                links:
                  - "transmission-openvpn:transmission"
                ports:
                  - ${TRANSMISSION_PEER_PORT}:${TRANSMISSION_PEER_PORT} # transmisison peers
                  - 9091:9091 #transmission
                  - 4032:4032
                  - 9117:9117
                  - 8989:8989
                  - 7878:7878
                  - 6767:6767
                depends_on:
                  - transmission-openvpn
                volumes:
                  - ~/vpn/proxy/nginx.conf:/etc/nginx/nginx.conf
                networks:
                  static-network-vpn:
                    ipv4_address: 172.20.0.13

volumes:
  networkShare:
    driver_opts:
      ##REDACTED##

networks:
  static-network-vpn:
    ipam:
      config:
        - subnet: 172.20.0.0/16
          ip_range: 172.20.5.0/24
  letsencrypt_proxy-tier:
    external: true

Current Behavior

Tunnel refuses to connect after updating to the latest dev branch release. Unable to connect to web interface but other services running through the proxy are available.

Expected Behavior

The tunnel connects successfully and I can use the web interface.

How have you tried to solve the problem?

Have changed which OpenVPN server is being used to no effect. Returning to the non-dev branch restores expected behavior.

Log output


Starting container with revision: 42b99aa86d879c38179d2c764231a8b473aa9aad
Creating TUN device /dev/net/tun
Using OpenVPN provider: WINDSCRIBE
Running with VPN_CONFIG_SOURCE auto
No bundled config script found for WINDSCRIBE. Defaulting to external config
Downloading configs from https://github.com/haugene/vpn-configs-contrib/archive/main.zip into /tmp/tmp.AoiBdvBw6Y
Extracting configs to /tmp/tmp.ADzRtTgGDB
Found configs for WINDSCRIBE in /tmp/tmp.ADzRtTgGDB/vpn-configs-contrib-main/openvpn/windscribe, will replace current content in /etc/openvpn/windscribe
Cleanup: deleting /tmp/tmp.AoiBdvBw6Y and /tmp/tmp.ADzRtTgGDB
Starting OpenVPN using config Paris-Jardin-udp.ovpn
Modifying /etc/openvpn/windscribe/Paris-Jardin-udp.ovpn for best behaviour in this container
Modification: Point auth-user-pass option to the username/password file
Modification: Change ca certificate path
Modification: Change ping options
Modification: Update/set resolv-retry to 15 seconds
Modification: Change tls-crypt keyfile path
Modification: Set output verbosity to 3
Modification: Remap SIGUSR1 signal to SIGTERM, avoid OpenVPN restart loop
Setting OpenVPN credentials...
adding route to local network 192.168.0.0/16 via 172.19.5.0 dev eth0
Sat Nov 27 14:02:04 2021 OpenVPN 2.4.7 aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021
Sat Nov 27 14:02:04 2021 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Sat Nov 27 14:02:04 2021 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat Nov 27 14:02:04 2021 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sat Nov 27 14:02:04 2021 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sat Nov 27 14:02:04 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]84.17.42.2:1194
Sat Nov 27 14:02:04 2021 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Nov 27 14:02:04 2021 UDP link local: (not bound)
Sat Nov 27 14:02:04 2021 UDP link remote: [AF_INET]84.17.42.2:1194
Sat Nov 27 14:02:04 2021 TLS: Initial packet from [AF_INET]84.17.42.2:1194, sid=519660aa 856319db
Sat Nov 27 14:02:04 2021 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Nov 27 14:02:04 2021 VERIFY OK: depth=2, C=CA, ST=ON, L=Toronto, O=Windscribe Limited, OU=Systems, CN=Windscribe Node CA X1
Sat Nov 27 14:02:04 2021 VERIFY OK: depth=1, C=CA, ST=ON, L=Toronto, O=Windscribe Limited, OU=Systems, CN=Windscribe Node CA X2
Sat Nov 27 14:02:04 2021 VERIFY KU OK
Sat Nov 27 14:02:04 2021 Validating certificate extended key usage
Sat Nov 27 14:02:04 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Nov 27 14:02:04 2021 VERIFY EKU OK
Sat Nov 27 14:02:04 2021 VERIFY X509NAME OK: C=CA, ST=ON, L=Toronto, O=Windscribe Limited, OU=Systems, CN=cdg-342.windscribe.com
Sat Nov 27 14:02:04 2021 VERIFY OK: depth=0, C=CA, ST=ON, L=Toronto, O=Windscribe Limited, OU=Systems, CN=cdg-342.windscribe.com
Sat Nov 27 14:02:04 2021 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA
Sat Nov 27 14:02:04 2021 [cdg-342.windscribe.com] Peer Connection Initiated with [AF_INET]84.17.42.2:1194
Sat Nov 27 14:02:06 2021 SENT CONTROL [cdg-342.windscribe.com]: 'PUSH_REQUEST' (status=1)
Sat Nov 27 14:02:06 2021 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,rcvbuf 256000,sndbuf 256000,route-gateway 10.120.114.1,topology subnet,ping 5,ping-restart 60,dhcp-option DNS 10.255.255.3,ifconfig 10.120.114.126 255.255.254.0,peer-id 165,cipher AES-256-GCM'
Sat Nov 27 14:02:06 2021 OPTIONS IMPORT: timers and/or timeouts modified
Sat Nov 27 14:02:06 2021 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Sat Nov 27 14:02:06 2021 Socket Buffers: R=[212992->425984] S=[212992->425984]
Sat Nov 27 14:02:06 2021 OPTIONS IMPORT: --ifconfig/up options modified
Sat Nov 27 14:02:06 2021 OPTIONS IMPORT: route options modified
Sat Nov 27 14:02:06 2021 OPTIONS IMPORT: route-related options modified
Sat Nov 27 14:02:06 2021 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Nov 27 14:02:06 2021 OPTIONS IMPORT: peer-id set
Sat Nov 27 14:02:06 2021 OPTIONS IMPORT: adjusting link_mtu to 1624
Sat Nov 27 14:02:06 2021 OPTIONS IMPORT: data channel crypto options modified
Sat Nov 27 14:02:06 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sat Nov 27 14:02:06 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sat Nov 27 14:02:06 2021 ROUTE_GATEWAY 172.19.5.0/255.255.0.0 IFACE=eth0 HWADDR=02:42:ac:13:05:03
Sat Nov 27 14:02:06 2021 TUN/TAP device tun0 opened
Sat Nov 27 14:02:06 2021 TUN/TAP TX queue length set to 100
Sat Nov 27 14:02:06 2021 /sbin/ip link set dev tun0 up mtu 1500
Sat Nov 27 14:02:06 2021 /sbin/ip addr add dev tun0 10.120.114.126/23 broadcast 10.120.115.255
Sat Nov 27 14:02:06 2021 /sbin/ip route add 84.17.42.2/32 via 172.19.5.0
Sat Nov 27 14:02:06 2021 /sbin/ip route add 0.0.0.0/1 via 10.120.114.1
Sat Nov 27 14:02:06 2021 /sbin/ip route add 128.0.0.0/1 via 10.120.114.1
Up script executed with
ERROR, unable to obtain tunnel address
killing 58
Sat Nov 27 14:02:06 2021 WARNING: Failed running command (--route-up): external program did not exit normally
Sat Nov 27 14:02:06 2021 Initialization Sequence Completed

Environment

- OS: Pi OS 64-bit Bullseye
- Docker: 20.10.11

Anything else?

Given the warning message I believe this is related to 42b99aa.

XMB5 commented 2 years ago

You are right that it is related to #2080, I am working on a fix now...

pkishino commented 2 years ago

Hmm, strange, works fine here so I’m curious why this would be.. might have time tomorrow to look

tim0901 commented 2 years ago

Can confirm that this has fixed the issue - cheers!