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.
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”.
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
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 
) and
in the non-transparent mode (rows marked
).
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 
), and the connection from
Kernun UTM's external IP address to the server (row marked
).
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
)
and the connection from Kernun UTM to the server
(row marked
).
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).
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 clientdenotes that the IP address of the real client should be used as the source address;source-address forcedenotes that the givenaddressaddressshould 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.
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.
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
”.
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).