4

For TCP and UDP NAT users port info. For other protocols like ICMP it can use protocol specific tricks. What happens if an IP protocol is used which isn't catered for or recognised?

Can such a packet even leave the target interface? If so, what happens? Does the source IP just get changed? What happens on the way back? Is it possible that a return packet can go to the wrong ip? Perhaps even all ips available?

8

For TCP and UDP NAT users port info. For other protocols like ICMP it can use protocol specific tricks.

Well, the same TCP and UDP are also "protocol-specific tricks" – they're really no different from ICMP Echo "request IDs", or IPsec "SPIs". (NAT itself is a 'trick'.)

Can such a packet even leave the target interface? If so, what happens? Does the source IP just get changed?

Usually, yes. Most NATs will pass through such packets even if they don't recognize the inner protocol, since it still has a bigger chance of working than "drop everything".

What happens on the way back?

Depends on whether the NAT actually kept track of the outgoing packet. (It varies.)

Even if the NAT doesn't understand how to extract ports or IDs out of the inner protocol, it can still keep track of the protocol type, which might be enough for some situations. (Every IP packet has a protocol-type field, so what you call "raw IP" is merely a case of "unknown IP protocol type".)

For example, a TCP connection (IP protocol 6) and an ICMP Ping (IP protocol 1, ICMP type 8) would be tracked as:

  • host 192.168.1.2 (as 42.0.2.1) → 62.205.132.12, proto 6, port 21445 → 80
  • host 192.168.1.2 (as 42.0.2.1) → 62.205.132.12, proto 1, type 8 code 0 id 1227

Meanwhile, an unrecognized protocol such as a 6in4 tunnel would be tracked as:

  • host 192.168.1.2 (as 42.0.2.1) → 62.205.132.12, proto 41,

Therefore, all incoming protocol-41 packets would be forwarded back to 192.168.1.2. This means that one computer could still speak the protocol, but two computers at once probably couldn't. (Much like with UDP, some NATs also check the source IP address, but many only care about protocol & port.)

While I used 6in4 in the example above, the same would also happen with all protocols that the NAT doesn't understand, even if they do have ports (e.g. UDP-Lite or SCTP).

  • Aside: If your router happens to run Linux, you could run conntrack -L or cat /proc/net/nf_conntrack to see all states currently being tracked. Some routers even show this in their web UI.

Finally, if the NAT didn't keep any state at all, then the packet is assumed to be destined to the router itself (same as with any other untracked incoming packet), and usually gets dropped on the floor.

Is it possible that a return packet can go to the wrong ip?

In the simplest case, no. Either the NAT can associate the return packet with some known state, or it cannot, but it won't randomly make up garbage. (Usually.)

However, if two computers behind the LAN are trying to speak the same protocol to the same remote host, then their states can conflict. Which one wins can vary – either the oldest state is used until it expires (so replies for both computers keep going to the 1st one), or they keep overriding each other every few moments (i.e. it flip-flops between both). It's a situation that dynamic NAT was definitely not designed for...

Perhaps even all ips available?

No. It's possible in theory – e.g. some people do this with static port-forwarding configurations for Wake-on-LAN – but doing it by default wouldn't be very useful. If anything, it would make your LAN more vulnerable to spoofed packets.

(Though, as it happens, that's actually how Ethernet switching works – packets for unknown MACs are flooded through all physical ports.)


As a side note, this is not actually specific to IPv4 NATs. State tracking is an integral part of a stateful firewall, used both by IPv4 and IPv6. Even without NAT/PAT, the state tracking also allows the firewall to automatically accept all known packets and reject unknown ones.

So when people claim that "NAT adds security", they're actually talking about the firewall configuration that usually comes with it (and can be used equally well without NAT).

4
  • Thanks, very helpful. This hits most of the key points I was thinking about. The most interesting point for me - which is something I'd reasoned was possible - is the conflict with two hosts trying to speak the same protocol. The main use case I have in mind is clients connection to a VPN. I was concerned that in some (admittedly, probably rare) situations there would at best be reliability issues and at worst be potential security holes. It sounds like my understanding of NAT is pretty good and if I need to say concretely what's going to happen I'm going to have to dig into kernel code. Aug 3 '16 at 14:31
  • Also, at the risk of becoming subjective, some pointers to sources of exact truth would be helpful, e.g. particular linux docs or source files. Aug 3 '16 at 14:35
  • There can be reliability issues with PPTP (due to GRE lacking ports – but PPTP ought to die already), and sometimes with IPsec (although most clients support NAT-T over UDP nowadays). Many other VPN products run everything over UDP and have no problems, although they do need to ping the server frequently to avoid state expiry.
    – user1686
    Aug 3 '16 at 15:47
  • For NAT as implemented in Linux, see net/netfilter/nf_conntrack*.c (where the state tracking is implemented) and the conntrack tool (for examining exactly what states are known right now).
    – user1686
    Aug 3 '16 at 15:50
2

NAT is an interesting topic.

There are three types of NAT:

  • Static
  • Dynamic
  • PAT

PAT is what most consumer routers use, so lets go for that one.

Lets imagine I have this layout at home:

Router   192.168.0.1
PC 1     192.168.0.2
PC 2     192.168.0.3
External IP 1.1.1.1 (Lets assume I have that one)

Both my computers want to connect to www.superuser.com which has the ip 151.101.65.69.

I load up my browser on PC1 and type in www.superuser.com and the following happens:

  • My computer asks my DNS server to resolve www.superuser.com to an IP
  • DNS Server comes back with 151.101.65.69
  • My computer opens a random source port number, lets say 40000 in this case.
  • My computer Sends a packet to 151.101.65.69 from the source 192.168.0.2 and puts the sequence number 1 on it.
  • The router intercepts that packet, and changes the source from 192.168.0.2 to our 1.1.1.1 and makes note that it came from 192.168.0.2:40000.
  • Super user gets the packet, and sends a response to 1.1.1.1
  • Router receives the response, looks at the sequence number and says "Aha, that's for 192.168.0.2, I better send it to him on port 40000, hes expecting it on that.

At the same time PC 2 could go to the same process, but will most likely pick a separate port. The router keeps notes of these port numbers and shuffles the traffic as needed to the correct destination.

The router will keep a table like this:

Source              Destination
192.168.0.2:40000   151.101.65.69:80
192.168.0.3:56944   151.101.65:69:80

Now you ask, "But Lister, what happens if the random port number you have chosen is already in use? You have broken the system Lister!" That's completely fine, the router will increment the port number in his list to the next available one, but will remember to send back the information on the correct port to the PC.

2
  • The question was mostly about protocols where the NAT device doesn't know how to extract ports from (or where a port or request-ID doesn't exist at all).
    – user1686
    Aug 3 '16 at 10:44
  • 1
    Ahh yes, I've written a good answer for the slightly wrong question looking at your answer.
    – Lister
    Aug 3 '16 at 10:46
0

I'm adding an answer at this late stage as this question still is highly ranked on google, and there wasn't actually a detailed answer supplied.

For a supported protocol, like TCP and UDP, a NAT device will first map the addresses in the IP layer, then it'll map the ports (if required), and then really importantly, if the higher-level protocols have some kind of checksum or HMAC etc, it'll recalculate it (for example, the UDP checksum includes a virtual header with the source/destination address).

It'll also do the same for the body of ICMP responses. So if you send a UDP packet through a NAT device, and the final consumer bounces it with an ICMP response, the header from the failing UDP packet will be copied into the ICMP data block. The NAT device should spot this, and remap the addresses and ports back to the ones that the originator is expecting (typically no checksum to take care of, as it is just the header in the ICMP data).

For a protocol that the NAT device doesn't recognise, such as SCTP or UDPLITE, then it will map the addresses just fine, but because it doesn't understand the higher-level protocol, it won't know to recalculate the checksum or HMAC etc.

To verify this, if you run a packet sniffer like tcpdump on the receiving host, you will likely see the packets arriving with the right IP addresses, but the checksum will be wrong, and so they will be typically discarded by the OS and not passed on to the applications.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.