How To Make All Traffic To Go Through One Interface In Linux
As you guess I am trying to build an anticensorship tool.
Decision about tunneling must be taken inside tun0 process
because only there we may use trusted DNS.
I need your help to show me how to make all traffic flow through a self-written interface tun0. If tun0 needs changes I ask you to provide such changes.
Below is how I tried to make all traffic go through tun0 and failed (pings fail).
Compiling
Configuring
$ cat /etc/iproute2/rt_tables # # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep 200 John - sudo ip rule add from all lookup John
- sudo ip route add default dev tun0 table John
- sudo ip rule add iif tun0 lookup main priority 500
$ ip rule 0: from all lookup local 500: from all iif tun0 lookup main 32765: from all lookup John 32766: from all lookup main 35000: from all lookup default Troubleshooting
- sudo tcpdump -i wlp2s0 -qtln icmp and then ping -I tun0 8.8.8.8 shows no packets captured, it means no packets are transmitted from tun0 to wlp2s0 via iif tun0 lookup main rule.
- When I replaced tun0 with lo everywhere then it worked for me.
Also Tried
Answer Troubleshooting
iptables -I FORWARD -j LOG --log-prefix "filter/FORWARD " iptables -t nat -I OUTPUT -j LOG --log-prefix "nat/OUTPUT " iptables -t nat -I PREROUTING -j LOG --log-prefix "nat/PREROUTING " iptables -t nat -I POSTROUTING -j LOG --log-prefix "nat/POSTROUTNG " tail -f /var/log/syslog Modified sources from answer are also here.
1 Answer 1
So in your configuration, all the packets you try to send to the network initially originating from 10.0.0.1 (because they are going through tun0 interface and its local address is 10.0.0.1 ). You capture the packets, everything is fine so far.
Now, tun0 sends the packets further. Source address is 10.0.0.1 and you want the packets to leave through a different interface ( wlp2s0 in your case). That’s routing so let’s enable routing first:
sysctl -w net.ipv4.ip_forward=1 After that, if you’ll look at tcpdump for wlp2s0 you can notice the packets leave with source address 10.0.0.1 and not with the source address of the wlan interface (what you would expect I guess). So we need to change the source address and it’s called source NAT. In linux it’s easy with help of netfilter/iptables:
iptables -t nat -A POSTROUTING -o wlp2s0 -s 10.0.0.1 -j MASQUERADE Please also check that your FORWARD chain has ACCEPT policy or you would need to allow forwarding with something like:
iptables -A FORWARD -i tun0 -o wlp2s0 -s 10.0.0.1 -j ACCEPT iptables -A FORWARD -i wlp2s0 -o tun0 -d 10.0.0.1 -j ACCEPT Everything should work now: linux kernel does the routing, it’s moving packets from tun0 interface to wlp2s0 . netfilter should change the source IP 10.0.0.1 to your wlp2s0 interface assigned address for output packets. It memorizes all the connections and when the reply packets go back (if they) it changes the destination address of the wlp2s0 interface assigned address to 10.0.0.1 (the «conntrack» feature).
Well, it should but it doesn’t. It seems, netfilter gets confused with this complicated routing configuration and the fact that the same packet first goes through the OUTPUT chain and then being routed and comes to PREROUTING chain. At least on by Debian 8 box it doesn’t work.
The best way to troubleshoot netfilter is the TRACE feature:
modprobe ipt_LOG iptables -t raw -A OUTPUT -p icmp -j TRACE iptables -t raw -A PREROUTING -p icmp -j TRACE I only enable tracing for ICMP packets, you may use other filter to debug.
It will show what tables and chains the packet goes through. And I can see that the packet goes no further the FORWARD chain (and it’s not being caught by the nat/POSTROUTING chain that actually does SNAT ).
Below are several approaches to make this work.
APPROACH #1
The best way to un-confuse netfilter is to change the source IP address of packets in tun0.c application. It’s also the most natural way. We need to change 10.0.0.1 to 10.0.0.2 on the way outwards and 10.0.0.2 to 10.0.0.1 on the way back.
I’ve modified tun0.c with source address change code. Here is the new file and here is patchfile for your tun0.c . Changes to IP header also involve checksum correction, so I took some code from OpenVPN project. Here is the full list of commands I execute after a clean reboot and tun0_changeip.c launch:
ifconfig tun0 inet 10.0.0.1/30 up sysctl -w net.ipv4.ip_forward=1 ip route add default dev tun0 table John ip rule add from all lookup John ip rule add from 10.0.0.2 lookup main priority 500 iptables -t nat -A POSTROUTING -o wlp2s0 -s 10.0.0.2 -j MASQUERADE Please note that you don’t need to turn off the reverse path filtering in that case, because everything is legal — tun0 only receives and sends packets that belong to its subnet. Also you can do a source-based routing instead of interface-based.
APPROACH #2
It’s possible to do SNAT before the packet reach tun0 interface. It’s not very correct though. You will definitely need to turn off the reverse path filtering in this case:
sysctl -w net.ipv4.conf.tun0.rp_filter=0 # It won't work without also changing the "all" value sysctl -w net.ipv4.conf.all.rp_filter=0 Now, do SNAT : iptables -t nat -A POSTROUTING -o tun0 -s 10.0.0.1 -j SNAT —to-source ip.address.of.your.wlan.interface
Here we change the source address just before the packets reach the tun0 device. tun0.c code resend these packets «as is» (with changed source address) and they are successfully routed through wlan interface. But you might have a dynamic IP on wlan interface and want to use MASQUERADE (in order to not specify the interface address explicitly). Here is how you can make use of MASQUERADE :
iptables -t nat -A POSTROUTING -o tun0 -s 10.0.0.1 -j SNAT --to-source 10.0.55.1 iptables -t nat -A POSTROUTING -o wlp2s0 -s 10.0.55.1 -j MASQUERADE Please note the » 10.0.55.1 » IP address — it’s different. You can use any IP here, it doesn’t matter. The packets reach nat/POSTROUTING chain on wlp2s0 interface if we change the source IP before. And now it’s not dependent on a static IP for wlan interface.
APPROACH #3
You can also use fwmark . That way you don’t need SNAT but you’ll capture only outgoing packets:
First we need to disable reverse path filtering for tun0 because it will forward packets that belong to another network:
sysctl -w net.ipv4.conf.tun0.rp_filter=0 # It won't work without also changing the "all" value sysctl -w net.ipv4.conf.all.rp_filter=0 Now let's alter the routing rules a bit: # Delete old rules ip rule del iif tun0 lookup main ip rule del from all lookup John # Packets will start going from wlan interface so they will have source address of it iptables -t mangle -A OUTPUT -o wlp2s0 -j MARK --set-mark 1 ip rule add fwmark 0x1 lookup John That’s another «hack» for routing and netfilter that works on my Debian 8 box, but still I recommend to take the first approach as it’s more natural and doesn’t use any hacks.
You may also consider to build your application as a transparent proxy. I think it would be much easier instead of analyzing packets from tun device.
How can I route all traffic from one interface to another interface and keep the same ports?
since I am fairly new to networking in general, but need to implement a specific scenario I would like to ask for support. Thanks for everything in advance. I have a following scenario, on my machine A I have a software running which is usually connected to machine B via an ethernet cable. What I would like to do now is to connect to machine B remotely via an in-between router/device from machine A , lets call this new device machine C . I believe that I will need to work with IP routing using iptables . Note: machine A is not in the same subnet as machine B So the scenario will look like this:
192.168.20.X machine A 10.8.0.55 10.8.0.50 machine C 192.168.27.1 192.168.27.100 machine B - If machine C is unaware of machine B’s ip address, but I know it is connected with its eth0 interface, can I still route traffic to its eth0 ip address under the condition that machine A is sending packets destined to machine B? For example using the gateway tap0?
- If machine A and C are unaware of machine B’s ip address, is it possible to route traffic to B’s eth0 ip address? Or would that packet be discarded because it doesnt contain the destination IP address?
- Can I forward packets in machine C to different interfaces and keep the same ports?
I was following this guide without implementing the firewall rules, but I was unable to connect properly because it was using hardcoded IP address which I would like to avoid, I would like to forward the traffic from tap0 to eth0 in machine C and in best case not need to know machine B’s ip address.
I was trying to use these rules in machine C but to be honest I am not understanding them very well.
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE sudo iptables -A FORWARD -i eth0 -o tap0 -m state --state RELATED,ESTABLISHED -j ACCEPT sudo iptables -A FORWARD -i tap0 -o eth0 -j ACCEPT If you could reference me to some easy to understand resources, I would check them out as well. Thank you.
EDIT: I have added a simplified layout of the scenario. I was figuring out that I possible need to use NAT.
From machine A I tried to send packets to machine C using ping 10.8.0.50 where machine B has ip address: 192.168.27.106 . When I send packets from machine A to C I want it to change the packets source and destination address, so I’ve applied:
sudo iptables -t nat -A PREROUTING -i tap0 -j DNAT --to 192.168.27.100 sudo iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 10.8.0.55 Using sudo tcpdump -i eth0 on machine B I got a correct ICMP request. However, the echo didnt go back to machine A. Naturally I thought I’d need to apply the iptables rule back again to machine A. So I’ve applied:
sudo iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 10.8.0.55 sudo iptables -t nat -A POSTROUTING -o tap0 -j SNAT --to 192.168.27.100 I was able to send the packets through to machine B, but didnt get the reply back to A. I feel like something is missing. Any ideas?