The IP address is not the only thing that the remote server sees. It also sees a port. The port is a 16-bit integer.
Think of a computer as an apartment building. The IP is like the street address. The port identifies which apartment. Thus, a browser, a mail client, and so on, all run on the one IP belonging to the computer but each is given, by the OS, one or more unique ports to use.
When a local computer sends a packet to a remote server, the packet is sent from a port on the local computer to a port on the remote server. The firewall receives that packet and sends it on to the remote server but it does so only after changing the from IP address to local network's public IP and also likely changing the from port to some other port of the firewall's choosing.
When the public server responds, it sends a packet back to the the public IP and the port number that it was given. The firewall receives that packet and sends it on to whichever computer initiated the connection on that port.
If the firewall receives a packet directed to a port that no local computer was using, it is the firewall's job to keep that packet out of the local network. It can silently drop it or it can noisily send a reject message back to the source.
Some common port numbers
When your browser sends a request to some remote server, that request very likely goes to the remote server's port 80.
- 22 = ssh
- 25 = smtp (mail)
- 53 = DNS (domain name server)
- 80 = http
- 194 = IRC
- 220 = IMAP
- 993 = POP (mail)
Typically, low number ports, up to 1024, are reserved for use by the operating system. High numbered ports, maybe 32000 to 65535, are used by user applications, like browsers.
1That is what NAT does. TCP is a connection orriented protocol, so when you on the inside negotiate a connection to an external server, the firewall remembers that you started the connection. returning packets will have the right port number, and SYN, and ACK values for that specific connection within them, so the router knows that the packet is part the connection it observed previously, and pass the packet into the LAN and to the host that started the connection. as you said, the external server only knows the connection, including your public IP, port number and SYN/ACK values. – Frank Thomas – 2015-02-20T04:55:04.003
thanks, so the local firewall remembers your connection and waits for packets containing the correct SYN/ACK values. I understood SYN/ACK occurred on the "three way handshake". once the handshake has occurred, do these SYN/ACK values continue to exist within all packets? – Michael Coleman – 2015-02-20T05:11:12.227
yes, and they change (predictably) with each packet, so that TCP can tell whether or not its gotten all the packets, or if its missed a few and needs to ask for a resend of a particular one. be careful not to confuse syn/ack values with syn/ack flags. the flags are turned on or off during the handshake, but the values start at a random value and increase from there with each packet successfully sent. Note that these values are predictable only within the connection. if someone on the outside was observing and syn vals were too easy to predict, they could hijack the connection. – Frank Thomas – 2015-02-20T05:14:48.693
see here: https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure Note that not only are there syn/ack flag bits in the 110th and 111th bits, there are also 32-bit fields for holding the syn and ack values. On the very first packet, ACK is off, and there is no value, but every other packet will have one, and they increment with every reply.
– Frank Thomas – 2015-02-20T05:18:19.230