Socks5 proxy server
This means that the external server is only aware of the SOCKS Server (the proxy).
How is this different from NAT
SOCKS is a completely different way of solving the external access problem from NAT.
Consider the following diagram using a firewall for network address translation:
The internal system forwards a packet through the firewall. The packet is inspected by the firewall, and the source address is modified (in the header usually, and in the payload depending on the application), the external server receives the packet and replies.
Key factors to think of:
- the IP session initiation (three way handshake) is directly from the client to the server
- the firewall modifies the packet
- there is no authentication
- inspection of the packet / application / data is much more difficult
- no changes to the client operating system – it is transparent to the user.
Why SOCKS ?
SOCKS was originally developed by NEC before NAT was a possible solution. As such, it was often only way to access the Internet.
It has the following key features:
- provides authentication for protocols that cannot be authenticated
- by passes default routing in the internal network
Consider that protocols such as HTTP and Telnet support firewall authentication. Anyone who has configured Authenticated Proxy on a Cisco firewall will understand this. However, encrypted protocols can never be authenticated by firewall, only by a SOCKS Proxy.
However SOCKS can be a problem in real life :
- the client program must have a SOCKS client capability
- the client operating system must have SOCKS client capability (and ‘intercept’ specific network requests and divert to the SOCKS proxy)
- you must run and maintain a SOCKS server (which has been problem in the past)
The Blue Coat SOCKS server is easy to use, and using the same GUI to control and manage the rules.
There are only two version of SOCKS. The main differences between SOCKS V5 and SOCKS V4 are:
SOCKS V4 does not support authentication. SOCKS V5 supports a variety of authentication methods.
SOCKS V4 does not support UDP proxy. SOCKS V5 does.
There is no interoperability.
SOCKS V4 DNS lookups must resolve the external hosts. SOCKS5 clients can passing the un-resolvable host names to SOCKS servers and the servers will try to resolve those names.
Why choose SOCKS ? A little history lesson
Around 1999 / 2000 SOCKS was the pre-eminent secure remote access technology, especially for Unix system administrators. It effectively provided for secure SSH Gateways with logging and access control. There were a number of SOCKS clients in production (such as the free WinSOCK in Windows 95/98, and Hummingbird) but they were expensive and licensed on a per client basis. The worst part of the SOCKS was that MS Windows (of the time) had such a lousy TCP/IP stack that getting the clients to be reliable was almost impossible. This led to a poor reputation for SOCKS that it never really shook off.
IPSec / PPTP / L2TP were just beginning to penetrate the market. Most IT folks chose IPSec for remote access because it could applied universally and required no modifications to the client applications.