Journey Of IP Packet Demystified

I sit in a private LAN connected to the Internet through a router. Because our network shares a single public IP address, we use NAT.

So when I request the page superuser.com that will generate many IP packets. Let's look at a single one.

A Packet Is Wrapped and Sent

IP Packet
Source: 172.31.46.50 (my IP)
Destination: 64.34.119.12 (superuser.com)

Now, my system is most likely set up similar to the one in question. I have my own IP address (172.31.46.50), a subnet mask (255.255.255.0) and a default gateway (172.31.46.1). Now, because my Destination field in my IP packet points to a network different than my own, it is sent to my default gateway (rather than to the computer directly).

But how can the packet get to the default gateway, if the Destination points somewhere completely else?

That's easy, because the we use the addressing of the Ethernet protocol for that. We just set our destination IP address in the IP packet and the MAC address of our default gateway as the destination in the Ethernet Frame.

Now that will make sure our default gateway gets the packet for superuser.com. Yay!

Now the gateway has our packet and could send it right on its path. But to make sure it will get the answer, it first need to replace the packet Source address (otherwise superuser.com would try to send the answer to some (possibly) non-existent device on their network. Now that wouldn't be very nice.)
So my router will place its public IP address in the Source field:

IP Packet
Source: 115.248.20.13  (my public IP)
Destination: 64.34.119.12 (superuser.com)

Now that same game goes on and on with all the routers on the world until the packet finally arrives atsuperuser.com and an answer is generated.

Answer IP Packet
Source: 64.34.119.12 (superuser.com)
Destination: 115.248.20.13  (my public IP)

Ok, the answer got to my router, now what? How does my router now know to send the answer to172.31.46.50?

Well, that actually works because we have only looked at the IP and Ethernet parts of the communication. What makes this work is the TCP part.

You most likely know that web servers usually run on port 80. IP has no notion of ports. That comes from TCP. In TCP we have (like in IP) a source and destination port.

My TCP Packet to superuser.com
Source: 172.31.46.50 (my IP)
Source Port: 11111 (the port my computer made up)
Destination: 64.34.119.12 (superuser.com)
Destination Port: 80

Now your router uses that to manage the whole thing.

When he sends that initial package (that's addressed to superuser.com on port 80), he will put a new source port in there (like 12345).
And this is the important part! He will remember that replacement!

My router's TCP Packet to superuser.com
Source: 115.248.20.13  (my public IP)
Source Port: 12345 (the port my router made up)
Destination: 64.34.119.12 (superuser.com)
Destination Port: 80

So the answer packet received by the router actually looks like this:
Answer TCP Packet from superuser.com
Source: 64.34.119.12 (superuser.com)
Source Port: 80
Destination: 115.248.20.13  (my public IP)
Destination Port: 12345 (the port my router made up)

So now he gets that package and sees that it is for a port it previously remembered was assigned to NAT operations for IP address 172.31.46.50 (my IP address).

A Packet Is Unwrapped and Examined

Answer TCP Packet from my router
Source: 64.34.119.12 (superuser.com)
Source Port: 80
Destination: 172.31.46.50 (my IP)
Destination Port: 11111 (the port my computer made up)

So it sends me the answer.
Pretty Cool huh .