3. Changing the Configuration

In the previous section we described the initial configuration as generated by the configuration script during the first boot after the installation of Kernun UTM. In this section we will demonstrate how to modify the configuration. We will make the following changes:

First of all, we want to permit the HTTP traffic. As the transparent mode of the proxy is used, the clients connect directly to servers. Therefore, the clients must be able to resolve server addresses, which is why we need to enable DNS as well. The following steps produce a working configuration with the required changes.

  1. Start the GUI and connect to Kernun UTM, as described in Section 1.1, “Kernun GUI Launcher”. If Kernun UTM is running the unmodified initial configuration, you will see the GKAT window with only a few components running, as depicted in Figure 4.21, “The Kernun UTM running the initial configuration”.

  2. Select Configuration | Edit configuration of the firewall in the menu to open the configuration.

  3. In the left-hand part of the configuration window, look for a line containing hidden dns-proxy DNS. Select the line with the left mouse button, then click the right mouse button to open the context menu and select Hide/Unhide. The line will change to dns-proxy DNS.

  4. Repeat the same action for the line containing hidden http-proxy HTTP.

  5. Select the line acl INTOK and then select Add node next to this node | Section or Item from the context menu. In the Create Item/Section dialog, select acl as the type of the section and set the section's name, for example NET1_DENY. You have created a new global ACL.

  6. Now select the newly created ACL and use Add new node as last child | Section or Item from its context menu repeatedly to add the from, service, and deny items.

  7. Select the from item. In the right-hand part of the configuration window you can see the current value of the item, which is the empty set. Add a new value to the set by clicking on the button Append Value. Enter the address (with mask) of the subnet that is to be denied, for example, [].

  8. Select the service item. Using Append Value, add HTTP to the list.

  9. Now we have the new ACL denying access from a subnetwork ready. However, as the ACLs are checked in sequence and the first matching is used, we must exchange our two ACLs. This can be done in several ways. One possibility is to select acl NET1_DENY and click on Move Up in its context menu.

  10. Finally, we want to restrict the HTTP proxy to allow only the GET method. Open the http-proxy HTTP section by clicking on the small plus sign. Select the request-acl ALL2 line.

  11. Add a request-method { GET } item to this ACL in the same way as when you modified values in acl NET1_DENY.

  12. The configuration should now correspond to Figure 4.22, “The modified configuration”.

  13. Save, generate, and apply the configuration by selecting File | Commit the configuration to the firewall. The Commit configuration window is displayed, as depicted in Figure 3.17, “Configuration commit dialog”.

  14. Click Commit to enter a RCS log message with a description of the change you have made.

  15. The configuration is saved to Kernun UTM, recorded as a new version in the RCS file, the low-level configuration files are generated and applied (copied to the locations where Kernun UTM components will look for them).

  16. The Synchronize system with configuration window is displayed, as depicted in Figure 4.23, “Activation of the new configuration”. It informs you that components DNS and HTTP have been reconfigured and need to be started for the new configuration to take effect.

  17. Click OK in the synchronization dialog to finish the reconfiguration; Kernun UTM now contains running DNS and HTTP proxies, see Figure 4.24, “Reconfigured Kernun UTM is running”.

  18. Now you can switch to the Log page of the Proxies node in the GKAT window. If you start a Web browser on a machine in the internal network and try to access a Web server in the external network, you will see proxy log messages appearing.

Figure 4.21. The Kernun UTM running the initial configuration

The Kernun UTM running the initial configuration

Figure 4.22. The modified configuration

The modified configuration

Figure 4.23. Activation of the new configuration

Activation of the new configuration

Figure 4.24. Reconfigured Kernun UTM is running

Reconfigured Kernun UTM is running

3.1. Adding TCP Proxies

The process of adding new TCP proxies can be simplified even more using two wizards (for general information on wizards, see Section 1.4.6, “Configuration Wizards”). When creating a TCP proxy, you first need to decide whether you want to enable the connection of clients in the internal network to a server in the external network (the server must have a public IP address and the clients connect to this address), or whether you have a server in the internal network (with a private IP address) and clients from the external network will connect to Kernun UTM, which will forward them to the server. The Kernun GUI provides one wizard for each of the alternatives. The following subsections describe the creation of sample proxies in both cases.

3.1.1. TCP Proxy to Server in External Network

As we have said before, a proxy needs to be created in order to allow communication from the internal to the external network. The proxy should be transparent, which means that clients in the local network would not be aware of the fact that they do not connect directly to the server. The TCP proxy to external network wizard will lead you through the creation of the transparent TCP proxy. In this example, we will configure the transparent tcp-proxy to allow some privileged local clients to shop on www.ebay.com. First of all, you need to delete or hide the tcp-proxy HTTPS from the initial configuration, because it would collide with the proxy we want to create. Then select Insert | Configuration wizard | TCP proxy to external network to start the wizard.

On the first page, you are asked to choose the tcp-proxy section name, the interface to the network that contains the clients and the port of the service that is supposed to use the proxy. In our example, we choose the INT interface and the 443 port, as shown in Figure 4.25, “TCP proxy general network settings”.

Figure 4.25. TCP proxy general network settings

TCP proxy general network settings

On the second page, you define the clients in the internal network that are allowed to connect using this proxy and the servers in the external network, to which the clients may connect, in the form of either IP addresses or host names. If you already have an appropriate ACL created in the configuration, you may select the Use existing accepting ACL radio button and then choose the ACL to be used for this proxy. As we do not have any usable ACL in the system, however, we choose to create a new one, and set its name and the IP address of the privileged client that is allowed to log in to the ebay.com server. The configuration is depicted in Figure 4.26, “TCP proxy ACL settings”.

Figure 4.26. TCP proxy ACL settings

TCP proxy ACL settings

The third page contains more advanced connection settings, including several connection timeouts and a limit of the number of proxy children. If you do not fill in any of these fields, the corresponding item will not be included in the resulting configuration. Since we know that there will be no problems with the traffic load, we leave all the limits empty. In order to get more detailed traffic examination outputs, we choose to monitor the proxy (which i.a. produces graphs of the proxy usage, see Figure 3.8, “Graphs page”) and to generate proxy statistics (see Figure 5.26, “Statistics browser window”). The filled page is shown in Figure 4.27, “TCP proxy miscellaneous settings”.

Figure 4.27. TCP proxy miscellaneous settings

TCP proxy miscellaneous settings

Finally, the last page (Figure 4.28, “TCP proxy recapitulation”) shows the recapitulation of the wizard settings in the form of the text configuration that is to be added to the main system configuration. There is also the outcome of system verification of the configuration with the created proxy. You can click Finish to commit the proxy into the configuration, Back to return and modify the wizard settings, or Cancel to close the wizard and discard all the settings.

Figure 4.28. TCP proxy recapitulation

TCP proxy recapitulation

3.1.2. TCP Proxy to Server in Internal Network

Besides the above-mentioned wizard for a transparent proxy, the Kernun GUI also provides a wizard for a non-transparent tcp-proxy. In this case, clients connect to to a specified port at Kernun UTM, which forwards the communication to a server behind it. This is useful when creating servers without a public IP address in the internal network (which is a recommended practice). We will create an IMAP4S proxy that will allow employees at home connect to a mail server in the internal company network behind Kernun UTM and read their mail. The wizard is very similar to the Section 3.1.1, “TCP Proxy to Server in External Network” wizard; actually, only the second page differs.

On the first page, we choose the proxy name, the interface on which it is supposed to listen (this time, it is the external interface EXT) and the port for secure IMAP4, 993. On the second page, we similarly define the ACL, with a slight difference in the process of its creation. We only define restrictions concerning clients, as they always connect to Kernun UTM. After choosing the ACL, we need to specify where to plug the communication in (in our case the IP address of the IMAP4S server) and the port it listens on. This is specified in a single field as [] : 993. Furthermore, we want the server to receive packets with the original client's IP address (rather than that of Kernun UTM), so we check the Client source address check box. The second page is shown in Figure 4.29, “Non-transparent TCP proxy ACL settings”. The last two pages are the same as in the transparent proxy wizard.

Figure 4.29. Non-transparent TCP proxy ACL settings

Non-transparent TCP proxy ACL settings