Why is nat required when proxy is enough?

Question

My machine is connected in a local lan. to connect to the internet the traffic goes through proxy server. my understanding of proxy server is that it sends the request on behalf of the original request sender. So when the server replies, it sends the reply to the proxy thinking that it is the client. The proxy then forwards the reply to my machine.
Take the case of Network Address translation. Your request goes through the nat router. The nat router then provides you a public ip address and stores this mapping in its table. The reply(from the server) is sent to this assigned public address. Which the nat router resolves to your local ip address from the table and forwards the reply to your machine.
My question why is nat required when proxy itself is able to mediate the traffic and provide you with access to the internet?

Solution 1

MadHatter has written an excellent layman's explanation of the differences between proxies and NAT.

For more technical details I suggest you read up on the OSI model and the TCP/IP model. Nat operates at later 3 of the OSI model (the network layer, IP in this case) and proxies generally operate at layer 7 (the Application layer, HTTP or whatever you're proxying).

NAT and proxies are also trying to solve slightly different problems. NAT is hiding a number of private IPs behind a smaller number of public IPs to alleviate the shortage of IP addresses, while proxies are creating a network "choke point" for security, auditing or performance reasons

Solution 2

It seems to me that you've grasped the fundamentals here quite well, and the short answer is, that if you're using a proxy with a public address, you don't need NAT - for the protocols which are mediated by the proxy.

However, there are more protocols in heaven and earth than are dreamt of in your philosophy; not all of them are proxiable, and proxies don't exist even for all that are, so NAT is a handy fallback for those.

Edit: A proxy is a computing device that works on an application level. An HTTP proxy receives HTTP requests for a remote site, and as you pointed out, it goes off to that site itself and makes the request, and passes the answer back to the requesting client. But it has to understand HTTP at a detailed level in order to do this.

Similarly, you might write an FTP proxy, but it would have to understand the details of MKD, DELE, LIST, and suchlike ftp protocol commands, in order to correctly proxy the client's requests. Any proxy that wants to work transparently generally has to intimately understand the internals of the protocol in order to proxy that protocol.

SOCKS is to some extent an exception to this rule, but that's because the SOCKS protocol puts in place a more general interface for proxying, requiring each client to be SOCKSified, and therefore capable of making the right requests of the SOCKS proxy in order to set up the kind of proxying each requires, which isn't exactly transparent.

Comments

[EEAA]

One clarification - the NAT router does not provide you a public IP address. It merely re-writes your packets as if they were coming from its own public IP instead of your client's IP. Then reply packets get sent back to the outside IP the NAT, which then re-writes the packets again with your client's IP and forwards the packet along.

[Joshua Drake]

Related: Why do we have NAT if we could just assign a public ip address.

[suraj]

What do you mean by "Protocols that are not proxiable"?

[Ashwin]

@MadHatter : What do you mean by not proxiable? Isn't it enough to have the proxies ip as the default gateway?

[Nobody moving away from SE]

To raise another aspect: For the non technical user the NAT should work out of the box (transparently) while the proxy has to be "installed" on the client side.

[EEAA]

@Nobody - not really. Transparent proxies are quite ubiquitous, and require zero configuration on the client.

[FooBee]

@Ashwin: The default gateway is used in routing and NAT, it is not a proxy. Some protocol are designed in a way that requires two machines to talk to each other directly. One easy method to reach this "goal" is to write a protocol that has an encrypted header or checksum containing the source address and let the receiver check if the source address encrypted in the header is the same address he got the package from. In case of a mismatch (which will happen when using NAT or a proxy), an error will be raised and the communication fails. Early variants of IPSec had this problem, IIRC.

[Nobody moving away from SE]

@ErikA: Well than thats more of a nat in my understanding.

[MadHatter]

Ashwin, see my edit above.

[Bruno]

Good answer, although FTP isn't necessarily a good example, since the NAT system also has to understand some of the commands to translate the addresses in the PORT commands.

[MadHatter]

Bruno, thank you for that; though that's exactly why I picked ftp, it being a great example a protocol where detailed protocol knowledge is required, in order to proxy that deeply annoying CONTROL/DATA pairing. I'm aware that NAT has become extra-bonus bright in some cases, to perform a similar function in NAT - but FTPS breaks that yet again.

[codeaviator]

I've always been told that NAT works in layers 3 & 4

[dwurf]

@codeaviator a fair comment - I defer to the experts at networkengineering.stackexchange.com :)