docker-transmission-openvpn icon indicating copy to clipboard operation
docker-transmission-openvpn copied to clipboard

Enabling UFW With Random Ports Not Opening Route

Open the-jbutler opened this issue 2 years ago • 4 comments

Is there a pinned issue for this?

  • [X] I have read the pinned issues and could not find my issue

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

  • [X] I have searched the existing issues
  • [X] I have searched the existing discussions

Is there any comment in the documentation for this?

  • [X] I have read the documentation, especially the FAQ and Troubleshooting parts

Is this related to a provider?

  • [X] I have checked the provider repo for issues
  • [X] My issue is NOT related to a provider

Are you using the latest release?

  • [X] I am using the latest release

Have you tried using the dev branch latest?

  • [X] I have tried using dev branch

Docker run config used

podman run \
  --replace -d \
  --restart unless-stopped \
  -e OPENVPN_PROVIDER=NORDVPN \
  -e "OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60" \
  -e LOCAL_NETWORK=x.x.x.x/x \
  -e CREATE_TUN_DEVICE=true \
  -e ENABLE_UFW=true \
  -e NORDVPN_COUNTRY=gb \
  -e NORDVPN_CATEGORY=legacy_p2p \
  -e TRANSMISSION_SCRAPE_PAUSED_TORRENTS_ENABLED=false \
  -e TRANSMISSION_PEER_PORT_RANDOM_ON_START=true \
  -e TRANSMISSION_PEER_PORT_RANDOM_LOW=50000 \
  -e TRANSMISSION_PEER_PORT_RANDOM_HIGH=55000 \
  -p 9091:9091 \
  --secret nordvpn_username,type=env,target=OPENVPN_USERNAME \
  --secret nordvpn_password,type=env,target=OPENVPN_PASSWORD \
  --name transmission_nordvpn \
  --privileged \
  -v /mnt/xxx/:/data:Z \
  haugene/transmission-openvpn

Current Behavior

Setting randomised ports on launch with UFW enabled does not create allowed routes in UFW for the randomised port range as expected. Instead an error is thrown in the logs as UFW expects port ranges to specify a protocol (https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu-14-04#allow-specific-port-ranges).

Expected Behavior

UFW to add routing rule for the randomised port range correctly.

How have you tried to solve the problem?

  1. Manually added port range to the firewall of a running container.
  2. Editing the openvpn/start.sh script in a stopped container to specify the correct protocol

Log output

Starting container with revision: xxx
Creating TUN device /dev/net/tun
mknod: /dev/net/tun: File exists
chmod: changing permissions of '/dev/net/tun': Operation not permitted
Using OpenVPN provider: NORDVPN
Running with VPN_CONFIG_SOURCE auto
Provider NORDVPN has a bundled setup script. Defaulting to internal config
Executing setup script for NORDVPN
2022-05-08 13:13:08 Checking curl installation
2022-05-08 13:13:08 Removing existing configs
2022-05-08 13:13:08 Selecting the best server...
2022-05-08 13:13:08 Searching for technology: openvpn_udp
2022-05-08 13:13:08 Best server : x.nordvpn.com
2022-05-08 13:13:08 Downloading config: default.ovpn
2022-05-08 13:13:08 Downloading from: https://downloads.nordcdn.com/configs/files/ovpn_udp/servers/x.nordvpn.com.udp.ovpn
2022-05-08 13:13:08 Selecting the best server...
2022-05-08 13:13:08 Searching for country : gb (227)
2022-05-08 13:13:08 Searching for technology: openvpn_udp
2022-05-08 13:13:08 Best server : x.nordvpn.com
2022-05-08 13:13:08 Downloading config: x.nordvpn.com.ovpn
2022-05-08 13:13:08 Downloading from: https://downloads.nordcdn.com/configs/files/ovpn_udp/servers/x.nordvpn.com.udp.ovpn
Starting OpenVPN using config x.nordvpn.com.ovpn
Modifying /etc/openvpn/nordvpn/x.nordvpn.com.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...
*enabling firewall*
*Firewall is active and enabled on system startup*
*allowing 50000:55000 through the firewall*
*ERROR: Must specify 'tcp' or 'udp' with multiple ports*
allowing x.x.x.x through the firewall to port 9091
Rule added
adding route to local network x.x.x.x/x via x.x.x.x dev tap0
allowing x.x.x.x/x through the firewall to port 9091
Rule added
Sun May  8 13:13:15 2022 OpenVPN 2.4.7 aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021
Sun May  8 13:13:15 2022 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Sun May  8 13:13:15 2022 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun May  8 13:13:15 2022 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sun May  8 13:13:15 2022 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sun May  8 13:13:15 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:x
Sun May  8 13:13:15 2022 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sun May  8 13:13:15 2022 UDP link local: (not bound)
Sun May  8 13:13:15 2022 UDP link remote: [AF_INET]x.x.x.x:x
Sun May  8 13:13:15 2022 TLS: Initial packet from [AF_INET]x.x.x.x:x, sid=9e946dd1 7f54d2b1
Sun May  8 13:13:15 2022 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun May  8 13:13:15 2022 VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA
Sun May  8 13:13:15 2022 VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA7
Sun May  8 13:13:15 2022 VERIFY KU OK
Sun May  8 13:13:15 2022 Validating certificate extended key usage
Sun May  8 13:13:15 2022 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sun May  8 13:13:15 2022 VERIFY EKU OK
Sun May  8 13:13:15 2022 VERIFY OK: depth=0, CN=x.nordvpn.com
Sun May  8 13:13:15 2022 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA
Sun May  8 13:13:15 2022 [x.nordvpn.com] Peer Connection Initiated with [AF_INET]x.x.x.x:x
Sun May  8 13:13:17 2022 SENT CONTROL [x.nordvpn.com]: 'PUSH_REQUEST' (status=1)
Sun May  8 13:13:17 2022 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS x.x.x.x,dhcp-option DNS x.x.x.x,sndbuf 524288,rcvbuf 524288,explicit-exit-notify,comp-lzo no,route-gateway x.x.x.x,topology subnet,ping 60,ping-restart 180,ifconfig x.x.x.x 255.255.255.0,peer-id 9,cipher AES-256-GCM'
Sun May  8 13:13:17 2022 OPTIONS IMPORT: timers and/or timeouts modified
Sun May  8 13:13:17 2022 OPTIONS IMPORT: explicit notify parm(s) modified
Sun May  8 13:13:17 2022 OPTIONS IMPORT: compression parms modified
Sun May  8 13:13:17 2022 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Sun May  8 13:13:17 2022 Socket Buffers: R=[212992->425984] S=[212992->425984]
Sun May  8 13:13:17 2022 OPTIONS IMPORT: --ifconfig/up options modified
Sun May  8 13:13:17 2022 OPTIONS IMPORT: route options modified
Sun May  8 13:13:17 2022 OPTIONS IMPORT: route-related options modified
Sun May  8 13:13:17 2022 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun May  8 13:13:17 2022 OPTIONS IMPORT: peer-id set
Sun May  8 13:13:17 2022 OPTIONS IMPORT: adjusting link_mtu to 1657
Sun May  8 13:13:17 2022 OPTIONS IMPORT: data channel crypto options modified
Sun May  8 13:13:17 2022 Data Channel: using negotiated cipher 'AES-256-GCM'
Sun May  8 13:13:17 2022 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun May  8 13:13:17 2022 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun May  8 13:13:17 2022 ROUTE_GATEWAY x.x.x.x/255.255.255.0 IFACE=tap0 HWADDR=x:x:x:x:x:x
Sun May  8 13:13:17 2022 TUN/TAP device tun0 opened
Sun May  8 13:13:17 2022 Note: Cannot set tx queue length on tun0: Operation not permitted (errno=1)
Sun May  8 13:13:17 2022 /sbin/ip link set dev tun0 up mtu 1500
Sun May  8 13:13:17 2022 /sbin/ip addr add dev tun0 x.x.x.x/x broadcast x.x.x.x
Sun May  8 13:13:17 2022 /etc/openvpn/tunnelUp.sh tun0 1500 1585 x.x.x.x 255.255.255.0 init
Up script executed with tun0 1500 1585 x.x.x.x 255.255.255.0 init
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : x.x.x.x
Updating Transmission settings.json with values from env variables
Using existing settings.json for Transmission /data/transmission-home/settings.json
Overriding bind-address-ipv4 because TRANSMISSION_BIND_ADDRESS_IPV4 is set to x.x.x.x
Overriding download-dir because TRANSMISSION_DOWNLOAD_DIR is set to /data/completed
Overriding incomplete-dir because TRANSMISSION_INCOMPLETE_DIR is set to /data/incomplete
Overriding peer-port-random-high because TRANSMISSION_PEER_PORT_RANDOM_HIGH is set to 55000
Overriding peer-port-random-low because TRANSMISSION_PEER_PORT_RANDOM_LOW is set to 50000
Overriding peer-port-random-on-start because TRANSMISSION_PEER_PORT_RANDOM_ON_START is set to true
Overriding rpc-port because TRANSMISSION_RPC_PORT is set to 9091
Overriding scrape-paused-torrents-enabled because TRANSMISSION_SCRAPE_PAUSED_TORRENTS_ENABLED is set to false
Overriding watch-dir because TRANSMISSION_WATCH_DIR is set to /data/watch
sed'ing True to true

-------------------------------------
Transmission will run as
-------------------------------------
User name:   root
User uid:    0
User gid:    0
-------------------------------------

STARTING TRANSMISSION
Transmission startup script complete.
Sun May  8 13:13:17 2022 /sbin/ip route add x.x.x.x/32 via x.x.x.x
Sun May  8 13:13:17 2022 /sbin/ip route add 0.0.0.0/1 via x.x.x.x
Sun May  8 13:13:17 2022 /sbin/ip route add x.x.x.x/1 via x.x.x.x
Sun May  8 13:13:17 2022 Initialization Sequence Completed

HW/SW Environment

- OS: Debian Bookworm
- Podman: 4.0.3

(functionally there appears to be no other issues using Podman over Docker!)

Anything else?

Potential source of this issue: openvpn/start.sh L252

the-jbutler avatar May 08 '22 14:05 the-jbutler

this may be an update of ufw? I swapped https://github.com/haugene/docker-transmission-openvpn/blob/44c82aa1297b0f4473ad141f2cea326b407d9c22/openvpn/start.sh#L188 with

    substr=":"
    if [[ $portNum == *"$substr"* ]];
    then
      ufw allow ${portNum}/tcp
    else
      ufw allow ${portNum}
    fi

I did the same with https://github.com/haugene/docker-transmission-openvpn/blob/e40246affdd3d2aba8ba52277d33b9d0d942b7de/openvpn/pia/update-port.sh#L114 (just to be sure, not sure if its needed in all cases):

    substr=":"
    if [[ "$new_port" == *"$substr"* ]];
    then
      ufw allow "$new_port"/tcp
    else
      ufw allow "$new_port"
    fi

this should probably be wrapped in some commong ufw bash functions to make it less ugly :) but it worked for me, now ufw is up and the daemon is reachable.

epichub avatar Jun 22 '22 07:06 epichub

Could this be causing my issue? At present the container will start and is obviously running as if I go to a tracker's website I can see the torrents I had loaded seeding, but trying to connect to the web interface for transmission just results in a connection timed out. I'm on a Synology running DSM7. I haven't updated the OS since I initially got this image working, but it suddenly stopped cooperating today.

First step I took was to update to the latest version of this image, then I also ensured I was on the most current version of the .ovpn file for Express VPN (my vpn provider). It still didn't work so I tried switching to the built-in express vpn config of the image, still no go. I see the following lines in the log as the last thing each time the image is started which made me think this is related:

STARTING TRANSMISSION

Transmission startup script complete.

Sat Jun 25 08:30:09 2022 /sbin/ip route add 193.29.107.11/32 via 172.17.0.1

Sat Jun 25 08:30:09 2022 /sbin/ip route add 0.0.0.0/1 via 10.173.6.209

Sat Jun 25 08:30:09 2022 /sbin/ip route add 128.0.0.0/1 via 10.173.6.209

Sat Jun 25 08:30:09 2022 /sbin/ip route add 10.173.0.1/32 via 10.173.6.209

RTNETLINK answers: File exists

Sat Jun 25 08:30:09 2022 ERROR: Linux route add command failed: external program exited with error status: 2

Sat Jun 25 08:30:09 2022 Initialization Sequence Completed

I've done as much google debugging as I can but I'm afraid I'm a bit of a neophyte when it comes to docker and networking stuff so I'm a bit lost. Here's screencaps of my setup in the synology docker app: <img width="677" alt="Screen S Screen Shot 2022-06-25 at 2 14 14 AM hot 2022-06-25 at 2 14 07 AM" src="https://user-images.githubusercontent.com/17838229/175767113-8f09f7bc-cc2b-4617-afef-bf608a66010f.png"> <img width="660" alt="Screen Shot 2022-06-25 at 2 15 02 AM" src="https://user-images.githubusercontent.com/17838229/175767120-71e1d8ec-e8d1-410f-b20 Screen Shot 2022-06-25 at 2 15 52 AM 9-8427feeb7141.png"> Screen Shot 2022-06-25 at 2 16 00 AM Screen Shot 2022-06-25 at 2 16 07 AM

When I attempted the very first troubleshooting step I got an interesting result: @MediaThot:/$ docker run --rm hello-world docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/create": dial unix /var/run/docker.sock: connect: permission denied. See 'docker run --help'.

I'm lost on what this all adds up to though. Is this the same issue or should I open a new issue?

astaplet avatar Jun 25 '22 09:06 astaplet

@astaplet I believe that is a different issue based on your configuration there. This particular issue relates to the firewall not being configured correctly for P2P traffic if using random ports with a range. Your issue seems to be something different I'm afraid (though still probably firewall related, I don't think it's the container image though). I'm not super well versed on how things like Synology handles containers and their own firewall settings.

As for the troubleshooting step, while out of the scope of this issue, it looks like you may need to run the docker command with elevated privileges via sudo. Strangely.

@epichub Thanks for playing around with potential fixes for this as well! I've been meaning to get back to this to see if my temporary solution can be made less awful, but your comment has made me realise that the provider configurations probably would need some tweaks too.

the-jbutler avatar Jun 25 '22 19:06 the-jbutler

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

stale[bot] avatar Sep 20 '22 19:09 stale[bot]

Feel free to re-open this issue if you think it deserves another look.

stale[bot] avatar Oct 01 '22 00:10 stale[bot]

I am seeing this same issue. If I enable a random peer port range, configuration of the range in UFW appears to fail:

      TRANSMISSION_PEER_PORT_RANDOM_ON_START: "true"
      TRANSMISSION_PEER_PORT_RANDOM_LOW: ###
      TRANSMISSION_PEER_PORT_RANDOM_HIGH: ####

Yields:

+ echo 'allowing ###:#### through the firewall'
allowing ###:#### through the firewall
+ ufw allow ###:####
ERROR: Must specify 'tcp' or 'udp' with multiple ports

It seems like the UFW command is incorrect when attempting to specify a range. The correct syntax is:

ufw allow ###:####/tcp
ufw allow ###:####/udp

robross0606 avatar Apr 04 '23 14:04 robross0606

Fixed

pkishino avatar May 12 '23 14:05 pkishino