Request: transmission-remote bind to IPv4 Address

[noctividus]

Since transmission can't bind to a specific interfaces afaik, I would like to request that the transmission-remote command include an option to change the IP address that the client binds to.

[bittaurus]

transmission-remote is a control client for a transmission or transmission-daemon remote. The ip address to which the remote binds is configured through it's own configuration file.

You can find more information on configuration files for various OS archetectures at (https://github.com/transmission/transmission/wiki/Configuration-Files).'

For instance my linux transmission config file is located at ~/.config/transmission/settings.json and contains the entries:

"bind-address-ipv4": "0.0.0.0", "bind-address-ipv6": "::",

where the ip address can be specified.

[barbequesauce]

@noctividus did you perhaps mean that you wanted transmission-remote to be able to tell transmission-daemon to change which IP it is bound to?

[noctividus]

Yes, to clarify- I am aware of what transmission-remote is and how it is used. I am also aware of how to configure address bindings. This is why I phrased this as a feature request.

Since you can't specify an interface, only a IP address, you have to change your configuration file if your IP address changes. I think we can all agree that's something that happens pretty frequently these days. This involves stopping the client, editing the file, and restarting the client.

If this were a feature, you could more easily script that update. You could also do it without stopping your daemon.

[barbequesauce]

Sorry - for clarity:

This involves stopping the daemon, editing the file, and restarting the daemon.

[bittaurus]

I'm not sure what your use case is, but if you have interfaces or ip addresses you are trying to forbid access to your daemon from, you could set your bind address for transmission to 0.0.0.0 to listen on all interfaces, then use a firewall to block access to your port for the interfaces you want to prohibit.

On Fri, Aug 3, 2018 at 10:29 AM, barbequesauce notifications@github.com wrote:

Sorry - for clarity:

This involves stopping the daemon, editing the file, and restarting the daemon.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/transmission/transmission/issues/680#issuecomment-410322810, or mute the thread https://github.com/notifications/unsubscribe-auth/AcTz7E5MMbvsgqBiq8IWL8BzRBs7q-3Yks5uNIh4gaJpZM4VrVaP .

[barbequesauce]

Speaking for my own scenario - one physical interface plus one openvpn tunnel; when the openvpn tunnel comes down and gets built back up, the IP changes. I currently have scripted a scaffold around the event that stops all active torrents, takes transmission-daemon down cleanly, restarts openvpn, and then restarts the transmission-daemon (along with resetting the incoming port for external connectivity).

If transmission-remote could change the IP being bound to by the daemon, it would avoid a lot of scripting/activity...

[bittaurus]

I'm sure there is a routing way to do this thing you want without restarting transmission. Maybe binding transmission-daemon to a localhost address like 127.0.0.2, then setting a up a firewall or nat to DMZ forward all traffic between the localhost address and your tunnel address? I'm not an iptables wizard or anything, but it's an idea since transmission won't rebind while running.

On Fri, Aug 3, 2018 at 11:45 AM, barbequesauce notifications@github.com wrote:

Speaking for my own scenario - one physical interface plus one openvpn tunnel; when the openvpn tunnel comes down and gets built back up, the IP changes. I currently have scripted a scaffold around the event that stops all active torrents, takes transmission-daemon down cleanly, restarts openvpn, and then restarts the transmission-daemon (along with resetting the incoming port for external connectivity).

If transmission-remote could change the IP being bound to by the daemon, it would avoid a lot of scripting/activity...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/transmission/transmission/issues/680#issuecomment-410342865, or mute the thread https://github.com/notifications/unsubscribe-auth/AcTz7DfWxGXsVtQ5XMJWKO4wyrIP6Mh4ks5uNJpbgaJpZM4VrVaP .

[noctividus]

I have a VPN tunnel like probably 90% of transmission users. @barbequesauce gets it. Same use case, I don't want to have to do all that scripting. @bittaurus , do you think this shouldn't be a feature for some reason?

[barbequesauce]

@noctividus here's my script, if it helps - it's for PIA but should be malleable for your use case. https://gist.github.com/barbequesauce/eeaa1c3997627ab81749073a83acd155

[robross0606]

This is such a common situation that I simply don't understand why the developers seem to be so dead-set against addressing it. Let's state this as a "User Story":

If they aren't already, a huge portion of transmission users will be behind a VPN. VPN regularly change their IP address. Users need a full-proof way to "sandbox" transmission to a specific interface where the IP might change. There are backflips and pretzels being accomplished all over the web on ways to try and solve this (split tunnels, iptables packet mangling, etc.). But this could all be solved nicely and neatly if transmission would provide a way to bind ALL traffic to a specific interface. And, by "ALL" I'm including UPNP traffic which also appears to ignore the bind configuration entirely.

[agster27]

This is such a common situation that I simply don't understand why the developers seem to be so dead-set against addressing it. Let's state this as a "User Story":

If they aren't already, a huge portion of transmission users will be behind a VPN. VPN regularly change their IP address. Users need a full-proof way to "sandbox" transmission to a specific interface where the IP might change. There are backflips and pretzels being accomplished all over the web on ways to try and solve this (split tunnels, iptables packet mangling, etc.). But this could all be solved nicely and neatly if transmission would provide a way to bind ALL traffic to a specific interface. And, by "ALL" I'm including UPNP traffic which also appears to ignore the bind configuration entirely.

I agree and also would like this!

[cbrace]

+1

Like the various users above, I also use transmission via a VPN and would greatly appreciate being able to use transmission-remote to set the bind address. I have a script which currently does this by stopping the daemon and editing the settings file when the openvpn connection gets reconfigured, as it does from time to time. A transmission-remote command would be much cleaner and more elegant. Please???

[freddiN]

+1 I have exactly the same usecase.

[inverted360]

+1

[EduCampi]

+1.

I'm trying to switch to transmission from qbittorrent and just found out I cannot bind to an interface in transmission.

Having the option to switch IP without having to bring down the daemon would be great. Google search gives a ton of people with similar issues, there seems have been implemented at one point in the past? Not sure what happened. https://trac.transmissionbt.com/ticket/2313

Thanks

[jbryantd]

+1.

I'm trying to switch to transmission from qbittorrent and just found out I cannot bind to an interface in transmission.

Having the option to switch IP without having to bring down the daemon would be great. Google search gives a ton of people with similar issues, there seems have been implemented at one point in the past? Not sure what happened. https://trac.transmissionbt.com/ticket/2313

Thanks

I used this exact link to setup my system. I use PIA and openvpn on a ddwrt based router. Setup a tun1 eth gateway and redirected all transmission traffic by adapter mac. The adapter i speak of was a second network card installed on my server(et1). Just setup a static ip for that mac address. That ip address got routed down tun1 with a routing entry. This made all the deamon server traffic flow in and out of tun1. Then for the remote access I just let that come through et0 via a dynamic dns address forwarded to my router and setup a routing entry to forward to the static ip of my server's primary network adaptor (et0). The only problem I ever had with this was on server restart windows would randomly initialize the adaptors. This is where I got stuck. It has been a minute since ive had to deal with it and havn;t messed with it since. All I do is upon server restart I log in and have to do a release renew based on how they were initialized. This is a local task and annoying. I was trying to find a way to organize the way windows initializes the ethernet adaptors but no luck. I did this(two network cards) so the server wasn't completely stuck behind a VPN and could still do my bare metal backups, ect. other server shit. That said, running deamon through one adaptor, through a VPN and while having the remote client connect through a dynamic dns outside the tunnel is possible. I do it everyday. It just takes two network adapters.

Edit: The more I think about this now, the less it makes since. But I think that is because even though I could static the two adaptors to a specific IP address on my router, the json file didn't(?) let you use a MAC or IP address to bind, only the name of the adaptor, being eth0 or eth1. I believe that was the genesis of the issues and the need to get windows adaptor initializations under control. Mind you, I havn't messed with updates or a json file in years, so I am not sure if that is still an issue or not. Also said, as far as trying to get the remote clinet to talk through the vpn tunnel, forget about it. That is well outside the scope of transmission, that is a networking layer issue. Drop in a second network card and push all the heavy lifting from the other side. Then the VPN can do whatever IP address changes it likes, it no longer matters. Said, if transmission CAN allow mac binding of local adaptors, then all the worlds problems would be solved. Truth be told, they could have already done that too, I wouldn't know. I actually came here to see if that has been solved yet, but seeing a Jan 19th entry lends me to believe otherwsie.

[cellulosa]

Any ETA on this?

[TCB13]

I'm all for having this feature built-in Transmission, meanwhile people like me who use systemd can simply override the transmission daemon unit and restrict the IP addresses the service can access.

systemctl edit transmission-daemon.service

Then type what you need to override:

[Service]
IPAddressDeny=any
IPAddressAllow=10.0.0.1 # --> your VPN IP here

Save the file and run systemctl daemon-reload followed by systemctl restart transmission-daemon.service and it should be applied.

This might be useful: https://www.ctrl.blog/entry/systemd-application-firewall.html and https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html#Network%20Accounting%20and%20Control

After this if the VPN is down Transmission won't be able to communicate with anything. Enjoy systemd saving the day yet again.

[X8PX]

+1