udp and tcp packets to port 51413 trying to bypass default routing?

Ask for help and report issues not specific to either the Mac OS X or GTK+ versions of Transmission
Post Reply
wsw70
Posts: 2
Joined: Mon May 23, 2016 2:36 pm

udp and tcp packets to port 51413 trying to bypass default routing?

Post by wsw70 »

Hello

I run Transmission in a Linux container (LXD) which also runs an OpenVPN client. The firewall this container is connected to only allows OpenVPN packets to go through.

I get, however, rejected packets from this container coming from Transmission (which otherwise works fine) like these ones:

Code: Select all

May 23 16:29:21 srv kernel: [78380.618018] Shorewall:vpn-int:REJECT:IN=br1 OUT=int0 MAC=fe:...:00 SRC=10.10.11.1 DST=A.B.C.D LEN=58 TOS=0x00 PREC=0x00 TTL=63 ID=7810 DF PROTO=UDP SPT=51413 DPT=51413 LEN=38
May 23 16:29:24 srv kernel: [78383.637747] Shorewall:vpn-int:REJECT:IN=br1 OUT=int0 MAC=fe:...:00 SRC=10.10.11.1 DST=A.B.C.D LEN=58 TOS=0x00 PREC=0x00 TTL=63 ID=8187 DF PROTO=UDP SPT=51413 DPT=51413 LEN=38
May 23 16:29:31 srv kernel: [78389.710171] Shorewall:vpn-int:REJECT:IN=br1 OUT=int0 MAC=fe:...:00 SRC=10.10.11.1 DST=A.B.C.D LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=7212 DF PROTO=TCP SPT=38382 DPT=51413 WINDOW=7300 RES=0x00 SYN URGP=0
where
  • 10.10.11.1 is the IP of the container (on br1, int0 being the interface on Internet)
  • A.B.C.D is the public IP address of the other side of my OpenVPN tunnel. In other words, this is the IP which is seen as "source" for the traffic originating from my OpenVPN tunnel
https://trac.transmissionbt.com/wiki/Po ... rdingGuide explains that 51413 is the default port for sharing and I do have a sustained upload.

Now, OpenVPN builds its own routing table in a clever way:

Code: Select all

0.0.0.0/1 via 10.8.8.13 dev tun0
default via 10.10.11.254 dev eth0
A.B.C.D via 10.10.11.254 dev eth0
10.0.0.0/8 dev eth0  proto kernel  scope link  src 10.10.11.1
10.8.8.1 via 10.8.8.13 dev tun0
10.8.8.13 dev tun0  proto kernel  scope link  src 10.8.8.14
10.10.10.0/24 via 10.10.12.254 dev eth0
10.10.13.0/24 via 10.10.13.1 dev eth0
128.0.0.0/1 via 10.8.8.13 dev tun0
It keeps the existing table (with its default gateway) and adds the routes 0.0.0.0/1 and 128.0.0.0/1 to cover all IPV4 IP range , effectively routing all the traffic via one of these two routes (this way, when it is shut down, one reverts to the original gateway and other routes).

In that context I do not understand why these packets generated by Transmission try to bypass the tunnel?

Any pointers are very much appreciated. Thank you.
wsw70
Posts: 2
Joined: Mon May 23, 2016 2:36 pm

Re: udp and tcp packets to port 51413 trying to bypass default routing?

Post by wsw70 »

x190 wrote: #2 I don't fully understand what exactly you are seeing or asking about, but you can set Transmission to bind to a specific address, but you cannot set it to bind to a specific interface. Please see trac ticket #2313 for more details.
Sorry for not having been clear enough, I wanted to convey the whole story. In short: Transmission is sending packets bypassing the default route.

Following your comment I bound it to an IP address (of the OpenVPN tunnel) nad I now have martian packets:

Code: Select all

May 24 08:58:06 srv kernel: [137702.801813] IPv4: martian source A.B.C.D from 10.8.8.14, on dev br1
May 24 08:58:06 srv kernel: [137702.801823] ll header: 00000000: fe e7 6c 44 d5 c8 00 16 3e 7b 86 db 08 00        ..lD....>{....
May 24 08:58:09 srv kernel: [137705.827352] IPv4: martian source A.B.C.D from 10.8.8.14, on dev br1
May 24 08:58:09 srv kernel: [137705.827355] ll header: 00000000: fe e7 6c 44 d5 c8 00 16 3e 7b 86 db 08 00        ..lD....>{....
May 24 08:58:15 srv kernel: [137711.871118] IPv4: martian source A.B.C.D from 10.8.8.14, on dev br1
May 24 08:58:15 srv kernel: [137711.871149] ll header: 00000000: fe e7 6c 44 d5 c8 00 16 3e 7b 86 db 08 00        ..lD....>{....
This means that, indeed, Transmission is not following the expected route, forcing packets on interfaces where they do not belong. I will open a bug report on that.

Thank you for your help.
Post Reply