0

I modified my iptables according to the answer from Musclehead here so that my transmission-daemon can just send outgoing traffic to tun0 (which is a VPN).

(Hint: My eth0 is called enp3s0.)

Now, if I add a torrent to download and I watch the traffic with sudo iptables -L -v the only increasing numbers are related to the INPUT chain with enp3s0 (which is my ethernet port). The numbers add up with the status I get from the VPN.

Does this mean that I download to my original WAN address instead of the tunnel?

I would think that when I add a torrent the information about downloading it will be sent with tun0 and so the answer should come back on that IP range.

As you can see here with two outputs I generated just seconds apart the traffic increases from 1356M to 2201M on the enp3s0 device.

 $ sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2417  172K f2b-sshd   tcp  --  any    any     anywhere             anywhere             multiport dports ssh
 170K   17M ACCEPT     all  --  tun0   any     anywhere             anywhere            
 330K 1356M ACCEPT     all  --  enp3s0 any     anywhere --THIS LINE anywhere            
  942  134K ACCEPT     all  --  lo     any     anywhere             anywhere

...


Chain OUTPUT (policy ACCEPT 483K packets, 269M bytes)
 pkts bytes target     prot opt in     out     source               destination

   19  6545 ACCEPT     tcp  --  any    enp3s0  anywhere             192.168.100.0/24     tcp spt:9091 owner GID match debian-transmission
    0     0 ACCEPT     udp  --  any    enp3s0  anywhere             192.168.100.0/24     udp spt:9091 owner GID match debian-transmission
 229K  210M ACCEPT     all  --  any    tun0    anywhere             anywhere             owner GID match debian-transmission
  221 57168 ACCEPT     all  --  any    lo      anywhere             anywhere             owner GID match debian-transmission
   92  5372 REJECT     all  --  any    any     anywhere             anywhere             owner GID match debian-transmission reject-with icmp-port-unreachable


...

Second output seconds later:

$ sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2431  173K f2b-sshd   tcp  --  any    any     anywhere             anywhere             multiport dports ssh
 170K   17M ACCEPT     all  --  tun0   any     anywhere             anywhere            
 384K 2201M ACCEPT     all  --  enp3s0 any     anywhere --THIS LINE anywhere            
  942  134K ACCEPT     all  --  lo     any     anywhere             anywhere

...


Chain OUTPUT (policy ACCEPT 536K packets, 272M bytes)
 pkts bytes target     prot opt in     out     source               destination

   19  6545 ACCEPT     tcp  --  any    enp3s0  anywhere             192.168.100.0/24     tcp spt:9091 owner GID match debian-transmission
    0     0 ACCEPT     udp  --  any    enp3s0  anywhere             192.168.100.0/24     udp spt:9091 owner GID match debian-transmission
 229K  210M ACCEPT     all  --  any    tun0    anywhere             anywhere             owner GID match debian-transmission
  221 57168 ACCEPT     all  --  any    lo      anywhere             anywhere             owner GID match debian-transmission
   92  5372 REJECT     all  --  any    any     anywhere             anywhere             owner GID match debian-transmission reject-with icmp-port-unreachable


...

I will also add my routing table outputs for better understanding:

 $ ip route show table local
broadcast 10.8.8.0 dev tun0  proto kernel  scope link  src 10.8.8.5 
local 10.8.8.5 dev tun0  proto kernel  scope host  src 10.8.8.5 
broadcast 10.8.8.255 dev tun0  proto kernel  scope link  src 10.8.8.5 
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.100.0 dev enp3s0  proto kernel  scope link  src 192.168.100.91 
local 192.168.100.91 dev enp3s0  proto kernel  scope host  src 192.168.100.91 
broadcast 192.168.100.255 dev enp3s0  proto kernel  scope link  src 192.168.100.91
bomben
  • 2,059

1 Answers1

0

I checked with the guys from the VPN compandy and they analysed the following output. They said that both the IPs (I changed them) are VPN IPs so my VPN is not leaking but connected correctly. And it is also transferring some ssh traffic of course because I am logged into the PC with it.

But they found it strange that this traffic to tun0 is not visible in the iptable chain I posted in my question. See below.

Regarding the fact that the traffic is going via enp3s0, this is correct, because the traffic from tun0 gets forwarded (encrypted) to the ethernet port.

 $ sudo tcpdump -i enp3s0 not src 84.17.47.59
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:35:14.533573 IP 192.168.100.91.ssh > 192.168.100.210.59004: Flags [P.], seq 835793677:835793865, ack 3278619125, win 318, options [nop,nop,TS val 19307620 ecr 4023390051], length 188
10:35:14.534084 IP 192.168.100.91.47524 > 203.179.83.129.openvpn: UDP, length 164
10:35:14.534399 IP 206.189.83.129.openvpn > 192.168.100.91.47524: UDP, length 468

Also, my firewall rules from ufw where missing from the INPUT, FORWARD and OUTPUT chains as well as other ufw-specific chains. Like those:

  199 13931 ufw-after-output  all  --  any    any     anywhere             anywhere            
  199 13931 ufw-after-logging-output  all  --  any    any     anywhere             anywhere            
  199 13931 ufw-reject-output  all  --  any    any     anywhere             anywhere            
  199 13931 ufw-track-output  all  --  any    any     anywhere             anywhere

Once I removed the package and settings, and purged all specific chains from iptables and then setup everything from scratch it worked. Incoming traffic to tun0 is now also visible.

To answer the question: Yes, outgoing traffic will eventually be transfered to eth after beeing tunneled in tun0. Both values should add up.

bomben
  • 2,059