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:
Port forwarding / NAT - port forwarding and abbr:NAT (Network Address Translation).
Outgoing traffic - outgoing traffic, i.e., towards the RED interface
Inter-Zone traffic - traffic between zones.
VPN traffic - traffic generated by VPN users.
System access - grant access to the Endian UTM Appliance host itself.
Firewall diagrams - pictures that show which traffic is intercepted by each type of firewall.
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 configuration options in the firewall’s parts are of the same type (e.g., the source or destination interfaces), since they are built with the same software, iptables. Therefore, in order to keep this section short and readable, all the common configuration items are grouped and explained. The next sections will contain only description of the option that are peculiar to that part of the firewall.
Hint
Multiple values can be supplied for any options: If there is a list of values to choose from, hold the CTRL key (German STRG) and click on each value, otherwise, write one value per line if there is a textbox.
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, in the textbox underneath different values can be written or chosen:
Zone/VPN/Uplink. The source zone, VPN client, or uplink.
Network/IP/Range. The network address, IP address or IP range.
OpenVPN User and L2TP User. An OpenVPN or 2TP users, respectively.
Another drop-down menu to allow the choice among three types of destination that the rule will need to match, which are the same as in the Source:
Zone/VPN/Uplink. The source zone, VPN client, or uplink.
Network/IP/Range. The network address, IP address or IP range.
OpenVPN User and L2TP User. An OpenVPN or 2TP users, respectively.
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 options define the port and protocol for 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).
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 check it with the Intrusion Prevention System.
Allow. Let the packets pass without any check.
Drop. Discard the packet without notifying the sender.
Reject. Discard the packet and send an error packet in response.
Every rule created is by default enabled, but it can be saved and not activated by unticking the checkbox. Disabling a rule may prove useful for troubleshooting connections’ problems.
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!
A description or a remark about the rule, to remember the purpose of the rule.
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.
Hint
Remember that the ordering of the rules matters! Indeed, the rules are processed in the order they appear in the page, from top to bottom, and the destination of the packet depends only on the first rule matched. If no rule matches, the packet is automatically blocked.
The list of actions that can be carried out on each 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 / Destination NAT, Source NAT, and Incoming routed traffic. This module’s purpose is to manage all the traffic that flows from the RED zone (Uplink) to the Endian UTM Appliance and to the other zones (ORANGE, GREEN, BLUE).
Destination NAT is usually employed to limit network accesses from an untrusted network or to redirect the traffic coming from the untrusted network 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 set up the advanced configuration of the rule: Access from, Policy, and the Type of the Translate to option.
Besides the common options, these other settings can be configured:
This part of the form changes depending on the current 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:
Warning
Remember to always add a valid value (IP address, network, OpenVPN user, and so on) in the textfield below the Translate to option, otherwise the rule will not be applied.
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.
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 . 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.
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 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.
If none of the above helps, analysing the network traffic from the CLI with tcpdump on the Endian UTM Appliance might prove useful, in that it will show if the network traffic flows from the expected RED interface to the expected server. Also using iptables with the -v option (verbose mode) to count packets on each rule might help.
In this tab 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:
Select to either apply NAT, No NAT, or Map Network. The choice to use NAT allows the selection of the IP address that should be used among those presented in the drop-down menu. The Auto entries will automatically choose the IP address corresponding to the outgoing interface.
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:
Configure the ORANGE zone with any subnet (e.g., 192.168.100.0).
Setup the SMTP server to listen on port 25 on an IP in the ORANGE zone (e.g., 129.168.100.13).
In the section, add a static Ethernet uplink with IP 123.123.123.123 to the Endian UTM Appliance.
Add a source NAT rule and specify the ORANGE IP of the SMTP server as source address. Be sure to use NAT and set the NAT-ed source IP address to 123.123.123.123.
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.
A Typical Scenario for Incoming routed traffic.
A typical example to show what kind of network traffic the incoming routed firewall matches is a local DMZ (Orange) network with servers having public IP addresses.
Suppose the Endian UTM Appliance is configured as follows:
Uplink (RED)
1.1.1.2/30 - Endian Uplink ip
1.1.1.1/30 - ISP router (default gateway for Endian)
1.1.1.0/30 - Network address
1.1.1.3 - Broadcast address
The Endian UTM Appliance connects to an ISP and receives one public IP addresses (1.1.1.2) and a gateway (1.1.1.1), through which it connects to the Internet.
DMZ (ORANGE)
2.2.2.1/28 - Endian (default gateway for DMZ Network)
2.2.2.2-14 - Public IPs for server
2.2.2.0/28 - Network address
2.2.2.15 - Broadcast
The local DMZ network consists of 14 public IP addresses in the 2.2.2.1/28 network and connects to the Internet using the 2.2.2.1 gateway (ORANGE IP of the Endian UTM Appliance).
Routing on the ISP side must be configured using the following rule:
route 2.2.2.0/28 via 1.1.1.2
The ISP sends all the traffic directed to the public 2.2.2.0/28 subnet to the Endian UTM Appliance.
With this configuration, on the main uplink will arrive (incoming) packets with destination 1.1.1.2 that are connection to the uplink of the Endian UTM Appliance and are connections to services offered, like OpenVPN, IPsec, and the like.
However, the Endian UTM Appliance will also receive packets with destination in the 2.2.2.2-2.2.2.14 range, because there’s a route for them set by the ISP. This traffic is both INCOMING -because it comes from the uplink- and ROUTED because the ISP has the routing rule for packages with that destination.
By default this traffic would be dropped, and must therefore be allowed with a rule in the incoming routed firewall. Moreover, this kind of traffic can not be configured with a DNAT rule, because the destination IP address is already public.
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 5.1, 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:
Stateful firewall rules, that filter traffic between IP addresses and ports.
Application Rules, i.e., rules that filter traffic generated by application.
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:
an application rule blocking the gmail and youtube protocols
a stateful rule allowing all http traffic.
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 ORANGE: DNS, ICMP BLUE: HTTP, HTTPS, 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.
It can be one or more Zone/Interfaces, Network/IP, or MAC addresses.
It can be the RED zone, one or more uplinks, or one or more network/host addresses accessible outside the RED interface.
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.
Ticking this checkbox causes all the accepted connections to the RED interface to be logged.
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.
Ticking this checkbox causes all the accepted connections among the zones to be logged.
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 clients and the hosts in the GREEN zone, and on the other side, VPN hosts can access all the zones behind the Endian UTM Appliance.
Note
VPN clients 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.
By default there is no rule defined, therefore to add rules, click on the Add a new VPN firewall rule link at the top of the page. Only the common options are available to define the rules.
The VPN firewall can be disabled or enabled using the Enable VPN firewall switch.
Ticking this checkbox causes all the accepted connections from the VPN users to be logged.
This section governs the rules that grant or deny access to the Endian UTM Appliance itself and to the services that run on it.
There is a list of pre-configured rules that cannot be changed, whose purpose is to guarantee the proper working of the services running on the Endian UTM Appliance, that require to be accessed from clients that are located either in the local or remote zones.
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.
Examples of the system access rules include services that are always active, for example the DNS service to resolve hostnames (which requires that the port 53 be open), or the access to the administration web interfaces (which uses port 10443). Moreover, whenever a services (e.g., OpenVPN, the Hotspot, SNMP server among others) is activated, one or more rules are automatically created to allow the proper efficiency of the service itself.
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:
All packets that access or try to access the Endian UTM Appliance are logged when this checkbox is ticked. This option proves useful to know who accessed -or tried to access- the system.
The MAC addresses of the incoming connection.
The interface from which the system can be accessed
Note
There is no Destination address, as it is the IP address of the interface from which the access is granted or attempted.
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.