Question about using ufw and the peer port

[ovizii]

Hi everyone,

please help me figure out if I made a mistake or if there's some part of the documentation missing. I'm pretty sure I properly understood the docs of this docker image but let me describe the problem.

my VPN for testing this is GhostPath. It works just fine. Tested the VPN connection and checked my public IP from inside the docker container. All good.

I'm using this image: image: haugene/transmission-openvpn - should be version 4.0.

I chose port 49994 as peer port in transmission. ufw is enabled. transmission settings => network => peer listening port is permanently displayed as "closed" even though I opened it on my VPN provider's side.

I then entered the docker image:
docker exec -ti transmission-openvpn bash

and checked the ufw status:

ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
9091                       ALLOW IN    172.31.0.1
9091                       ALLOW IN    10.10.10.0/24

all good so far.

I then re-read the documentation:

Firewall configuration options¶
When enabled, the firewall blocks everything except traffic to the peer port and traffic to the rpc port from the LOCAL_NETWORK and the internal docker gateway.

If TRANSMISSION_PEER_PORT_RANDOM_ON_START is enabled then it allows traffic to the range of peer ports defined by TRANSMISSION_PEER_PORT_RANDOM_HIGH and TRANSMISSION_PEER_PORT_RANDOM_LOW.

Now this sounds like ufw would let traffic to the peer port through but that port is not in above allow list. Reading it again, it then sounded like it would only block stuff from the LOCAL_NETWORK and the internal docker gateway, depending on the comma situation in this sentence. Not sure if English not being my first language is at fault here. Maybe someone could clarify this sentence for me please?

Reading the part about "if TRANSMISSION_PEER_PORT_RANDOM_ON_START is enabled" made me think that ufw is actually aware of transmissions settings and so allows traffic to the peer port which is totally wrong as my port is marked closed.

I then made a quick test and allowed all traffic to my peer port:

ufw allow 49994 
ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
9091                       ALLOW IN    172.31.0.1
9091                       ALLOW IN    10.10.10.0/24
49994                      ALLOW IN    Anywhere

and the status inside transmission immediately jumped to "peer listening port open".

So obviously what I was doing was the right thing so I tried using
- UFW_EXTRA_PORTS=49994
in my docker compose but that yielded the wrong results as it only allowed access to this port from docker and my local network:

ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
9091                       ALLOW IN    172.31.0.1
49994                      ALLOW IN    172.31.0.1
9091                       ALLOW IN    10.10.10.0/24
49994                      ALLOW IN    10.10.10.0/24

Please somebody help me figure out this know in my brain: is it the documentation or is it me being wrong?

[ovizii]

I have followed these instructions: https://haugene.github.io/docker-transmission-openvpn/config-options/#custom_scripts

and mounted /scripts/ then placed a script named transmission-pre-start.sh inside with this content and all seems to work as desired.

#!/bin/bash
ufw allow 49994

Please let me know if there's something wrong with my solution and the fact that nobody else who's having enabled ufw is reporting a closed peer port?

[ovizii]

Looks like the behaviour of ufw / transmission changed, I am not missing the rules allowing access to the control port.

Found new haugene/transmission-openvpn:latest image (3ddaedfe83cc)
Stopping /transmission-openvpn (8fa74c94b242) with SIGTERM
Creating /transmission-openvpn

if I now enter the container with docker exec -ti transmission-openvpn bash

ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
49574                      ALLOW IN    Anywhere     

This is only my manually added rule, the default ones are missing :-/

[ovizii]

If anyone is curious, I manually fixed it with the same pre script:

ufw allow from 172.31.0.1 to any port 9091
ufw allow from 10.10.10.0/24 to any port 9091

[pkishino]

checked this a few times on master branch and the port opens fine here
see code:
https://github.com/haugene/docker-transmission-openvpn/blob/master/openvpn/start.sh#L218

[ovizii]

checked this a few times on master branch and the port opens fine here see code: https://github.com/haugene/docker-transmission-openvpn/blob/master/openvpn/start.sh#L218

thanks for taking a look. May I ask where "TRANSMISSION_PEER_PORT" is defined? Is that a docker environmental variable I need to define? Just asking as that is not mentioned here at all: https://haugene.github.io/docker-transmission-openvpn/

[ovizii]

oh, btw. I just tried it and added TRANSMISSION_PEER_PORT=49994 to my docker-compose.yml and low and behold it works as expected. I just wish that had been documented ;-)

ufw status verbose                                                                                                                 
Status: active                                                                                                                                                  
Logging: on (low)                                                                                                                                               
Default: deny (incoming), allow (outgoing), deny (routed)                                                                                                       
New profiles: skip                                                                                                                                              
                                                                                                                                                                
To                         Action      From                                                                                                                     
--                         ------      ----                                                                                                                     
49994                      ALLOW IN    Anywhere                                                                                                                 
9091                       ALLOW IN    192.168.48.1                                                                                                             
9091                       ALLOW IN    10.10.10.0/24       

There was another update last night apparently:

Found new haugene/transmission-openvpn:latest image (38671380faf0)
Stopping /transmission-openvpn (b609ca2ecf0a) with SIGTERM
Creating /transmission-openvpn

[pkishino]

It is mentioned here: http://haugene.github.io/docker-transmission-openvpn/config-options/ All transmission options are referred to the official transmission documentation

…

On Mon, Dec 6, 2021 at 17:16 ovizii ***@***.***> wrote: oh, btw. I just tried it and added TRANSMISSION_PEER_PORT=49994 to my docker-compose.yml and low and behold it works as expected. I just wish that had been documented ;-) ufw status verbose Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), deny (routed) New profiles: skip To Action From -- ------ ---- 49994 ALLOW IN Anywhere 9091 ALLOW IN 192.168.48.1 9091 ALLOW IN 10.10.10.0/24 There was another update last night apparently: Found new haugene/transmission-openvpn:latest image (38671380faf0) Stopping /transmission-openvpn (b609ca2ecf0a) with SIGTERM Creating /transmission-openvpn — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2073 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7OFYTNI23RJ7N2R42TH6TUPRWONANCNFSM5IXEPI6Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[ovizii]

Not quite. I read the whole documentation availabel here from top to bottom: http://haugene.github.io/docker-transmission-openvpn/
and there is no mention of TRANSMISSION_PEER_PORT

If TRANSMISSION_PEER_PORT_RANDOM_ON_START is enabled then it allows traffic to the range of peer ports defined by TRANSMISSION_PEER_PORT_RANDOM_HIGH and TRANSMISSION_PEER_PORT_RANDOM_LOW.

But nevermind, now that I know about this variable and have set it, all is well. Thanks for your comments.

[pkishino]

You clearly didn’t read completely..
http://haugene.github.io/docker-transmission-openvpn/config-options/#transmission_configuration_options
it lists how transmission options are sorted and links to the official transmission documentation with all options there.. including peer port

[ovizii]

OK, I see what you mean. In this case, it might be a misunderstanding on my side.

The docs say that:

You may still override Transmission options by setting environment variables if that's your thing.

That is not my thing so i read the above sentence thinking that this container image to read the transmission peer port from what I had set in the transmission config and allow it through ufw which seems not to happen unless I explicitly override TRANSMISSION_PEER_PORT inside my docker-compose.yml

I might have misunderstood that sentence because English isn't my first language or there's something else afoot.

I also found this part of the documentation:

Firewall configuration options¶
When enabled, the firewall blocks everything except traffic to the peer port and traffic to the rpc port from the LOCAL_NETWORK and the internal docker gateway.

which led me to think that whatever peer port I set inside transmission will be allowed through.

Again, I may have misread this part of the documentation. If you think its stated clear enough, lets just close this thread. Alternatively it could be worded clearer.

[pkishino]

Hello, sorry for coming of a bit harsh there.. I do believe the documentation has many areas to be improved and some small things like you mentioned at the end need to be updated as they have slightly changed afaik.. It’s always a hassle to get documentation done to everyone’s liking :/ Suggestions are always welcome or even updates directly

…

On Mon, Dec 6, 2021 at 19:20 ovizii ***@***.***> wrote: OK, I see what you mean. In this case, it might be a misunderstanding on my side. The docs say that: You may still override Transmission options by setting environment variables if that's your thing. That is not my thing so i read the above sentence thinking that this container image to read the transmission peer port from what I had set in the transmission config and allow it through ufw which seems not to happen unless I explicitly override TRANSMISSION_PEER_PORT inside my docker-compose.yml I might have misunderstood that sentence because English isn't my first language or there's something else afoot. I also found this part of the documentation: Firewall configuration options¶ When enabled, the firewall blocks everything except traffic to the peer port and traffic to the rpc port from the LOCAL_NETWORK and the internal docker gateway. which led me to think that whatever peer port I set inside transmission will be allowed through. Again, I may have misread this part of the documentation. If you think its stated clear enough, lets just close this thread. Alternatively it could be worded clearer. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2073 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7OFYUFBAUVCHQO3RIXC3LUPSFANANCNFSM5IXEPI6Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[ovizii]

no worries, I understand that this project is done by people in their spare time and of course you can't cater to everyone's level of understanding documentations.
Like I said, I might have misread and that is also the reason why I posted here in discussions - I have seen plenty of people raise bugs and feature requests when the issue was just a lack of understanding.