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
Docker traffic
- Incoming
- Outgoing
Firewall Diagrams

This section allows to set up rules that specify if and how the network traffic flows through the Connect Switchboard. The firewall on the Connect Switchboard 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 Connect Switchboard 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

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

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

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

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 Connect Switchboard 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 Connect Switchboard 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 Connect Switchboard 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

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

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

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

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 ¶

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.

Restrict on time and day

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.

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 Connect Switchboard 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 Connect Switchboard is behind a NAT device.

In this case there is a device like a router or another firewall between the Connect Switchboard 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 Connect Switchboard, 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 Connect Switchboard. 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 Connect Switchboard 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. This page contains two boxes, Current Rules and System rules.

Current rules

Source NAT can be useful if a server behind the Connect Switchboard 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

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 Connect Switchboard 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:

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

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 Connect Switchboard 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 Connect Switchboard 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 Connect Switchboard).
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 Connect Switchboard.

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

However, the Connect Switchboard 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 Connect Switchboard 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 Connect Switchboard 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 Connect Switchboard 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

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 Connect Switchboard 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 or routing rules. For example, a network object can be a set of 15 IPs which are the subject of a single 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 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.

New in version 6.6.4.

Type

A drop-down menu to allow the choice among two types of network objects:

Network/IP
Here you can enter IP addresses, IP ranges, or subnets in CIDR notation that 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.
FQDNs
Here you can enter one or more fully qualified domain names (FQDNs) to use as a network object. This can be especially useful to create policies which automatically track and adjust to changing IP addresses used for load-balancing and other similar technologies.

Keep old entries
This setting is useful for sites which use a pool of IP addresses for a given domain name and can return one or more IPs from the pool at random. By enabling this, the Connect Switchboard will retain previously recorded IPs for the specified duration. This is helps to greatly reduce the likelihood of the objects not being fully accurate. Once this box is checked, a new option appears to specify the duration (below).

Keep old entries for (seconds)
This setting provides the length of time the (in seconds) the Connect Switchboard will retain previous IP adddresses from a previous DNS resolution. The default value is 300 seconds (5 minutes).

The Connect Switchboard keeps track of the DNS TTLs for the FQDN entries and will automatically refresh the DNS entries based on these TTL values. This ensures that the objects are as accurate as possible and ensure the proper functioning of the firewall and routing rules.

Note

The FQDNs feature only supports domains and subdomains which support forward name resolution (A records). In addition, it is not recommended for use with second-level domains (e.g. example.com) as this usually will not provide the intended results. Last, this feature may not work for every site as there may be exceptions or unusual situations which are not covered.

Warning

The FQDNs feature relies on the DNS system and protocol which are not guaranteed to be accurate and/or secure. In the event a DNS server is compromised, your FQDN results could be inaccurate and potentially create a security risk to your network and users.

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 Connect Switchboard 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

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 Connect Switchboard 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

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.