Suppose a host machine A in LAN has address like this 192.168.0.123
. It connects to the Internet through a default gateway 192.168.0.1
.
When A sends data to an external machine B, how does the gateway handle the IP packet?
When B's response reaches the gateway, how does the gateway locate A as the intended receiver?
Seems communication between A
and B
can only be initiated by A
. Because external machine doesn't know about A
hidden in the LAN.
Suppose there's another machine C
who sits in another LAN. A
and C
wants to communicate to each other. I guess the only way to do that is to have some public machine like B
to act as a middle-man. Maybe that's why all chat programs like OICQ have to log onto a server first, such as B
. And all chat messages are forwarded by that central server. And I think unless the A-B
or B-C
connection are persistent, the forwarding
can only be implemented as pulling
by A
or C
, rather than pushing
by B
, because only A
and C
can initiate request to B
.
Well - a short answer - through something called Network Address Translation
A slightly longish answer -
So here's what happens @ A - Route lookup to get Next Hop (default gw in this case). ARP resolution to find out MAC address of Default gateway) and then Network Address Translation @ Gateway - before packet goes out into wilderness.
Route Lookup -
Every well configured machine should have a local routing table - which would normally contain two routes. One is default route and another is called the subnet route. There can be more than these two routes, but definitely these two routes should help. the 'subnet route' helps in reaching the nodes on the subnet. and the 'default route' helps to reach anyone else. So eg. in your case there'd be two routes (0.0.0.0/32 gw = 192.168.0.1) the 'subnet route need not have gateway - in fact will not have gw). In this case since B's address is not on the subnet default route and gw corresponding to it will be used.
ARP resolution
A broadcast ARP request message is sent by A to ask for Gateway's MAC address - which it wants to use before forwarding the packet. Since Gateway knows it's own IP and MAC, it replies with it's own MAC address.
NATing -
So when a browser (say) on Node A wants to connect to a machine on Internet Node B (on a web server). It will send a TCP packet with following information - DIP = IP of B/ SIP = IP of A/ DP = 80/SP = 10000 (randomly chosen by A)/Proto = TCP.
Now when this packet arrives on Node B. Node B can forward this packet as it is - if it was simply working as a gateway - without NAT functionality. Technically that packet can go out and reach B, but there's no way for B's reply to reach back to 'A'. 'cos 192.168.X.X are private IP addresses - those packets routers are not supposed to forward them. So packets going out of A should have an IP address that can be reached by Host B. Gateway usually has a 'global' IP address. This address is used in all outbound packets. So packets on return path could reach to Gateway and subsequently to 'A'. So the IP address part is taken care of. The port part needs to be dealt with as well. Technically B could simply re-use the Source Port in outgoing IP packets, but imagine another node (say C) using a same port going to same server, so gateway would be clueless about whom to send packets to - on return path. So typically Gateway uses different outgoing ports and keeps a mapping between Inside IP-Port and outside IP-Port (technically that means Gateway can only reliably forward packets for 64 K connections). Normally this is not a problem, but for a large number of nodes on LAN with persistent TCP connections, this could be a problem. So typically multiple IP addresses are used - effectively multiplying the connections supported.
Hope that was not too long!