6

I'm trying to forward traffic from a physical interface enp5s0 to a virtual one tun0. The goal is to make tun0 receive essentially all packets from enp5s0.

First, I enable forwarding with a command

sudo sysctl -w net.ipv4.ip_forward=1

Then I create tun0 by running

sudo ip tuntap add dev tun0 mod tun

I assign it IP-address and turn the device on:

sudo ifconfig tun0 10.1.8.5 netmask 255.255.255.0 promisc up

I want to make all packets go from enp5s0 to tun0, so I have to use iptables. I need to make a rule that allows forwarding from enp5s0 to tun0, so the command is

sudo iptables -A FORWARD --in-interface tun0 --out-interface enp5s0 -j ACCEPT

Then I enable NAT by running

sudo iptables -t nat -A POSTROUTING --out-interface enp5s0 -j MASQUERADE

tcpdump shows no traffic on tun0.

Also, I tried almost the same thing, but using TAP device. I created a bridge with brctl, added tap0 and enp5s0, but no packets were received by tap0 and everything was ok with enp5s0. Nothing like default gw 10.1.8.5 works in TUN case. Where is a mistake?

Nikita Zeulin
  • 61
  • 1
  • 2

2 Answers2

3

Your in and out interfaces are reversed in the iptables command.

They should be:

sudo iptables -A FORWARD --in-interface enp5s0 --out-interface tun0 -j ACCEPT

and:

sudo iptables -t nat -A POSTROUTING --out-interface tun0 -j MASQUERADE
BrendanMcL
  • 81
  • 5
  • I've tried yours and `tcpdump -i tun0` is still empty – Nikita Zeulin May 09 '18 at 13:55
  • 1
    What are you trying to achieve? I have used these commands to set up a vpn over a tun device (which is why I know about the in/out order), however you would normally have something on the other side of the tun0 interface - either the other end of the vpn or a local application that opens the device. Just having the tun0 device with an ip address doesn't mean that traffic will flow - its like having an ethernet port with the cable unplugged. This might be useful: http://www.naturalborncoder.com/virtualization/2014/10/17/understanding-tun-tap-interfaces/ – BrendanMcL May 09 '18 at 22:45
  • Thanks for a link. The goal is to capture all `enp5s0` traffic on `tun0`. I have a program that reads packets from `tun0`, spoofs them and send them back on wire. I've tried `ping` and `traceroute` to test the connection, and the thing is that there are some records on packet going though PREROUTE chain and that's all, packets are not being forwarded even if I make a rule and enable forwarding. – Nikita Zeulin May 11 '18 at 12:39
  • 1
    It's ok to ping tun endpoint from the forwarding host(the tun gateway). But it does not work on the other hosts -- IP packets are forwarded to the (gateway) tun device without NAT, so the endpoint won't be able to response to the 'correct' source IP. So the below rule saved my day: `udo iptables -t nat -A POSTROUTING --out-interface tun0 -j MASQUERADE` – clarkttfu Jun 12 '20 at 12:11
0

The problem is to make the packets WANT to go to that interface. This can be done either by routing or iptables.

First test: from your own host, ping something like 10.1.8.57. It should show up in your tcpdump. If it doesn't, nothing else will ever work. so fix it.

Start with routing. On the host declare a network on the other end of tun0, which I believe you've made 10.1.8.0/24. Put an entry for that on a host on the other end of the enp5s0 link, routing to your host. From that host, ping something like 10.1.8.57. This should show up in your tcpdump.

On to iptables. In this case, I think what you want is to take packets normally traveling to your host, and forward them on to the TUN interface. The trick for this is a DNAT rule. I think something like:

iptables -t nat -A PREROUTING --in-interface enp5s0 -j DNAT --to-destination 10.1.8.57
iptables -t nat -A OUTPUT --in-interface enp5s0 -j DNAT --to-destination 10.1.8.57

(Actually, this target is valid on PREROUTING and OUTPUT, and I apparently put it on both when I used it. I'm not sure if you need both, or just one, or if they do different cases.) For early testing, I recommend addition additional restrictions on what is rerouted, like adding -p tcp -m tcp --dport 5000 and then trying to connect to port 5000. If you aren't careful, you could block yourself out of the machine altogether.

David G.
  • 1,314
  • 1
  • 4
  • 15