My knowledge of iptables and network traffic and routing is not the best, so I have some questions:
I run a deluged server bound incoming and outgoing to the enp10s interface in core.conf. This is my default Lan interface with an IP of 192.168.1.100.
On that same server I have a TUN interface for openvpn with an IP of 10.8.0.1.
On my routers LAN interface I see a lot of traffic to a tracker coming from 10.8.0.1 that is denied acces outside. because its the wrong ip range for that interface (should be in the range 192.168.1.0/24).
Does somebody know why this traffic from deluge is going over 10.8.0.1??? Everything is sort of working ok I guess, even announce... so is deluge just using all interfaces to send annouces?
ubuntu server 22.04.04
Client: 2.1.1
Server: 2.1.1
libtorrent: 2.0.5.0
Sorry don't know why happens, as in theory it should work as you say. I would use IPs then instead, and see if still happens, which I would guess not. It sounds like issue with the interface name, and saw recently a couple of posts on libtorrent github about interface VS ip issues, former problematic, unresolved still. Not sure as said, and just thinking out loud. You can check in log if listening sockets made for other than lan ip, e.g that vpn ip, which is what is used for tracker announces - hmm well it must have I guess, since happens already... As said, real IP I guess would fix it, and if dynamic then can script it.
Sorry no better help to offer on this.
Edit: Sorry, was thinking about vpn's when stating possible need scripting dynamic private IPs.
Thanks for the reply! you inspired me to do a little bit more research.
I put the log to debug and actually checked the logs like I should have done in the first place. The listen_interface wants an IP address not a device name (why?). So it's now only listening on my ethernets IP. As it was listening to all devices it was also sending out announces on all interfaces. So it is more of a routing problem on my side, that these are showing up in my routers' logs.
Why 10.8.0.1 is labeled as source on an interface with 192.168.1.100/32 as IP is to me a mystery that I can't solve. So if somebody reads this and knows why, let me know!
It does actually support both device names and IPs, and just that the logs only shows IPs. I tested myself with wlan0 and that works as intended.
I had a hunch that it was the predictable device naming of systemd being your issue, and googled it a little, and found something supporting that thought somewhat - one had issue with a systemd service he made for static networking, because at the time the service ran, the network name was still the old one, etho instead of enp1s0 - systemd renames through udev to the new predictable names. I'm then guessing it's what you experience, but haven't tested it myself, as don't use a service for deluged or have persistent names enabled, and being lazy honestly.
As you just want a lan interface bound, then using IP would be same as interface I guess, and just if using e.g. vpn's with changing private IPs which would be bothersome, so I suppose you would just leave it, but if wanting fix this, then I guess to edit the systemd service to have "after=systemd-udevd.service" or something, to avoid a more ineffecient sleep delay. Again haven't tested and just thinking out loud. Maybe could use old name, eth0, but not good solution imho, because of risk of timing-issues and more. Could also just disable it completely as I do(predictable names), as oldschool and don't have the issues this fixes anyway, just a symlink needed(sudo ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules).
VPN implementations are a tricky thing, generally the safest method is to use a docker container with VPN support already integrated that manages the VPN connection and refuses to make any other requests outside of through the VPN.
I understand that not everyone is familiar with or uses Docker, so this isn't always the obvious option, but with configuring the VPN yourself, as you've found, there are quite a few potential issues that could arise which lead to leaks.
binhex offers a container that supports OpenVPN and implements it correctly if you are interested at all.
Other than that, I unfortunately don't have any experience that could shed any light on the problem. Just thought it was worth mentioning as a potential solution.
Deluge
