The Firewall Menu¶

In this page you find:

Outgoing traffic
Inter-Zone traffic
VPN traffic
Port forwarding
Source NAT
Incoming routed traffic
System access
Objects
Firewall Diagrams

This section allows to set up rules that specify if and how the network traffic flows through the 4i Edge X. The firewall on the 4i Edge X 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 / NAT–port forwarding and NAT.
System access–grant access to the 4i Edge X host itself.
Network Objects–groups object to shorten rules.
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.

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 4i Edge X 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 4i Edge X.

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 4i Edge X 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 4i Edge X 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.

4i Edge X 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 4i Edge X 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.

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 4i Edge X from a remote location through the Endian Network, and to allow members of the support team to check the 4i Edge X 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 4i Edge X is in bridged mode, because in this case only the traffic from the zone behind the 4i Edge X 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 Object. 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 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.

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

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.

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 4i Edge X 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). To activate the inter-zone firewall, click on the grey switch Disabled. 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 4i Edge X 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

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.

Log accepted Inter-Zone connections: Ticking this checkbox causes all the accepted connections among the zones to be logged.

Current rules

The 4i Edge X 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 Object. 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 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

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.

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 4i Edge X 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, 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 4i Edge X.

Note

Rules of the outgoing traffic firewall and the Inter-Zone traffic firewall do not apply to VPN clients.

Three boxes are present on this page: one containing the settings, one that shows the current rules and allow to add new ones, and the last with the system rules, which can not be deactivated.

Settings

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

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, therefore to add rules, click on the Add new rule button at the top of the page. The following options are available.

Source

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

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

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.

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 4i Edge X and can not be disabled, because they are necessary for the services to work properly.

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 Sustem 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.
OpenVPN user. Select for which OpenVPN clients the rule will be valid.
L2TP user. Select for which L2TP clients the rule will be valid.
Network/IP/Range. The network address, IP address or IP range to which the rule can be applied.

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:

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.
OpenVPN User. choose one OpenVPN user as the destination target for the traffic.
L2TP User. select one L2TP user as the destination target for the traffic.
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
```
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.

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

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.

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 4i Edge X 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.

The 4i Edge X is behind a NAT device.

In this case there is a device like a router or another firewall between the 4i Edge X 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 4i Edge X, 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 4i Edge X. 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 4i Edge X 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.

Source NAT ¶

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.

Current rules

Source NAT can be useful if a server behind the 4i Edge X 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

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

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: 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; No NAT gives no other otpions, and Map netork allows to choose a subnet to which to map the incoming connections. The `Auto entries will automatically choose the IP address corresponding to the outgoing interface.
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 4i Edge X 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 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 Menubar ‣ Network ‣ Interfaces section, add a static Ethernet uplink with IP 123.123.123.123 to the 4i Edge X.
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.

Incoming routed traffic ¶

This page allows to redirect traffic that has been routed through the 4i Edge X. 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. New rules can be defined by clicking on the Add new rule button and configuring the following options.

Source

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

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 4i Edge X.
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

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.

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 4i Edge X is configured as follows:

Uplink (RED)

1.1.2/30 - Endian Uplink ip
1.1.1/30 - ISP router (default gateway for Endian)

1.1.0/30 - Network address
1.1.3 - Broadcast address

The 4i Edge X 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 4i Edge X).
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 4i Edge X.

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

However, the 4i Edge X 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 4i Edge X 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 4i Edge X itself and to the services that run on it; it is organised in three boxes: Settings, Current rules, and System Rules.

Settings

Log packages: All packets that access or try to access the 4i Edge X 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:

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.

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

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.

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 4i Edge X 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:

168.0.15/28
168.0.230
168.0.240-192.168.0.248

Hint

Write one IP, IP range or subnet per line.

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