In this page you find:
This section allows to set up rules that specify if and how the network traffic flows through the Endian UTM Appliance. The firewall on the Endian UTM Appliance is divided in different modules, each monitoring and allowing or blocking one specific type of traffic. The modules available are the following:
Within each of the sub-menus, in which all the corresponding existing rules are listed, any customised rules can be added, for any type of service or every port/protocol. The various parts of which the firewall is composed refer to different types of traffic (e.g., OpenVPN governs the traffic from/to the VPN users, inter-zone traffic the one flowing from zone to zone) and are designed to avoid any overlapping or even contrasting rules. In other words, there is no way to write two rules in two different firewall modules whose combined effect causes an unwanted block or access of packets.
The choice to separate the networks controlled by the Endian UTM Appliance allows also for an easier management of the firewall, whose configuration may become very complex. Indeed, each of the modules can be considered as an independent firewall, and their combined effect covers all possible packet flows through the Endian UTM Appliance.
Additionally, for any of the modules listed above, one or more rule may exist, that can neither be disabled nor removed. These are the so-called Rules of system services (or System rules) whose purpose is to allow the correct interoperability of the services running on the Endian UTM Appliance with the Endian Network infrastructure.
The rules that are defined here will be transformed into iptables commands, the standard Linux firewall tool since the 2.4 kernel, and therefore organised into tables, chains, and rules. For a more in-depth description of the various elements that compose a firewall rule, or even to learn how to fine-tune and to manage a complex firewall, it is suggested to read either the iptables(8) manual page on any Linux box, or some of the countless online resources or tutorials available on the Internet.
When adding a rule, most of the values to configure in the various modules are of the same type (e.g., the source or destination interfaces), since in the end they are all setup with iptables. Therefore, in order to keep this section short and readable, all the configuration items that are common to all modules of the firewall are grouped here and defined only once. There will be some more explanation only in case of significant differences with the descriptions given here.
Source or Incoming IP. Usually in the form of a drop-down menu, this setting is the type of the source or incoming connection that should be matched. Depending on the type chosen, the selection of different connections from the small box underneath the menu will be possible: Zone/VPN/Uplink is either the source zone, VPN client, or uplink to which this rule should be applied, Network/IP/Range the IP address or range or the network addresses, OpenVPN User and L2TP User the OpenVPN or 2TP users, respectively.
Destination or Target. Also this setting comes in the form of a drop-down menu and allows the choice among three types of destination that should be matched, which are the same as in the Source drop-down menu: A Zone/VPN/Uplink, Network/IP, OpenVPN User or L2TP user, except for some small change (e.g., for some type of rules, the target can not be an OpenVPN or L2TP user).
Service, Port, and Protocol. A service is usually defined as a combination of a port and a protocol. For example, the SSH service runs by default on port 22 and uses the TCP protocol. These three options control the port and protocol to which to apply the rule and consist of two drop-down menus, from which to choose either a pre-defined Service, that will also set the protocol and the port range in the text area, or one Protocol and optionally a port or a port range. Available protocols are: TCP and UDP - the most used, GRE - used by tunnels, ESP - used by IPsec, and ICMP - used by the ping and traceroute commands.
Note
There exist dozens predefined services that can be chosen from the drop down menus and should suffice to allow the most common services to access the Internet. An user defined combination of port and protocol should be used only if a service is not running on a standard port (e.g., an SSH server listens to port 2345 or a web server runs on port 7981) or if a service is using a particular port (e.g., a multiplayer game on the Internet).
‘Access from’ sub-rule. Almost every rule can be further detailed by adding several Access from rules to it, for example to limit access to a client depending on the zone from which it connects to the Endian UTM Appliance. Access from rules can be configured when the advanced mode is selected (see below). As a consequence, a rule can appear split on two or more lines, depending on the number of access policies defined. Each access from sub-rule can be deleted individually, without changing the main rule. Each of the sub-rules can even have a different filter policy.
Policy, Filter Policy. The action to carry out on the packets that match the current rule. The drop-down menu allows to select among four options: Allow with IPS -let the packet pass but analyse it with the Intrusion Prevention System, Allow - let the packets pass without any check, Drop - discard the packet, and Reject - discard the packet and send an error packet in response.
Enabled. Every rule created is by default enabled, but it can be saved and not activated by unticking the checkbox, i.e., it will not be taken into account for packet filtering. Disabling a rule may prove useful for troubleshooting connections’ problems.
Log, Log all accepted packets. By default, no log entries is written when traffic is filtered. To enable logging for a rule, tick the box.
Warning
If there is a lot of traffic and packets to be analysed, the size of the log files will likely grow rapidly, so in this case remember to check the log directory regularly to avoid running out of space!
Remark. A description or a remark about the rule, to remember the purpose of the rule.
Position. Recall that the iptables rules are processed in the order they appear on the list and that some is a “terminating” rule, i.e., it may drop or reject a packet and stop the processing of the subsequent rules. This drop-down menu allows to choose in which position this rule should be saved.
Actions. On all rules several actions can be carried out:
- move the rule upwards or downwards in the
list.
Hint
Remember that the ordering matters! The firewall rules are processed in the order they appear in the page, top to bottom.
- enable or disable the rule.
- modify the rule.
- remove the rule.
Finally, after every change has been saved in the firewall rules, the firewall should be restarted to reload the configuration. A callout with a clickable Apply button will appear to recall this necessity.
The Port forwarding / NAT module is composed by three tabs: Port forwarding / DNAT, Source NAT, and Incoming routed traffic. Its purpose is to manage all the traffic that flows through the uplink, from the RED zone to the Endian UTM Appliance and the NAT-ed traffic, both incoming and outgoing.
Destination NAT is usually employed to limit network accesses from an untrusted network or to redirect the traffic coming from the untrusted network and directed to a given port or address-port combination. It is possible to define which port on which interface should be forwarded to which host and port.
The list of the configured rules shows several information: The ID (#) showing the order in which the rules are matched against the traffic, the Incoming IP address, the service (i.e., port and protocol) to which the traffic is directed, the Policy applied to the traffic, the Translate to address (i.e., the host and port where to redirect the traffic), a custom Remark, and the available Actions.
When editing a rule, the same form open as when adding a new rule, by clicking on the Add a new Port forwarding / Destination NAT rule. A link on the top right of the form allows to chose between a Simple mode or an Advanced mode. The latter mode allows also to fine-tune the Access from, the policy, and the type of Translate to.
Besides the common options, these other settings can be configured:
This part of the form changes depending on the current active editing mode, simple or advanced. If the mode is set to advanced, besides adding Access from sub-rules, there is an additional Type drop-down menu that allows to chose among different types of translations.
The first one is IP and corresponds to the only one available in simple mode. Here should be written the destination IP address (besides port and NAT), the port or port range to forward to and if to apply NAT or not to the incoming packets.
OpenVPN User: choose one OpenVPN user as the destination target for the traffic.
Load Balancing: specify a range of IP addresses to which traffic will be split, to avoid bottlenecks or the overloading of a single IP.
Map the network. Insert a sub-network to which translate the incoming traffic.
Note
The Map network translation statically maps a whole network of addresses onto another network of addresses. This can be useful for companies whose subsidiaries all use the same internal network. Indeed, in this case all these networks can be connected to each other through network mapping.
An example would be:
original network 1: 192.168.0.0/24
mapped network 1: 192.168.1.0/24
original network 2: 192.168.0.0/24
mapped network 2: 192.168.2.0/24
L2TP User: choose one L2TP user as the destination target for the traffic.
Except when selecting the Map the network option, it is always possible to define the port or port range to which the traffic should be sent to, and if to apply NAT on the traffic or not. If Do not NAT is chosen, it is not allowed to define a Filter policy under the Access From (advanced mode).
Warning
When selecting IP, OpenVPN User, L2TP User or Load balancing, keep in mind that port ranges will not be mapped 1 to 1, but rather a round robin balancing is performed. For example, mapping incoming ports 137:139 to destination ports 137:139 will result in these ports being used randomly: The incoming traffic to port 138 can unpredictably be redirect to either 137, 138, or 139. Leave the translation Port/Range field empty to avoid such occurrences!
Troubleshooting port-forwarding.
There are mainly two reasons why port-forwarding may not work.
The Endian UTM Appliance is behind a NAT device.
In this case there is a device like a router or like another firewall between the Endian UTM Appliance and the Internet, which disallows direct incoming connections. The solution is to configure a port forwarding also on that device to the RED IP of the Endian UTM Appliance, if this is possible.
The destination server has wrong default gateway.
The server set as the destination of a port-forwarding rule is configured with a wrong or no default gateway. Connections will be directed to the target IP address but due to a wrong default gateway, packets will not be directed through the Endian UTM Appliance. The solution is to correct the server’s gateway.
In this page can be defined rules that apply SNAT to outgoing connections. The list of already defined rules is also displayed, for each of which the source and destination IP addresses, the service, the NAT status, a custom description of the rule, and the available actions are shown.
Source NAT can be useful if a server behind the Endian UTM Appliance has an own external IP and the outgoing packets should therefore not use the RED IP address of the firewall, but the one of the server. To add a new rule, click on Add a new source NAT rule and proceed like in the case of adding a port forwarding rule. Besides the common options, only one other setting can be configured:
SNAT and a SMTP server in the orange zone.
In certain cases it is preferable to explicitly declare that no Source NAT be performed. An example would be a SMTP server in the DMZ, configured with an external IP, but whose outgoing connections should have the REDIP as the source. Configuring an SMTP server running on the IP 123.123.123.123 (assuming that 123.123.123.123 is an additional IP address of the uplink) in the DMZ with Source NAT can be done as follows:
See also
Tutorials to define DNAT (Basic Setup), DNAT (Advanced Setup), and SNAT (Basic Setup) rules.
This tab allows to redirect traffic that has been routed through the Endian UTM Appliance. This is very useful when having more than one external IP addresses and some of them should be used in the DMZ without the necessity to use NAT. The fields shown for every rule in the list are the traffic source and destination, the service, the policy to apply, a remark, and the available actions.
No other setting can be configured besides the common options.
New in version 3.0: Application Firewall (Application Control)
The Endian UTM Appliance comes with a pre-configured set of rules for outgoing traffic, i.e., to allow traffic flow of specific services, ports, and applications from the various zones to the RED interface and therefore the Internet. These rules are needed to ensure that the most common services always be able to access the Internet and work correctly. Two boxes are present on this page, one that shows the current rules and allows to add new ones, and one that allows to set the outgoing firewall options.
Note
Rules defined in the outgoing firewall are disregarded when the Endian UTM Appliance is in no uplink mode. When operating in Stealth uplink mode, only part of the traffic from the zone behind the Endian UTM Appliance to the outside is considered as outgoing, see the description of the stealth uplink.
Endian UTM Appliance and Application Firewall (Application Control).
Application firewalls are a recent development and improvement to stateful firewalls, that combine the ability of the latter to keep track of the connection’s origin and path with those of Intrusion Prevention Systems to inspect packets’ content, with the purpose to provide higher security from worm, viruses, malware, and all types of threats. The final result from the user experience point-of-view is that firewalls can block not only traffic between ports and IP addresses, but also traffic generated by single applications. This requires however, more efforts from the firewall: While traffic between IP addresses only needs that the first packet be inspected to block or allow the whole flow, to correctly recognise traffic generated by application, it is sometimes necessary the analysis of a few packets -usually not more than 3- of the flow.
Starting with version 3.2, every Endian UTM Appliance is equipped with nDPI, an open source library implementing Deep Packet Inspection, thus allowing the deployment of rules for application firewalling. nDPI is deployed as a kernel module and interacts with iptables for the packet analysis.
Hence, there are now two different types of rules that can be defined on the outgoing firewall:
When no application rules have been defined, the behaviour of the firewall is exactly the same as in previous version. Whenever an application rule has been defined, however, the steteful rules preceding it behave normally, while all the rules after undergo nDPI.
It is worth noting that the use of nDPI might present some subtleties, illustrated by the following example, and therefore might produce some unwanted side effect.
Suppose that a company wants to allow all HTTP traffic, except for youtube and gmail. The first default rule defined in Endian UTM Appliance is to allow all HTTP traffic, with no restriction. This rule must therefore be disabled as first step. Then, two rules must be defined:
If rule 2. were an application rule with protocol HTTP, then only traffic recognised as HTTP by nDPI would be allowed, but other protocols using HTTP, like e.g., Yahoo and FaceBook would pass, since nDPI does not consider them as being HTTP, but indipendent protocols.
In detail, these are the services and protocols allowed by default to access the REDIP from the zones and shown in the top box:
GREEN: HTTP, HTTPS, FTP, SMTP, POP, IMAP, POP3s, IMAPs, DNS, ICMP
BLUE: HTTP, HTTPS, DNS, ICMP
ORANGE: DNS, ICMP
Everything else is forbidden by default except for the System rules which allow access to the services in the Endian Network. The system rules are defined even if the corresponding zones are not enabled.
Note
Access to Endian Network is not permitted to Community Edition appliances.
Possible actions on each rule are to enable or disable it, to edit it or delete it. Additional rules can be added by clicking on the Add a new firewall rule link at the top of the page. Please remember that the order of rules is important: the first matching rule decides whether a packet is allowed or denied, regardless of how many matching rules follow. The order of the rules can be changed by using the up and down arrow icons next to each rule.
The following settings differ from the default common options.
This search widget allows to select the applications that should be part of the rule. Applications are dividend into categories (e.g., Database, filesharing, and so on).
Hint
Enter at least one letter to show all applications whose name starts with that letter.
It is possible to disable or enable the whole outgoing firewall by clicking on the Enable Outgoing firewall switch. When disabled, all outgoing traffic is allowed and no packet is filtered: This setting is however strongly discouraged and the recommendation is to keep the outgoing firewall enabled.
Proxy and outgoing firewall.
Whenever the proxy is activated for a given service (e.g., HTTP, POP, SMTP, DNS), the firewall rules in the outgoing firewall will take no effect, because of the nature of the proxy.
With the proxy activated, whenever a connection starts from a client to the Internet, it will either be intercepted by the proxy on the Endian UTM Appliance (in transparent mode) or go directly to the firewall, but never go through the firewall. The proxy then starts a new connection to the real destination, gets the data and sends it to the client. Those connections to the Internet always start from the Endian UTM Appliance, which hides the clients internal IP address. Therefore, such connections never go through the outgoing firewall, since in fact they are local connections.
This module permits to set up rules that determine how traffic can
flow between the local network zones, excluding therefore the RED zone
(traffic through the RED zone can be filtered in Outgoing traffic and
Port forwarding / NAT). To activate the inter-zone firewall, click on the grey
switch 
. Two boxes are present on this page, one that shows the
current rules and allow to add new ones, and one that allows to set
the inter-zone firewall options.
Note
When the Endian UTM Appliance is configured in no uplink mode, all the network traffic shall be filtered using the interzone firewall. Also when in Stealth uplink mode with more than one zone defined, all the traffic not routed through the gateway is filtered with the interzone firewall. See ref:the stealth uplink description <stealth> for more information.
The Endian UTM Appliance comes with a simple set of pre-configured rules: traffic is allowed from the GREEN zone to any other zone (ORANGE and BLUE) and within each zone, with everything else forbidden by default.
Analogously to the outgoing traffic firewall, rules can be disabled/enabled, edited or deleted by clicking on the appropriate icon on the right side of the table. New rules can be added by clicking on the Add a new inter-zone firewall rule link at the top of the page. Only the common options can be configured.
The inter-zone firewall can be disabled or enabled by using the Enable Inter-Zone firewall switch. When disabled, all traffic is allowed among all the BLUE, GREEN, and ORANGE zones. Disabling the inter-zone firewall is strongly discouraged.
The VPN traffic firewall allows to add firewall rules applied to the users and hosts that are connected via OpenVPN.
The VPN traffic firewall is normally not active, which means that, on the one side, the traffic can freely flow between the VPN hosts and the hosts in the GREEN zone, and on the other side, VPN hosts can access all other zones. Please note that VPN hosts are not subject to the outgoing traffic firewall or the Inter-Zone traffic firewall. Two boxes are present on this page, one that shows the current rules and allow to add new ones, and one that allows to set the VPN firewall options.
The handling and definition of the rules is identical to the outgoing traffic firewall, so please refer to that section and to the common options for directions on the definition and handling of the firewall rules in this module.
The VPN firewall can be disabled or enabled using the Enable VPN firewall switch.
This section governs the rules that grant or deny access to the Endian UTM Appliance itself.
There is a list of pre-configured rules that cannot be changed, whose purpose is to guarantee the proper working of the firewall. Indeed, there are services, among those supplied by the Endian UTM Appliance, that require to be accessed from clients in the various local zones. Examples include using the DNS (which requires that the port 53 be open) to resolve remote hostnames or using the administration web interfaces (which uses port 10443): Whenever one of these services is activated, one or more rules are automatically created to allow the proper efficiency of the service itself.
The list of the pre-defined rules is shown when clicking on the Show rules of system services button at the bottom of the page.
More system access rules can be added by clicking on the Add a new system access rule link. The setting specific to this module of the firewall are:
Note
There is no Destination address, as it is the IP address of the interface from which the access is granted or attempted.
Actions are to disable/enable, edit, or delete a rule from the list of rules.
This page shows, for each of the modules described in this page, a diagram that shows how the traffic flows among the zones, and which is the firewall module that takes charge of the various flows. The green arrowed lines show which traffic is allowed in each zone and in which directions. If the case of VPN, the arrows from/to the RED interface are marked with a red ‘X’, meaning that the traffic is not possible between them.
When an image is clicked, it will be opened into a gallery that allows to browse all of them like in a slide show.