A well-known shortcoming of IP masquerading (and NAPT in general) is the inability of outside (Internet) hosts to initiate connections to internal hosts. For this same reason, IP masquerading is a suitable solution for client environments, such as a community of Windows PCs that needs to browse the Web and send Internet e-mail while receiving its e-mail from a POP3 server. For more information on Linux IP masquerading, go to
Network managers often find themselves in need of a higher degree of access control than that offered by a packet-filtering firewall. Its not always possible to track the IP addresses that should be granted network access, and Network-layer filtering leaves no room for user authentication and session logging. An Application-layer firewall system lets the security administrator specify which users are permitted to use a given network service (for example: HTTP, SMTP, POP3), regardless of the source address the request originated from.
The IETF has blessed the SOCKS protocol as the standard for proxying requests across Application-layer firewalls. When a SOCKS-aware Web browser attempts to establish a connection to an outside resource, the SOCKS server processes the request instead and proxies the connection on the clients behalf. SOCKS 5 (RFCs 1928, 1929, and 1961) supports strong user authentication, as well as the ability to proxy both TCP and UDP connections.
Aside from the ability to authenticate users, SOCKS firewalls come with a more subtle benefit: Because the proxy server originates all network requests on behalf of the clients, only one legal IP address needs to be deployed. While
this isnt technically NAT, this feature bodes well for security administrators, who prefer not to have internal addresses (even the legal ones) known to the Internet at large.