docker-transmission-openvpn
docker-transmission-openvpn copied to clipboard
Enabling UFW With Random Ports Not Opening Route
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?
- Manually added port range to the firewall of a running container.
- 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
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.
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
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
9-8427feeb7141.png">
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 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.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Feel free to re-open this issue if you think it deserves another look.
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
Fixed