Opened 7 years ago
#6136 new Bug
Transmission bypasses the default routing
Reported by: | wsw70 | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | None Set |
Component: | Daemon | Version: | 2.92 |
Severity: | Normal | Keywords: | |
Cc: |
Description
Environment:
- transmission-daemon on a LXD container running Ubuntu 14.10.
- The container has an eth0 NIC attached to a bridge (br1 on the host machine which is an Ubuntu 16.10).
- Firewalling on the host prevents traffic other than OpenVPN to leave the container.
- Transmission is bound to the client IP address of the OpenVPN tunnel.
- Connectivity with Internet works and Transmission itself works as well (torrents are downloaded and seeeded).
The issue: the host firwall shows martian packets:
May 29 12:02:16 srv kernel: [580735.649158] IPv4: martian source INTERNET_IP from 10.8.8.30, on dev br1 May 29 12:02:16 srv kernel: [580735.649167] ll header: 00000000: fe fc 8c 49 2b 0b 00 16 3e 7b 86 db 08 00 ...I+...>{....
- INTERNET_IP is the IP of the other side of the tunnel (the address which is set as the source when my packet leaves the tunnel to Internet).
- 10.8.8.30 is the IP of the OpenVPN client to which Transmission is bound to.
This means that packets with source 10.8.8.30 going to INTERNET_IP are found on br2 despite the fact that the default routing is though OpenVPN (and its tun0 interface).
Traffic from other processes go though without problems.
When launching Transmission the martians appear, and stop when Transmission is shut down.
It looks like Transmission forces traffic though an interface, bypassing the default routing which is in the routing table.
Note: See
TracTickets for help on using
tickets.