The Firewall Menu

This section allows to set up rules that specify if and how the network traffic flows through the UTM. The firewall on the UTM is divided in different modules, each monitoring and allowing or blocking one specific type of traffic. The modules available are the following:

  • Outgoing traffic–outgoing traffic, i.e., towards the RED interface

  • Inter-Zone traffic–traffic between zones

  • VPN traffic–traffic generated by VPN users

  • Port forwarding, Source NAT, and Incoming routed traffic–port forwarding and various NAT traffic

  • System access–grant access to the UTM host itself

  • Network Objects–groups object to shorten rules

  • Docker traffic–define how traffic flows to and from docker containers

  • Firewall diagrams–pictures that show which traffic is intercepted by each type of firewall

New in version 6.0: Network objects–define groups of network items to simplify set up and reading of firewall rules.

New in version 6.0: Time-based rules–constrain firewall rules to be operational only during given timespans.

New in version 6.0: Rules for Docker traffic

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 UTM 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 UTM.

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 System rules, whose purpose is to allow the correct interoperability of the services running on the UTM 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.

Outgoing traffic

The UTM 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.

It is possible to disable or enable the whole outgoing firewall by clicking on the Disabled 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.

UTM and Application Firewall (Application Control).

Application firewalls represent an improvement to stateful firewalls, which are still used to keep track of the connection’s origin and path and to decide the destination of packets, by adding the ability to inspect the packets, with the purpose to provide higher security from worm, viruses, malware, and all types of threats.

Since this new ability is used to identify the application–in a broad sense: an application can be a software running on a computer, a cloud service, a browser, or a protocol–generating traffic, 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.0, every Endian 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 older, pre-3.0 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 UTM is to allow all HTTP traffic, with no restriction. This rule must therefore be disabled as first step. Then, two rules must be defined:

  1. an application rule blocking the gmail and youtube protocols

  2. 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.

Three boxes are present on this page: Settings, Current rules, and System rules.

Settings

This box contains one option.

Log accepted Outgoing connection

By ticking this checkbox, all outgoing connections that are not blocked by the firewall will be written in the log file.

Current rules

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, shown in the box below,

System rules.

The rules defined in this box allow a correct access to the Endian Network. They are needed to verify the maintenance status, to access the UTM from a remote location through the Endian Network, and to allow members of the support team to check the UTM and work out problem reported in tickets.

Note

The Current rules and the System rules are defined even if they involve zones that are not (yet) enabled.

New rules can be added by clicking on the Add new rule link on the top right of the Current rules box. 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 other matching rules may follow. The order of the rules can be changed by using the arrow icons in the Actions column.

Note

Rules defined in the outgoing firewall are disregarded when the UTM is in bridged mode, because in this case only the traffic from the zone behind the UTM through the NIC designated as uplink is considered as outgoing.

Rule editor

The following settings are available in the Rule Editor.

Source

Type

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, a drop-down menu or a textbox will appear underneath, to help supply the required values for the rule.

  • <ANY>. A shortcut for every source.

  • Zone/Interface. A zone or interface.

  • Network/IP. A subnet or IP address.

  • Network Objects. A network object, see Objects.

  • MAC. The MAC address of the interface.

Destination

Type

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:

  • RED. The RED zone, i.e., all active uplinks.

  • Uplink. A specific uplink.

  • Network/IP. A subnet or IP address.

  • Network Objects. A network object, see Objects.

Service/Port

Service

The service that the rule should match.

Hint

User defined permits to specify a custom protocol and the ports to block, an option that proves useful when running services on ports different from the standard ones.

Protocol

The type of traffic that is interested by the rule: TCP, UDP, TCP+UDP, ESP, GRE, and ICMP. TCP and UDP are the most used, GRE is used by tunnels, ESP by IPsec, and ICMP by the ping and traceroute commands.

Destination port

The destination port for the rule.

Note

There exist dozens predefined services that can be chosen from the drop-down menus and should suffice to cover the most use cases. An user defined combination of port and protocol should be used only if a service is not running on a standard port (e.g., the SSH server listens to port 2345 or the web server runs on port 7981) or if a service, not included in the list, is using a particular port.

Countries (GeoIP)

New in version 6.5.

Geo-IP filtering now allows you to restrict access to a given firewall rule based on the source country or geographic region. This is done via a database mapping which contains country-to-IP/networks and is regularly updated in order to provide the most accurate information.

Note

This is especially useful when you know that traffic from other countries should not be accessing your network or when you receive repetitive malicious traffic always from the same country/region.

Source

Select the dropdown or start typing to find a country in order to select one or more. After selecting one you can continue selecting to add as many countries as you need.

Negate

Select this checkbox to negate your selected countries. This means the rule will match all countries except the selected ones.

Applications

Application

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.

Restrict on time and day

New in version 6.0.

Time-based constraints can be added to each rule to define in which time window a rule should be activated. The following options can be configured

Time from

The starting time of the rule’s validity, in 24h format.

Time to

The ending time of the rule’s validity, in 24h format.

Days

Select from the drop-down menu in which days of the week the rule will be applied. Multiple choices are possible.

Hint

To remove a selected day, simply click on it.

Policy

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 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.

Remark

A description or a remark about the rule, to remember the purpose of the rule.

Position

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 firewall rules are processed in the order they appear in the page, from top to bottom, and the destination of the packets depends only on the first rule matched. If no rule matches, the packet is automatically blocked, due to the implicit DROP rule, which blocks everything that has not matched.

Enabled

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’ issues.

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!

System rules

This table contains all rules that are automatically set up by the various daemons ans services running on the UTM and can not be disabled, because they are necessary for the services to work properly.

Inter-Zone traffic

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). When disabled, all traffic is allowed across all the enabled BLUE, GREEN, and ORANGE zones. Disabling the inter-zone firewall is strongly discouraged. To activate the inter-zone firewall, click on the grey switch Disabled.

Three boxes are present on this page: Settings, Current rules, and System rules.

Note

When the UTM is configured in no uplink mode, all the network traffic should 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.

Settings

Log accepted Inter-Zone connections

Ticking this checkbox causes all the accepted connections among the zones to be logged.

Current rules

The UTM 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 new rule link at the top of the page.

Source

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, a drop-down menu or a textbox will appear underneath, to help supply the required values for the rule.

  • <ANY>. A shortcut for every source.

  • Zone/Interface. A zone or interface.

  • Network/IP. A subnet or IP address.

  • Network Objects. A network object, see Objects.

  • MAC. The MAC address of the interface.

Destination

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:

  • <ANY>. A shortcut for every destination.

  • Zone/Interface. A zone or interface.

  • Network/IP. A subnet or IP address.

  • Network Objects. A network object, see Objects.

Service/Port

Service

The service that the rule should match.

Hint

User defined permits to specify a custom protocol and the ports to block, an option that proves useful when running services on ports different from the standard ones.

Protocol

The type of traffic that is interested by the rule: TCP, UDP, TCP+UDP, ESP, GRE, and ICMP. TCP and UDP are the most used, GRE is used by tunnels, ESP by IPsec, and ICMP by the ping and traceroute commands.

Destination port

The destination port for the rule.

Note

There exist dozens predefined services that can be chosen from the drop-down menus and should suffice to cover the most use cases. An user defined combination of port and protocol should be used only if a service is not running on a standard port (e.g., the SSH server listens to port 2345 or the web server runs on port 7981) or if a service, not included in the list, is using a particular port.

Restrict on time and day

New in version 6.0.

Time-based constraints can be added to each rule to define in which time window a rule should be activated. The following options can be configured

Time from

The starting time of the rule’s validity, in 24h format.

Time to

The ending time of the rule’s validity, in 24h format.

Days

Select from the drop-down menu in which days of the week the rule will be applied. Multiple choices are possible.

Hint

To remove a selected day, simply click on it.

Policy

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 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.

Remark

A description or a remark about the rule, to remember the purpose of the rule.

Position

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 firewall rules are processed in the order they appear in the page, from top to bottom, and the destination of the packets depends only on the first rule matched. If no rule matches, the packet is automatically blocked, due to the implicit DROP rule, which blocks everything that has not matched.

Enabled

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’ issues.

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!

System rules

This table contains all rules that are automatically set up by the various daemons ans services running on the UTM and can not be disabled, because they are necessary for the services to work properly.

VPN traffic

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 the traffic can freely flow between the VPN clients and the hosts in the GREEN zone and VPN hosts can access all the zones behind the UTM.

Note

It is important to remember that only rules of the VPN traffic firewall are applied to VPN clients, but not rules of the outgoing traffic and the Inter-Zone traffic firewall .

The VPN firewall can be enabled by clicking the Disabled switch.

Three boxes are present on this page: Settings, Current rules, and System rules.

Settings

Log accepted VPN connections

Ticking this checkbox causes all the accepted connections from the VPN users to be logged.

Current rules

By default here there is no rule defined, which means that all the VPN traffic is blocked. To add new rules, click on the Add new rule button at the top of the box. The Rule Editor will open, in which to define new rules for the VPN clients.

System rules.

The rules defined in this box can not be deactivated and are automatically generated to allow the correct operations of the UTM.

Rule editor

The following settings are available in the Rule Editor.

Source

Type

The type of the source or incoming connection that should be matched. Depending on the choice, a drop-down menu or a textbox will appear underneath, to help supply the required values for the rule.

  • <ANY>. A shortcut for every source.

  • Zone/Interface. A zone or interface.

  • OpenVPN User and L2TP User. An OpenVPN or 2TP users.

  • Network/IP. A subnet or IP address.

  • Network Object. A network object, see Objects.

  • MAC. The MAC address of the interface.

Destination

Type

Another drop-down menu to allow the choice among types of destination that the rule will need to match.

  • <ANY>. A shortcut for every destination.

  • Zone/VPN/Uplink. A zone, VPN client, or uplink.

  • OpenVPN User and L2TP User. An OpenVPN or 2TP users, respectively.

  • Network/IP. A subnet or IP address.

  • Network Object. A network object, see Objects.

Service/Port

Service

The service that the rule should match.

Hint

User defined permits to specify a custom protocol and the ports to block, an option that proves useful when running services on ports different from the standard ones.

Protocol

The type of traffic that is interested by the rule: TCP, UDP, TCP+UDP, ESP, GRE, and ICMP. TCP and UDP are the most used, GRE is used by tunnels, ESP by IPsec, and ICMP by the ping and traceroute commands.

Destination port

The destination port for the rule.

Note

There exist dozens predefined services that can be chosen from the drop-down menus and should suffice to cover the most use cases. An user defined combination of port and protocol should be used only if a service is not running on a standard port (e.g., the SSH server listens to port 2345 or the web server runs on port 7981) or if a service, not included in the list, is using a particular port.

Restrict on time and day

New in version 6.0.

Time-based constraints can be added to each rule to define in which time window a rule should be activated. The following options can be configured

Time from

The starting time of the rule’s validity, in 24h format.

Time to

The ending time of the rule’s validity, in 24h format.

Days

Select from the drop-down menu in which days of the week the rule will be applied. Multiple choices are possible.

Hint

To remove a selected day, simply click on it.

Policy

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 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.

Remark

A description or a remark about the rule, to remember the purpose of the rule.

Position

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 firewall rules are processed in the order they appear in the page, from top to bottom, and the destination of the packets depends only on the first rule matched. If no rule matches, the packet is automatically blocked, due to the implicit DROP rule, which blocks everything that has not matched.

Enabled

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’ issues.

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!

Port forwarding

Changed in version 6.0: The editor’s Simple and Advanced Mode have been merged.

Port forwarding, called also Destination NAT is usually employed to selectively allow accesses from an untrusted network or to redirect the traffic coming from the untrusted network to a given port or IP address-port combination. It is possible to define which port on which interface should be forwarded to which host and port. This page contains two boxes, Current Rules and System rules.

Current rules

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.

By default here there is no rule defined, therefore to add rules, click on the Add new rule button at the top of the page.

Rule editor

The following options are available.

incoming destination

Type

This option determines where the incoming connection will be forwarded. The following options can be selected:

  • Zone/VPN/Uplink. From which zone, VPN client, or uplink the connection is allowed.

  • Network/IP. A subnet or IP address.

  • Network Objects. A network object, see Objects.

  • OpenVPN User and L2TP User. An OpenVPN or 2TP users.

Service/Port

Service

The service that the rule should match.

Hint

User defined permits to specify a custom protocol and the ports to block, an option that proves useful when running services on ports different from the standard ones.

Protocol

The type of traffic that is interested by the rule: TCP, UDP, TCP+UDP, ESP, GRE, and ICMP. TCP and UDP are the most used, GRE is used by tunnels, ESP by IPsec, and ICMP by the ping and traceroute commands.

Destination port

The destination port for the rule.

Note

There exist dozens predefined services that can be chosen from the drop-down menus and should suffice to cover the most use cases. An user defined combination of port and protocol should be used only if a service is not running on a standard port (e.g., the SSH server listens to port 2345 or the web server runs on port 7981) or if a service, not included in the list, is using a particular port.

Access from

Access from every zone

By default the rule is valid for any incoming connection; untick the checkbox to selectively allow access from the following environments to the IP and service configured in the rule

  • Zone/VPN/Uplink. From which zone, VPN client, or uplink the connection is allowed.

  • Network/IP. The network address or IP address to which the rule is applied.

  • Network Objects. A network object, see Objects.

  • OpenVPN user. Select for which OpenVPN clients the rule will be valid.

  • L2TP user. Select for which L2TP clients the rule will be valid.

Countries (GeoIP)

New in version 6.5.

Geo-IP filtering now allows you to restrict access to a given firewall rule based on the source country or geographic region. This is done via a database mapping which contains country-to-IP/networks and is regularly updated in order to provide the most accurate information.

Note

This is especially useful when you know that traffic from other countries should not be accessing your network or when you receive repetitive malicious traffic always from the same country/region.

Source

Select the dropdown or start typing to find a country in order to select one or more. After selecting one you can continue selecting to add as many countries as you need.

Negate

Select this checkbox to negate your selected countries. This means the rule will match all countries except the selected ones.

Restrict on time and day

New in version 6.0.

Time-based constraints can be added to each rule to define in which time window a rule should be activated. The following options can be configured

Time from

The starting time of the rule’s validity, in 24h format.

Time to

The ending time of the rule’s validity, in 24h format.

Days

Select from the drop-down menu in which days of the week the rule will be applied. Multiple choices are possible.

Hint

To remove a selected day, simply click on it.

translate to

Type

This option determines where the incoming connection will be forwarded. The following options can be selected:

  1. IP is a single destination IP address, which includes the port or port range to forward traffic to and if to apply NAT or not to the incoming packets.

  2. OpenVPN User. choose one OpenVPN user as the destination target for the traffic.

  3. L2TP User. select one L2TP user as the destination target for the traffic.

  4. Map 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
    
  5. Load Balancing: specify a range of IP addresses to which traffic will be split, to avoid bottlenecks or the overloading of a single IP.

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 and 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.

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!

System rules

This table contains all rules that are automatically set up by the various daemons ans services running on the UTM and can not be disabled, because they are necessary for the services to work properly.

Troubleshooting port-forwarding.

There are mainly two reasons why port-forwarding may not work.

  1. The UTM is behind a NAT device.

    In this case there is a device like a router or another firewall between the UTM 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 UTM, if this is possible.

  2. 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 UTM. 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 UTM 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.

See also

The following tutorials are available in Endian knowledge base:

DNAT (Basic Setup) https://help.endian.com/hc/en-us/articles/218144268

DNAT (Advanced Setup) https://help.endian.com/hc/en-us/articles/218144258

Source NAT

In this page can be defined rules that apply SNAT to outgoing connections. This page contains two boxes, Current Rules and System rules.

Current rules

Source NAT can be useful if a server behind the UTM 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 new rule and configure the following setting.

Source

Type

The type of the source or incoming connection that should be matched. Depending on the type, a drop-down menu or a textbox will appear underneath, to help supply the required values for the rule.

  • Network/IP. A subnet or IP address.

  • Network Objects. A network object, see Objects.

  • OpenVPN User and L2TP User. An OpenVPN or 2TP users.

Destination

Type

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. A zone, VPN client, or uplink.

  • Network/IP. A subnet or IP address.

  • Network Objects. A network object, see Objects.

  • OpenVPN User and L2TP User. An OpenVPN or 2TP users, respectively.

Service/Port

Service

The service that the rule should match.

Hint

User defined permits to specify a custom protocol and the ports to block, an option that proves useful when running services on ports different from the standard ones.

Protocol

The type of traffic that is interested by the rule: TCP, UDP, TCP+UDP, ESP, GRE, and ICMP. TCP and UDP are the most used, GRE is used by tunnels, ESP by IPsec, and ICMP by the ping and traceroute commands.

Destination port

The destination port for the rule.

Note

There exist dozens predefined services that can be chosen from the drop-down menus and should suffice to cover the most use cases. An user defined combination of port and protocol should be used only if a service is not running on a standard port (e.g., the SSH server listens to port 2345 or the web server runs on port 7981) or if a service, not included in the list, is using a particular port.

Restrict on time and day

New in version 6.0.

Time-based constraints can be added to each rule to define in which time window a rule should be activated. The following options can be configured

Time from

The starting time of the rule’s validity, in 24h format.

Time to

The ending time of the rule’s validity, in 24h format.

Days

Select from the drop-down menu in which days of the week the rule will be applied. Multiple choices are possible.

Hint

To remove a selected day, simply click on it.

NAT

NAT

Select to either apply NAT, No NAT, or Map Network. If the choice is:strong:No NAT, no additional option will be available, otherwise one more option appears.


to source address

Choose from the dropdown menu the available IPs to which NAT will be applied. This option is available only if the choice is NAT.

to subnet

Write in the textarea the subnet that will be use for NAT. This option is available only if the choice is Map network.


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.

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.

Enabled

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’ issues.

System rules

This table contains all rules that are automatically set up by the various daemons ans services running on the UTM and can not be disabled, because they are necessary for the services to work properly.

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 RED IP 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:

  1. Configure the ORANGE zone with any subnet (e.g., 192.168.100.0).

  2. Setup the SMTP server to listen on port 25 on an IP in the ORANGE zone (e.g., 129.168.100.13).

  3. In the Menubar ‣ Network ‣ Interfaces section, add a static Ethernet uplink with IP 123.123.123.123 to the UTM.

  4. 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

The following tutorial is available in Endian knowledge base:

SNAT (Basic Setup) https://help.endian.com/hc/en-us/articles/218144248

Incoming routed traffic

This page allows to redirect traffic that has been routed through the UTM. 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.

This page contains two boxes, Current Rules and System rules.

Current rules

New rules can be defined by clicking on the Add new rule button.

Source

Type

The type of the source or incoming connection that should be matched. Depending on the type, a drop-down menu or a textbox will appear underneath, to help supply the required values for the rule.

  • RED. The entire RED zone.

  • Uplink. One or more uplinks.

  • Network/IP. A subnet or IP address.

  • Network Objects. A network object, see Objects.

Destination

Type

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:

  • <ANY>. A shortcut to include all possible destinations..

  • Zone. A zone managed by the UTM.

  • Network/IP. A subnet or IP address.

  • Network Objects. A network object, see Objects.

Service/Port

Service

The service that the rule should match.

Hint

User defined permits to specify a custom protocol and the ports to block, an option that proves useful when running services on ports different from the standard ones.

Protocol

The type of traffic that is interested by the rule: TCP, UDP, TCP+UDP, ESP, GRE, and ICMP. TCP and UDP are the most used, GRE is used by tunnels, ESP by IPsec, and ICMP by the ping and traceroute commands.

Destination port

The destination port for the rule.

Note

There exist dozens predefined services that can be chosen from the drop-down menus and should suffice to cover the most use cases. An user defined combination of port and protocol should be used only if a service is not running on a standard port (e.g., the SSH server listens to port 2345 or the web server runs on port 7981) or if a service, not included in the list, is using a particular port.

Countries (GeoIP)

New in version 6.5.

Geo-IP filtering now allows you to restrict access to a given firewall rule based on the source country or geographic region. This is done via a database mapping which contains country-to-IP/networks and is regularly updated in order to provide the most accurate information.

Note

This is especially useful when you know that traffic from other countries should not be accessing your network or when you receive repetitive malicious traffic always from the same country/region.

Source

Select the dropdown or start typing to find a country in order to select one or more. After selecting one you can continue selecting to add as many countries as you need.

Negate

Select this checkbox to negate your selected countries. This means the rule will match all countries except the selected ones.

Restrict on time and day

New in version 6.0.

Time-based constraints can be added to each rule to define in which time window a rule should be activated. The following options can be configured

Time from

The starting time of the rule’s validity, in 24h format.

Time to

The ending time of the rule’s validity, in 24h format.

Days

Select from the drop-down menu in which days of the week the rule will be applied. Multiple choices are possible.

Hint

To remove a selected day, simply click on it.

Policy

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 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.

Remark

A description or a remark about the rule, to remember the purpose of the rule.

Position

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 firewall rules are processed in the order they appear in the page, from top to bottom, and the destination of the packets depends only on the first rule matched. If no rule matches, the packet is automatically blocked, due to the implicit DROP rule, which blocks everything that has not matched.

Enabled

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’ issues.

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!

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 UTM 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 UTM 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 UTM).

  • 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 UTM.

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 UTM and are connections to services offered, like OpenVPN, IPsec, and the like.

However, the UTM 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.

System rules

This table contains all rules that are automatically set up by the various daemons ans services running on the UTM and can not be disabled, because they are necessary for the services to work properly.

System access

This section governs the rules that grant or deny access to the UTM itself and to the services that run on it; it is organised in three boxes: Settings, Current rules, and System Rules.

Settings

Log packets

All packets that access or try to access the UTM are logged when this checkbox is ticked. This option proves useful to know who accessed -or tried to access- the system.

Current rules

More system access rules can be added by clicking on the Add new rule link. The setting that can be configured are the following:

Rule Editor

Source

Insert Network/IPs/MACs

Write in the textbox the networks, IP addresses, and MAC addresses that should be matched.

Note

The items written as source must be the configured on the interface selected in the next option.

Select interfaces

Select from the drop-down menu which interface should be matched.

Service/Port

Service

The service that the rule should match.

Hint

User defined permits to specify a custom protocol and the ports to block, an option that proves useful when running services on ports different from the standard ones.

Protocol

The type of traffic that is interested by the rule: TCP, UDP, TCP+UDP, ESP, GRE, and ICMP. TCP and UDP are the most used, GRE is used by tunnels, ESP by IPsec, and ICMP by the ping and traceroute commands.

Destination port

The destination port for the rule.

Note

There exist dozens predefined services that can be chosen from the drop-down menus and should suffice to cover the most use cases. An user defined combination of port and protocol should be used only if a service is not running on a standard port (e.g., the SSH server listens to port 2345 or the web server runs on port 7981) or if a service, not included in the list, is using a particular port.

Countries (GeoIP)

New in version 6.5.

Geo-IP filtering now allows you to restrict access to a given firewall rule based on the source country or geographic region. This is done via a database mapping which contains country-to-IP/networks and is regularly updated in order to provide the most accurate information.

Note

This is especially useful when you know that traffic from other countries should not be accessing your network or when you receive repetitive malicious traffic always from the same country/region.

Source

Select the dropdown or start typing to find a country in order to select one or more. After selecting one you can continue selecting to add as many countries as you need.

Negate

Select this checkbox to negate your selected countries. This means the rule will match all countries except the selected ones.

Restrict on time and day

New in version 6.0.

Time-based constraints can be added to each rule to define in which time window a rule should be activated. The following options can be configured

Time from

The starting time of the rule’s validity, in 24h format.

Time to

The ending time of the rule’s validity, in 24h format.

Days

Select from the drop-down menu in which days of the week the rule will be applied. Multiple choices are possible.

Hint

To remove a selected day, simply click on it.

Policy

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 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.

Remark

A description or a remark about the rule, to remember the purpose of the rule.

Position

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 firewall rules are processed in the order they appear in the page, from top to bottom, and the destination of the packets depends only on the first rule matched. If no rule matches, the packet is automatically blocked, due to the implicit DROP rule, which blocks everything that has not matched.

Enabled

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’ issues.

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!

Note

There is no Destination address, as it is the IP address of the interface from which the access is granted or attempted.

System rules

This table contains all rules that are automatically set up by the various daemons ans services running on the UTM and can not be disabled, because they are necessary for the services to work properly.

Objects

A network object is a group of similar (network) items that can be used together as a whole in the source or destination of firewall rules. For example, a network object can be a set of 15 IPs which are subject of a same rule. Without network objects, there will be a long set of firewall rules in the GUI–that in more complex setups can become unreadable–and cause unwanted or unexpected behaviours, making troubleshooting difficult. However, by using a network object that contains all the above-mentioned subnets, there will be only one rule.

An additional advantage of this approach is that if for any reason one network object must be modified, the firewall rules involving it will need no adjustment.

In the table there are the objects already defined, and a new network object can be created by clicking on the Add new object button on the top right corner of the table.

The following options are available.

Name

The name given to the object, which must be unique. This name will appear in the GUI as the source or destination of a rule.

Description

An optional description of the object.

IPs/CIDRs/IP Ranges

Insert here which IP addresses, IP ranges, or subnets in CIDR notation will be part of the network object. It is possible to mix all three of them in a same object, like for example:

192.168.0.15/28
192.168.0.230
192.168.0.240-192.168.0.248

Hint

Write one IP, IP range, or subnet per line.

Docker traffic

This page allows to define custom rule applied to the network traffic generated by the Docker containers. Distinct rules can be defined and applied to incoming and outgoing traffic.

Incoming

This page contains two boxes, one to configure log settings, the other where current rules are shown.

Settings

In this box only one option is available.

Log packets

Write in the log file all packets that are directed towards the docker containers.

Current rules

The UTM comes with one pre-configured rule for the docker incoming traffic: all traffic from containers in the GREEN zone is allowed. Additional rules can be added by clicking on the Add new rule button in the top right corner and configuring them in the Rule editor.

Rule editor

The following configuration items are available.

Source

Type

Select the type of the source from which to filter the traffic. Valid options are:

  • <ANY>. A shortcut to include all possible destinations.

  • OpenVPN User and L2TP User. An OpenVPN or 2TP users.

  • Zone/Interface. From which zone the traffic should be matched.

  • Network/IP. A subnet or IP address.

  • Network Objects. A network object, see Objects.

  • MAC. The MAC Address of the interface.

Suitable drop-down menus will appear on the right-hand side to insert the actual values for the chosen option.

Service/Port

Service

The service that the rule should match.

Hint

User defined permits to specify a custom protocol and the ports to block, an option that proves useful when running services on ports different from the standard ones.

Protocol

The type of traffic that is interested by the rule: TCP, UDP, TCP+UDP, ESP, GRE, and ICMP. TCP and UDP are the most used, GRE is used by tunnels, ESP by IPsec, and ICMP by the ping and traceroute commands.

Destination port

The destination port for the rule.

Note

There exist dozens predefined services that can be chosen from the drop-down menus and should suffice to cover the most use cases. An user defined combination of port and protocol should be used only if a service is not running on a standard port (e.g., the SSH server listens to port 2345 or the web server runs on port 7981) or if a service, not included in the list, is using a particular port.

Countries (GeoIP)

New in version 6.5.

Geo-IP filtering now allows you to restrict access to a given firewall rule based on the source country or geographic region. This is done via a database mapping which contains country-to-IP/networks and is regularly updated in order to provide the most accurate information.

Note

This is especially useful when you know that traffic from other countries should not be accessing your network or when you receive repetitive malicious traffic always from the same country/region.

Source

Select the dropdown or start typing to find a country in order to select one or more. After selecting one you can continue selecting to add as many countries as you need.

Negate

Select this checkbox to negate your selected countries. This means the rule will match all countries except the selected ones.

Restrict on time and day

New in version 6.0.

Time-based constraints can be added to each rule to define in which time window a rule should be activated. The following options can be configured

Time from

The starting time of the rule’s validity, in 24h format.

Time to

The ending time of the rule’s validity, in 24h format.

Days

Select from the drop-down menu in which days of the week the rule will be applied. Multiple choices are possible.

Hint

To remove a selected day, simply click on it.

Policy

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 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.

Remark

A description or a remark about the rule, to remember the purpose of the rule.

Position

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 firewall rules are processed in the order they appear in the page, from top to bottom, and the destination of the packets depends only on the first rule matched. If no rule matches, the packet is automatically blocked, due to the implicit DROP rule, which blocks everything that has not matched.

Enabled

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’ issues.

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!

Outgoing

This page contains two boxes, one to configure log settings, the other where actual rules are shown.

Settings

In this box only one option is available.

Log packets

Write in the log file all packets that are directed towards the docker containers.

Current rules

The UTM comes with a few pre-configured rules for the docker outgoing traffic, that allow HTTP and HTTPS traffic, DNS resolution, and ICMP traffic on containers’ NIC. Additional rules can be added by clicking on the Add new rule button in the top right corner and configuring them in the Rule editor.

Rule editor

The following configuration items are available.

Destination

Type

Select the type of the source from which to filter the traffic. Valid options are:

  • <ANY>. A shortcut to include all possible destinations.

  • Zone/VPN/Uplink. From which zone, VPN client, or uplink the connection is allowed.

  • OpenVPN User and L2TP User. An OpenVPN or 2TP users.

  • Network/IP. A subnet or IP address.

  • Network Objects. A network object, see Objects.

Suitable drop-down menus will appear on the right-hand side to insert the actual values for the chosen option.

Service/Port

Service

The service that the rule should match.

Hint

User defined permits to specify a custom protocol and the ports to block, an option that proves useful when running services on ports different from the standard ones.

Protocol

The type of traffic that is interested by the rule: TCP, UDP, TCP+UDP, ESP, GRE, and ICMP. TCP and UDP are the most used, GRE is used by tunnels, ESP by IPsec, and ICMP by the ping and traceroute commands.

Destination port

The destination port for the rule.

Note

There exist dozens predefined services that can be chosen from the drop-down menus and should suffice to cover the most use cases. An user defined combination of port and protocol should be used only if a service is not running on a standard port (e.g., the SSH server listens to port 2345 or the web server runs on port 7981) or if a service, not included in the list, is using a particular port.

Applications

Here it is possible to define Application firewall rules for docker container. Please check the dedicated description of application firewall.

Application

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.

Countries (GeoIP)

New in version 6.5.

Geo-IP filtering now allows you to restrict access to a given firewall rule based on the source country or geographic region. This is done via a database mapping which contains country-to-IP/networks and is regularly updated in order to provide the most accurate information.

Note

This is especially useful when you know that traffic from other countries should not be accessing your network or when you receive repetitive malicious traffic always from the same country/region.

Source

Select the dropdown or start typing to find a country in order to select one or more. After selecting one you can continue selecting to add as many countries as you need.

Negate

Select this checkbox to negate your selected countries. This means the rule will match all countries except the selected ones.

Restrict on time and day

New in version 6.0.

Time-based constraints can be added to each rule to define in which time window a rule should be activated. The following options can be configured

Time from

The starting time of the rule’s validity, in 24h format.

Time to

The ending time of the rule’s validity, in 24h format.

Days

Select from the drop-down menu in which days of the week the rule will be applied. Multiple choices are possible.

Hint

To remove a selected day, simply click on it.

Policy

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 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.

Remark

A description or a remark about the rule, to remember the purpose of the rule.

Position

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 firewall rules are processed in the order they appear in the page, from top to bottom, and the destination of the packets depends only on the first rule matched. If no rule matches, the packet is automatically blocked, due to the implicit DROP rule, which blocks everything that has not matched.

Enabled

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’ issues.

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!

Firewall Diagrams

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 arrows show which traffic is allowed in each zone and in which direction, while the lines marked with a red X shows if the traffic is forbidden.

When an image is clicked, it will be opened into a gallery that allows to browse all of them like in a slide show.