7. Networking in Proxies

In general, a proxy can listen in two modes: non-transparent and transparent. In the non-transparent mode, the client must be aware of Kernun UTM, as it is connecting explicitly to some of its IP addresses. For example, the proxy address and port must be entered in the preferences dialog of the Web browser. According to the configuration of the protocol and of Kernun UTM, the proxy typically connects to a server and mediates the communication.

In the transparent mode, on the other hand, Kernun UTM captures clients' connections and hands them over to the proxies. Although the client thinks to be connected directly to the server IP address, it is in fact communicating with the proxy. Hence, the client does not have to be configured for using the proxy. The proxy typically creates the connection on its own and mediates the communication. According to the configuration, the proxy can either connect to a server (the one the client was connecting to, or even to another one), or it can react otherwise, e.g. deny the connection.

7.1. Transparent Proxies

7.1.1. Transparency for Clients

Incoming transparency (i.e., proxy listening in the transparent mode) is configured by specifying the transparent item in the listen-on section in the proxy configuration.

Let us demonstrate the transparency aspects on the example of http-proxy. It is configured to listen in the transparent mode on port 80 and in the non-transparent mode on port 3128, as depicted in Figure 5.28, “HTTP Proxy listening both in transparent and non-transparent mode”.

Figure 5.28. HTTP Proxy listening both in transparent and non-transparent mode

HTTP Proxy listening both in transparent and non-transparent mode

When one proxy listens in both modes simultaneously, clients can choose whether to connect in the transparent mode (by connecting directly to the Web server to its port 80), or non-transparently (by connecting to the proxy to port 3128). Examples of Web browser configuration dialogs are shown in Figure 5.29, “Configuration of non-transparent mode in Firefox and Microsoft Internet Explorer Web browsers”.

Figure 5.29. Configuration of non-transparent mode in Firefox and Microsoft Internet Explorer Web browsers

Configuration of non-transparent mode in Firefox and Microsoft Internet Explorer Web browsers

After the configuration is applied to Kernun UTM and the proxy is restarted, it starts to listen on the two given sockets. This can be verified in the Network | sockstat tab of the GKAT window, as depicted in Figure 5.30, “Sockstat tab showing the list of all sockets ”. We can see sockets listening for connection in the transparent mode (rows marked 1) and in the non-transparent mode (rows marked 2). These sockets occur in the list more than once as they are shared by the parent process and all the child processes. The listening sockets show *:* in the ForeignAddr column. The non-transparent listening sockets show the IP address they listen on in the LocalAddr column. The transparent listening sockets show the special symbol >> in the LocalAddr column, preceded by the name of the interface, from which they accept connections.

In this example we can also see two clients to be actually connecting through the proxy, both to the Web server at 194.228.50.79. Client from IP 192.168.1.31 is connecting via the non-transparent proxy. We can see the connection from the client to Kernun UTM's internal IP address (row marked 3), and the connection from Kernun UTM's external IP address to the server (row marked 4).

Client from the IP address 192.168.1.12 is connecting transparently. We can see the connection from the client to the server, which was grabbed by Kernun UTM (row marked 5) and the connection from Kernun UTM to the server (row marked 6).

Figure 5.30. Sockstat tab showing the list of all sockets

Sockstat tab showing the list of all sockets

The realized connections can be traced in the log, as is shown in Figure 5.31, “Tracking transparent and non-transparent connections in the http-proxy log (the log was filtered, in order to save space). ”. We have filtered the log messages that inform about the session—see the filters box in the screenshot. The complete track of the session is more detailed, concerning matching of ACLs, requests, documents, etc. The selected message (HTTP-710-I) denotes the start of the session in http-proxy, and informs about the facts that are known at the time the session is being established (client address, server address and the transparency flag). The session end message (HTTP-711-I) would also provide other informations concerning the session (the number of requests, the length of the session, etc.).

Figure 5.31. Tracking transparent and non-transparent connections in the http-proxy log (the log was filtered, in order to save space).

Tracking transparent and non-transparent connections in the http-proxy log (the log was filtered, in order to save space).

7.1.2. Transparency for Servers

When a client is connecting to a server, the question is what IP address the server sees as the client IP address. Different approaches can be useful in different situations.

If a network with private addressing is hidden behind Kernun UTM, Kernun UTM must connect from its own (external, public) IP address. When the client network uses public IP addresses, both approaches can be desired: either the internal addressing should be hidden (the traffic should be formally realized from Kernun UTM's IP address), or not. On the other hand, a server protected in a DMZ may need to know the IP address of the real client.

By default, Kernun UTM proxy connects to the server from Kernun UTM's IP address (i.e. hiding the client's real IP address). However, there are two other options, which can be specified in the first-layer ACL (see Section 2.5, “Application Proxies and ACLs” for details on ACLs):

  • source-address client denotes that the IP address of the real client should be used as the source address;

  • source-address force address denotes that the given address should be faked as the source address for the connection to the server.

The source-address item can be either specified on the system level of the configuration, in which case it influences all the proxies that reference the ACL, or in the session-acl section of the particular proxy. In Figure 5.32, “Transparency for servers (source-address client) ”, the real client address is configured to be used as the source address for all the named proxies, because it is specified in the system ACL.

Figure 5.32. Transparency for servers (source-address client)

Transparency for servers (source-address client)

7.2. A Proxy and a Server on the Same Port

In Kernun UTM, a single port can be shared by several proxies or servers, provided that they do not collide in their listen sockets. For example, it is desirable to provide a transparent SSH proxy for connecting to SSH servers in the Internet and, at the same time, to provide an SSH server for administration of Kernun UTM. Both should be available from the protected network.

An example of such configuration is shown in Figure 5.33, “A port shared by two applications ”. When a packet arrives, Kernun UTM kernel delivers it to the most specific socket that is suitable for it. Consult transparency(7) for more information, including the definition of conflicting sockets and the socket preference. This way, it is possible to provide services on their traditional ports as well as transparent proxies on the same ports.

Figure 5.33. A port shared by two applications

A port shared by two applications

7.3. Listening on a port range

Kernun UTM proxy can be configured to listen on a set of contiguous ports. This ability is also known as listening on a port range and is available for TCP and UDP-based proxies. If a transparent proxy listens on a port range (and ACLs do not specify otherwise), the proxy connects to the port the client was connecting to. If a non-transparent proxy listens on a port range, the situation is similar to the regular non-transparent proxy (one that listens on a single port): the port (as well as the server IP address) would be either provided in some ACL in the Kernun UTM configuration (for example, in the plug-to item), or it is a part of the application protocol. An example of sip-proxy configured to listen on a port range is shown in the Figure 5.34, “The sip-proxy configured to listen transparently on a port range 5060-5062 ”.

Figure 5.34. The sip-proxy configured to listen transparently on a port range 5060-5062

The sip-proxy configured to listen transparently on a port range 5060-5062


Warning

Proxies cannot listen on ranges of ports that collide with the system default port ranges. The system normally assigns ports to connections with unspecified source port from three port ranges, which can be modified by the portrange-default, portrange-high, portrange-low items in the system.sysctl section. None of those ranges may overlap with the range of ports that a proxy is listening on. In the case of a port range collision, the system would not know, which ports are free to use and which are occupied.

Note that this problem does not occur when the proxy listens on separate ports. In this case, the single ports are reserved for the use of the proxy (even if they are inside one of the system port ranges).