Cool Solutions

Using Remote Control without Punching Holes in the NAT Firewall



June 27, 2008 11:43 am





By Ranganath Dhanasekaran and Sambit Kumar Dash

You are unable to remote control through NAT without having to punch firewall holes. This is due to the fact that the NAT firewall hides the internal IP addresses from an external network and thus blocks all the Remote Management connections arriving on port 5950.

If you do not want to open any ports to the external network, only the NAT router address is visible. Hence, to punch a hole in the NAT firewall will mean to open a port in the firewall for every internal device that needs to be managed by remote control.

For example, if you want to manage two machines with IP addresses and from an external network, you will not be able to do so as you will have no access to those IP addresses since they are behind a NAT firewall.

The NAT firewall can see both the internal and external sides of the network. For example, a NAT firewall may have an internal IP address of and external IP address of Since the external IP address will be visible from, you will need to open two ports — say 5961 and 5962 on the NAT router. Then you must configure the NAT router such that if any incoming request arrives at it will be forwarded to and if a request arrives at it will be forwarded to

This process of mapping internal and external addresses is cumbersome. For a large number of machines in the internal network, creating and managing the routing scripts may be rather complex. The other issue, of course, is to remember the mapping between the router port numbers and internal IP addresses to initiate a remote control session.


We suggest the use of a SOCKS proxy and SOCKS server to avoid the complexities of configuring a NAT firewall. Before we get to the details of the solution, let’s try to understand the basic principles of NAT and SOCKS.


NAT (Network Address Translation or Network Address Translator) is the translation of an Internet Protocol address (IP address) used within one network to a different IP address known within another network. One network is designated the inside network and the other is the outside. Typically, a company maps its local inside network addresses to one or more global outside IP addresses and un-maps the global IP addresses on incoming packets back into local IP addresses. The shortage of IP addresses is one prime reason to use NAT.

Additionally, NAT helps ensure security since each outgoing or incoming request must go through a translation process that also offers the opportunity to qualify or authenticate the request or match it to a previous request.


Note: Unregistered IP addresses are the IP addresses those are used in the inside network and are not visible/ accessible from the outside network. Registered IP addresses are addresses used in the outside network.

There are different NAT configurations. Two of them are described below:

  • Static NAT: In this configuration, each unregistered IP-address is mapped to a registered IP-address on a one-to-one basis.
  • Dynamic NAT: In this configuration, each unregistered IP address is mapped to a registered IP address from a group of registered IP addresses.

Configuring the above mappings to provide access to the machines on the inside network is also called as punching the hole on the NAT.


SOCKS protocol provides a framework for client-server applications in both the TCP and UDP domains to conveniently and securely use the services of a network firewall. The protocol is conceptually a “shim-layer” between the application layer and the transport layer, but does not provide network layer gateway services, such as forwarding of ICMP messages.

The use of network firewalls, systems that effectively isolate an organization’s internal network structure from an exterior network such as the Internet, is becoming increasingly popular. These firewall systems typically act as application-layer gateways between networks, usually offering controlled TELNET, FTP, and SMTP access. SOCKS provides a general framework for these protocols to traverse securely and conveniently over a firewall.

SOCKS version 5 provides strong authentication of such traversal, while SOCKS Version 4 provides only unsecured firewall traversal for TCP-based client-server applications, including TELNET, FTP, and protocols such as HTTP, WAIS and GOPHER.


As seen from the description of NAT above, if a host A on outside network needs to remote control a machine at host B, holes need to be punched on the NAT. Likewise for every host that needs to be remote controlled from the outside network, holes need to be punched on the NAT. This is definitely cumbersome. Hence, an alternate solution using SOCKS Proxy is described below.

Single NAT Network Architecture


The above figure shows the architecture of a single NAT network.

  1. Host A has a SOCKS client running which can encapsulate the TCP packets with the relevant SOCKS header.
  2. The SOCKS client is configured to contact the SOCKS server.
  3. When the Remote Management viewer is launched to connect with Host B, it requests with Host B’s IP address and port. Since the SOCKS client is configured to encapsulate the request with SOCKS header, it will encapsulate the TCP packet and pass it on to the SOCKS server that is inside the internal network.
  4. The NAT intercepts the SOCKS packet, does the address translation, and forwards the SOCKS packet to the SOCKS server on the inside network.
  5. The SOCKS Server understands the SOCKS header and passes on the TCP connection to the intended recipient (Host B).

Double NAT Network Architecture


The above figure shows the double NAT architecture. The SOCKS proxy servers have to be set up in a chain to facilitate TCP connections for the remote viewer. In this configuration:

  1. Each network will have a SOCKS proxy server.
  2. For any connection going to an external network, the SOCKS client on the host machine will forward the request to the SOCKS proxy server in the same network.
  3. Depending on the IP address, and the range requested, the SOCKS proxy can be configured to forward the request to the SOCKS proxy server of the other network. In the case of Host A trying to connect to Host B, the SOCKS Proxy Server in LAN 1 should be configured to forward the request to the SOCKS proxy server of LAN 2. Similarly, the SOCKS proxy server on LAN 2 should be configured to forward requests back to the SOCKS proxy server on LAN 1 for bi-directional communication.
  4. Moreover the NAT routers should be configured in each network to allow seamless traffic exchange between the SOCKS proxy servers in the network.


1 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 5 (1 votes, average: 5.00 out of 5)
You need to be a registered member to rate this post.

Categories: Uncategorized


Disclaimer: This content is not supported by Micro Focus. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

1 Comment

  1. By:dsambit

    ZENworks 10 SP2 onwards has support for a Remote Management Proxy. Hence, generic SOCKS proxy configuration for the same purpose is no more needed. Please refer to documentation of ZENworks at: