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
- 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
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
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.