Combining NAT an tunneling

Question

I was reading a text and a doubt came to mind. Suppose there is an interface in a router that implements NAT. That same interface is the extreme of a tunnel. If I was to send a message through said tunnel, the origin address of the inner IP header would be the same, or it would have it's corresponding translation to a public address?

I will show an example to illustrate this.

PC1 wants to send a datagram to PC2, which is in another network. Both networks are connected through a tunnel that has it's extreme in router R1's interface. This same interface implements NAT (Network address translation).

To R1 arrives the datagram with

IP source address: 10.10.10.1

IP destination address: 192.168.0.1

A new datagram with an outer and inner header will leave R1. The one outside will have the addresses corresponding to the extremes of the tunnel. For the inner header I do not know which one of these would apply

Option 1.

IP source address: 100.0.0.1 (NAT translation of 10.10.10.1)

IP destination address: 192.168.0.1

Option 2.

IP source address: 10.10.10.1

IP destination address: 192.168.0.1

Thank you all in advance, any help would be appreciated! : )

Answer 1

Why guess if we can check and see what happens?

I've prepared a topology that represents your scenario that we will use for experiments.

Note that tunnels are not magically working, they require the underlay network to be properly configured. For the underlay network configuration, I've set up eBGP sessions between routers to get it up and running. It does not matter much for the question, so let's concentrate on NAT and tunneling.

Stage 1. No NAT, no tunnel. Let's see how the packet looks like when traveling "normally" w/o NAT or tunneling as seen on the link between cumulus6 and cumulus5.

Nothing fancy, huh? Exactly as one would expect so far.

Stage 2. Adding NAT. Let's then configure the NAT rule. Note that to set up NAT we would need to have two interfaces: inside and outside. For our topology, for cumulus6 the inside would be swp2 and the outside would be swp1.

Here is how Dynamic NAT is configured with Cumulus VX.

net add nat dynamic snat icmp source-ip 10.0.0.0/24 out-interface swp1 translate 100.0.0.1-100.0.0.1

It basically says that we need to dynamically translate based on the source address and outbound interface swp1 into address 100.0.0.1. Note how the protocol is set to icmp -- that's for simplicity. How ICMP works with NAT it's a topic of another discussion, but basically, the same way as it does for UDP and TCP. It does not matter for our question too much though.

Let's now see how the same ping between PCs will be seen now!

Okay! Now we got our addresses translated. Our host PC now looks like the cumulus6 on the wire to other devices.

Final stage. NAT and the tunnel. Now we are ready to build the tunnel and see! As was said before tunnel relies on the underlay network for transport. I've configured the GRE tunnel with IP endpoint addresses of 10.99.99.1 on cumulus6 and 10.99.99.2 on the cumulus4 on the other side of the topology and 100.0.0.1/200.0.0.1 for underlay transport.

I've also added a static route to force traffic for 192.168.0.2 to go to the tunnel interface, and here you have it.

As you can see the outer IP header is providing the transport between cumulus6 and cumulus4.

The answer. Now we are ready to give an informed answer to your question. The inner IP packet has NOT translated source IP address 10.0.0.2. You can even intuit that given the NAT definition -- when we created the NAT translation rule we had to specify the outbound interface. NAT will only be applicable if we use that interface as outbound for the traffic (swp1 in our case), however, our packet gets routed to the tunnel interface instead, so it is not applicable!

Hope this was helpful! At least it was fun to play with :)

Answer 2

In common you can think of NAT and tunneling as two different processes. Tunneling is something in kernel, but firewall/NAT is usually something tied to interface. NAT is dealing with real packets on interface, that is most common scenario. It can be BSD, Cisco or anything else - the packet processing will be almost the same:

1. Packet arrive into kernel and been analyzed with firewall. Firewall pass it to kernel.
2. Kernel receive packet and analyze routing table to pass it. In your case routing table will pass packet into tunnel interface and this action will originate new packet (with outer tunnel addresses).
3. New packet will be processed against routing table again to find next hop.
4. Kernel will try to send packet through specific interface.
5. Firewall will analyze packet before sending on interface and apply NAT if it match NAT rule.

So, If your NAT rule is tied to outbound interface and contain something like 10.10.10.0/24 -> 100.0.0.1 it will not match tunneled packet which will be already 100.0.0.1 to someone. That also means your Option 2 will happen inside this encapsulated packet.

Answer 3

I think you mean the NAPT version of NAT that allows many devices behind the NAPT device to share the outside address.

Remember that any packets that arrive at an interface doing NAPT and are not in a NAT table are destined for the NAT device itself. That means that the router will recognize that the traffic destined for the tunnel interface gets sent to the tunnel interface of the router. That is explained in RFC 3022, Traditional IP Network Address Translator (Traditional NAT):

In NAPT setup, where the registered IP address is the same as the IP address of the stub router WAN interface, the router has to be sure to make distinction between TCP, UDP or ICMP query sessions originated from itself versus those originated from the nodes on local network. All inbound sessions (including TCP, UDP and ICMP query sessions) are assumed to be directed to the NAT router as the end node, unless the target service port is statically mapped to a different node in the local network.

Sessions other than TCP, UDP and ICMP query type are simply not permitted from local nodes, serviced by a NAPT router.