Client SOCKS support

iSeries™ uses SOCKS version 4 to enable programs that use the AF_INET address family with SOCK_STREAM socket type to communicate with server programs that run on systems outside a firewall.

A firewall is a very secure host that a network administrator places between a secure internal network and a less secure external network. Typically such a network configuration does not allow communications that originate from the secure host to be routed on the less secure network, and vice versa. Proxy servers that exist on the firewall help manage required access between secure hosts and less secure networks.

Applications that run on hosts in a secure internal network must send their requests to firewall proxy servers to navigate the firewall. The proxy servers can then forward these requests to the real server on the less secure network and relay the reply back to the applications on the originating host. A common example of a proxy server is an HTTP proxy server. Proxy servers perform a number of tasks for HTTP clients: HTTP proxy servers handle only HTTP clients.

A common alternative to running multiple proxy servers on a firewall is to run a more robust proxy server known as a SOCKS server. A SOCKS server can act as a proxy for any TCP client connection that is established using the sockets API. The key advantage to iSeries Client SOCKS support is that it enables client applications to access a SOCKS server transparently without changing any client code.

The following figure shows a common firewall arrangement with an HTTP proxy, a telnet proxy, and a SOCKS proxy on the firewall. Notice that the two separate TCP connections used for the secure client that is accessing a server on the internet. One connection leads from the secure host to the SOCKS server, and the other leads from the less secure network to the SOCKS server.


Common firewall arrangement

Two actions are required on the secure client host to use a SOCKS server:

  1. Configuration of a SOCKS server. On February 15, 2000, IBM® announced that the IBM Firewall for iSeries product (5769-FW1), which provides SOCKS server support, is not enhanced beyond its current V4R4 capability.
  2. On the secure client system, define all outbound Client TCP connections that are to be directed to the SOCKS server on the Client system. You can define the secure client SOCKS configuration entries by using the SOCKS tab found under the iSeries Navigator function of iSeries Access 95 or Microsoft® Windows NT®. The SOCKS tab has substantial help on configuring the secure client system for Client SOCKS support.

    To configure client SOCKS support, follow these steps:

    1. In iSeries Navigator, expand your iSeries server > Network > TCP/IP Configuration.
    2. Right-click TCP/IP Configuration.
    3. Click Properties.
    4. Click the SOCKS tab.
    5. Enter your connection information about the SOCKS page.
    Note: The secure client SOCKS configuration data is saved in the file QASOSCFG in library QUSRSYS on the secure client host system.

When configured, the system automatically directs certain outbound connections to the SOCKS server you specified on the SOCKS page. You do not need to make any changes to the secure client application. When it receives the request, the SOCKS server establishes a separate external TCP/IP connection to the server in the less secure network. The SOCKS server then relays data between the internal and external TCP/IP connections.

Note: The remote host on the less secure network connects directly to the SOCKS server. It does not have direct access to the secure client.

Up to this point, outbound TCP connections that originate from the secure client have been addressed. Client SOCKS support also lets you tell the SOCKS server to allow an inbound connection request across a firewall. An Rbind() call from the secure client system allows this communication. For Rbind() to operate, the secure client must have previously issued a connect() call and the call must have resulted in an outbound connection over the SOCKS server. The Rbind() inbound connection must be from the same IP address that was addressed by the outbound connection that the connect() established.

The following figure shows a detailed overview of how sockets functions interact with a SOCKS server transparent to the application. In the example, the FTP client calls the Rbind() function instead of a bind() function, because the FTP protocol allows the FTP server to establish a data connection when there is a request from the FTP client to send files or data. It makes this call by recompiling the FTP client code with the __Rbind preprocessor #define, which defines bind() to be Rbind(). Alternatively, an application can explicitly code Rbind() in the pertinent source code. If an application does not require inbound connections across a SOCKS server, Rbind() should not be used.


Interaction of sockets functions with a SOCKS server
Notes:
  1. FTP client initiates an outbound TCP connection to a less secure network through a SOCKS server. The destination address that the FTP client specifies on the connect() is the IP address and port of the FTP server located on the less secure network. The secure host system is configured through the SOCKS page to direct this connection through the SOCKS server. When configured, the system automatically directs the connection to the SOCKS server that was specified through the SOCKS page.
  2. A socket is opened and Rbind() is called to establish an inbound TCP connection. When established, this inbound connection is from the same destination-outbound IP address that was specified above. You must pair outbound and inbound connections over the SOCKS server for a particular thread. In other words, all Rbind() inbound connections should immediately follow the outbound connection over the SOCKS server. You cannot attempt to intervene non-SOCKS connections relating to this thread before the Rbind() runs.
  3. getsockname() returns the SOCKS server address. The socket logically binds to the SOCKS server IP address coupled with a port that is selected through the SOCKS server. In this example, the address is sent through the "control connection" Socket CTLed to the FTP server that is located on the less secure network. This is the address to which the FTP server connects. The FTP server connects to the SOCKS server and not directly to the secure host.
  4. The SOCKS server establishes a data connection with the FTP client and relays data between the FTP client and the FTP server. Many SOCKS servers allow a fixed length of time for the server to connect to the Secure client. If the server does not connect within this time, errno ECONNABORTED is encountered on the accept().
Related information
bind()
connect()
accept()
getsockname()
Rbind()