This is something I have wondered for awhile and couldn't find answer of. Apologies for the stupid question, but here it goes:
If two computers have static IP's then they can easily send each other packets over TCP/IP.
If a computer is behind a firewall/router/another device that connects it to the internet the computer doesn't have an external IP address. Instead it has a LAN address, e.g. 192.168... If this computer wants to access a webpage, it knows the webserver's IP address, or uses DNS to obtain it. It sends a TCP/IP package, but how does the server then know what IP to send the answer to?
I imagine the following:
Request: A --[send to C, return to A]-> B --[send to C, return to B]-> C
Response: A <-[send to A, return to C]-- B <-[send to B, return to C]-- C
where A is the computer in question, B is the router it sits behind, and C is the target webserver. This doesn't seem realistic though, as B would have to memorize who to forward replies to for every packet it routed out. Which is probably a lot.
So my question 1 is: How does C reply to A?
In another scenario, computer A wants to send a packet to computer D both of which live in separate LAN networks. Is this possible without a central server E? I imagine something like this:
Request: A --[s.t. D, r.t. A]-> B --[s.t. D, r.t. B]-> C --[s.t. D, r.t. C]-> D
However, there is no way A could know the address of D, as D in fact does not have an external IP address. The only solution using a central server E is this:
A connects to E; has an id in E's system which is id_A
D connects to E; has an id in E's system which is id_D
A sends a message to D indirectly, by sending it to E and saying it is for id_D
E forwards the message to D, as it knows how to communicate with D
And even in this case, I don't quite get how can E send a message to D, if D didn't request it (as my model for PC <-> Server communication depends on the assumption that the PC requests and the Server responds; see question 1).
My question 2 is: Is it possible and how can two computers that only have LAN IP's communicate directly, if they are in different LAN's.
If you can point me to some beginners literature, that would be more than enough.
Thank you for your time.
Best Answer
First: What you describe is NAT, not firewalling. A firewall just filters what can go through, a NAT device changes addresses in packets.
You almost answer the first question yourself. Yes, a NAT device needs to keep track of every session going through it. Most communication on the internet uses TCP or UDP. Both of these protocols use port numbers. A session is defined by source address, source port number, destination address and destination port number. The NAT device needs to maintain a mapping between which numbers on the inside correspond to which numbers on the outside. And then it has to match every packet to an entry in its mapping table and adjust the packet accordingly.
This is also why NAT devices are less than optimal: a normal router is stateless. It doesn't need to keep track of what happened previously and it doesn't need to adjust the numbers and addresses in the packet. If a router fails another router can take over immediately. When a NAT device fails the device that takes over doesn't have the same mapping table and all sessions break and have to be re-established.
Your second question is more complex. One option is to configure port forwarding in one of the NAT devices. Then you let A send a packet to the forwarded port on C. B will change the source address and port to one of its own. When the packet arrives at C it then adjusts the destination address and port so the packet is forwarded to D. Reply packets do exactly the same in the opposite direction.
If there is no port forwarding then it gets more difficult. You need to have the assistance of an external server E. Both A and D have to initiate connections to E. Then E has to coordinate setting up the session between A and D. A and D both send outbound packets to trick B and C into adding entries to their mapping tables. Once those mappings are in place they can communicate directly.
To summarise: the way things usually work is that for outbound packets you have a device that performs source NAT. It changes the source address and port of the internal device to one of its own. For inbound packets you have a device that performs destination NAT. It changes the destination address and port to what is in its mapping table. The mapping table is filled either by manual configuration, by a protocol that lets internal systems request a mapping (didn't talk about those, look up UPNP and PCP) or automatically when the NAT device creates an entry for an outbound packet.