How does NAT work for non-standard or uncommon protocols (or raw up)

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?

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).

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.