In contrast, HTTP or SMTP rely on the source address in the IP layer for the response that is returned. This creates a problem if the client initiating the session is using NAT. The NAT address will be placed in the application layer when the client initiates the session, and the receiver will attempt to use this NAT address as the destination IP address of the response.
But because NAT is not routable, the response will not arrive. Even though a NAT device is smart enough to substitute its own external, routable address in the IP layer of the packets that it transmits, this intelligence does not extend to substituting its address in the application layer.
The other problem NAT poses is that, by default, it's impossible to initiate any connectivity from the Internet to a device with a NAT address. Although this has some security benefits, it can create confusion. If the Web server in the above example had a NAT address,
a client on another network would have no way to direct a request to the server because it would be using a nonroutable IP address. One way to solve this problem is to configure the NAT device manually to send all requests on Port 80 to a particular device on the internal NAT network. The external IP address can then be published as the address of the Web server. But this approach requires a high level of expertise to configure. In addition, it doesn't scale well if a lot of devices are involved. This is a big problem with SIP phones on a NAT network--they won't be able to receive calls.
Fortunately, better solutions exist:
Discover the benefits of scalable backbone and network services for application and cloud providers.
Network automation is gaining momentum. Here's how you can drive this powerful technology to its full potential.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
