Score:0

NAT Between TUN and Ethernet Network Interfaces

pl flag

There's a detailed explanation of the setup and my debugging efforts so far, but the main question is at the bottom.

I have a setup like so:

  • Machine A has two network interfaces: eth0 (192.168.159.60) and mesh0 (10.255.0.1), where eth0 has a route to 0.0.0.0/0 and mesh0 is a TUN interface being used in a mesh network.
  • Machine B has one network interface: mesh0 (10.255.0.2), where mesh0 is also TUN interface.
  • mesh0 on A and mesh0 on B are wirelessly connected.

I would like to be able to send traffic from B, through A, to some external machine. Essentially, A is a gateway for B.

ip route for A:

default via 192.168.144.1 dev eth0
10.255.0.0/16 dev mesh0 proto kernel scope link src 10.255.0.1
10.255.0.2 via 10.255.0.2 dev mesh0 proto 100 src 10.255.0.1 metric 2 onlink
192.168.144.0/20 dev eth0 proto kernel scope link src 192.168.159.60

ip route for B:

default via 10.255.0.1 dev mesh0 proto 100 src 10.255.0.2 metric 2 onlink 
10.255.0.0/16 dev mesh0 proto kernel scope link src 10.255.0.2 
10.255.0.1 via 10.255.0.1 dev mesh0 proto 100 src 10.255.0.2 metric 2 onlink

Step 1: Verify packets from A to B The connection between A and B is working as expected. If I run ping -I mesh0 8.8.8.8 on B, and I run sudo tcpdump --interface mesh0 on B, it outputs:

21:08:59.701208 IP 10.255.0.2 > dns.google: ICMP echo request, id 43, seq 374, length 64

So I know that my packets are getting from B to A.

Step 2: Verify packet forwarding on A Next, I checked whether A was forwarding the packets it received on mesh0 to eth0. If I run sudo tcpdump --interface eth0, I see:

21:15:00.581098 IP 10.255.0.2 > dns.google: ICMP echo request, id 44, seq 5, length 64

So I know that the packet forwarding on A is working as expected. However, there is no corresponding ICMP echo reply. For some reason, the request is going out on eth0, but no response is coming back.

Step 3: Test the same ping from A To confirm that it's not an issue with the external server or the eth0 interface itself, I ran ping -I eth0 8.8.8.8 and sudo tcpdump --interface eth0 on A. The tcpdump shows:

21:12:45.878014 IP 192.168.159.60 > dns.google: ICMP echo request, id 11669, seq 6, length 64
21:12:45.882465 IP dns.google > 192.168.159.60: ICMP echo reply, id 11669, seq 6, length 64

And the ping succeeds. So, I know it's not an issue with the eth0 interface or the server I'm trying to ping.

All of this leads me to the conclusion that the issue is with the next hop not knowing where to route the ICMP echo response to. Problem: I need NAT on A from mesh0 to eth0.

Question: How can implement NAT between mesh0 and eth0, so that response packets from external machines (e.g. 8.8.8.8) are routed back to eth0 so they can be forwarded to mesh0?

Tom Yan avatar
in flag
Your question seems a bit weird to me. I mean, are you totally unaware that you can set up SNAT with iptables / nftables on Linux or what? Or are you looking for guides for their syntax or so? (It's essentially a one-liner especially in the case of iptables.)
Nikita Kipriyanov avatar
za flag
The mentioned basic one-liner is `iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE`; it doesn't matter which interface packets were in, whether that's mesh0 or even eth0 itself; if they are destined to *output* eth0 they will be SNATed. Probably you'd want to restrict it to whatever neworks sits behind mesh0 (add `-s 10.255.0.0/24` or something like that). What is specific problem with that?
Tom Yan avatar
in flag
You can have either or both the `-s` and `-o` match btw. The `-o` match can sometimes be undesirable if the interface (name) changes from time to time.
pl flag
@NikitaKipriyanov do you know the equivalent one-liner for nftables?
Nikita Kipriyanov avatar
za flag
It is not possible to have easy one-liner for nftables — you need to create chains and everybody is free to give them names as they wish, whereas in iptables they are fixed. However, you can always change `iptables` to `iptables-translate` in any iptables command and it will give you a great hint how the corresponding nftables rule should look like.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.