The Services Menu¶

In this page you find:

The UTM includes many useful services to prevent threats and to monitor the networks and the running daemons, whose activation and set up is explained in this section. In particular, among them, we highlight the various proxy services, such as the antivirus engine, as well as the intrusion detection system, high availability, and traffic monitoring. The available services appear as items in the sub-menu list on the left-hand side of the screen.

DHCP server - DHCP server for automatic IP assignment.
Dynamic DNS - Client for dynamic DNS providers such as DynDNS (for home / small office use).
Antivirus Engine - configure the antivirus engine used by the e-mail, web, pop, and FTP proxies.
Time server - enable and configure the NTP time server, set the time zone, or update the time manually.
Mail Quarantine - manage quarantined emails.
Spam Training - configure training for the spam filter used by the mail proxies.
Intrusion Prevention - configure snort, the IPS.
High availability - configure the UTM in a high availability setup.
Traffic Monitoring - enable or disable traffic monitoring with ntop.
SNMP Server - enable or disable support for the Simple Network Management Protocol.
Quality of Service - IP traffic prioritisation.

DHCP server ¶

The DHCP server is used by the clients (both workstations and servers) in the zones controlled by the UTM to receive an IP address (called lease), either dynamic or a fixed lease, and communicate with other local and remote devices.

The DHCP server configuration consists of three pages, namely Server configuration, Fixed leases, and Dynamic leases.

Server configuration ¶

The DHCP server on an UTM can be enabled on each active zone independently. For each of the zones enabled on the UTM, this page show one checkbox, hence at least the Enable DHCP server on GREEN interface option appears. There are corresponding checkboxes for the ORANGE and BLUE zone if they are activated.

At the bottom of the page, there is a textfield, labelled Custom configuration lines, that can be used by advanced users to write custom configuration lines to be added to the dhcpd.conf file (e.g., custom routes to subnets), like this example shows.

Warning

The custom configuration lines must adhere to the syntax of the /etc/dhcpd.conf file–check the manual page dhcpd.conf (5) or see it online at https://linux.die.net/man/5/dhcpd.conf, since they are not checked for errors and are inserted verbatim in the configuration file. Any typo or mistake might prevent the DHCP server from starting correctly!

To customise the DHCP parameter for each zone, tick the respective checkbox. A panel labelled Settings will appear: click on it to show the available options.

Settings

Mode: In this dropdown you can select whether you wish to configure the selected zone as a DHCP Server or Relay

DHCP Server ¶

Start address, End address: The range of IP addresses to be supplied to the clients. These addresses have to be within the subnet that has been assigned to the corresponding zone. If these two fields are left blank, the whole IP range of the zone will be used to assign dynamic leases.

Hint

If some hosts should receive a fixed lease, (see below), make sure their IP addresses are included neither in this range nor in the range of the OpenVPN address pool (see Menubar ‣ VPN ‣ OpenVPN server) to avoid conflicts.
Allow only fixed leases: Tick this checkbox to use fixed leases only. No dynamic lease will be assigned.
Treat infinite leases as reserved: Tick this checkbox and the server will automatically reserve leases allocated to clients which requested an infinite lease-time.
Default lease time, Max lease time: The default and the maximum time in minutes before the assignment of each lease expires and the client requests a new lease from the DHCP server.
Domain name suffix: The default domain name suffix that is passed to the clients and that will be used for local domain searches.
Default Gateway: The default gateway that the clients in the zone will used. If left blank, the default gateway is the UTM itself.
Primary DNS, Secondary DNS: The DNS used by the clients. Since the UTM contains a caching DNS server, the default value is the firewall’s own IP address in the respective zone, though a second server or even the primary value can be changed.

Primary NTP server, Secondary NTP server: The NTP servers used by the clients, to keep the clocks synchronised. Leave blank to use the UTM's default NTP server.
Primary WINS server address, Secondary WINS server address: The WINS servers used by the clients. This option is only needed for the Microsoft Windows networks that use WINS.

Once done, click on the Save button at the bottom of the page, then on the Apply button in the green callout that will appear to restart the DHCPD server with the new configuration.

DHCP Relay ¶

Relay server zone: Here you can select the zone which you wish to configure as a DHCP relay.
Relay address: Enter the IP address to relay (forward) the DHCP requests received on the configured zone.
Append agent option fields: Append an agent option field to each request before forwarding it to the server. Agent option fields in responses sent from servers to clients will be stripped before forwarding such responses back to the client.

Fixed leases ¶

It is sometimes necessary or desirable for certain devices to always use the same IP address while still using DHCP, for example servers that provide a service (like, e.g., a VPN server or a code repository) or devices like printers or scanners.

A fixed lease is also called Static IP Address, since a device will always receive the same IP address when requesting a lease from the DHCP server.

This page contains the list of all the fixed leases defined in the local networks, providing several information about that lease: The device’s MAC Address and the assigned IP address, a remark, and the available actions.

By clicking on the Add a fixed lease button, a static IP address can be assigned to a device. The devices are identified by their MAC addresses.

Note

Assigning a fixed lease from the DHCP server is very different from setting up the IP address manually on a (client) device. Indeed, in the latter case, the device will still contact the DHCP server to receive its address and to announce its presence on the network. When the IP address required by the device has already been assigned, however, a dynamic lease will be given to the device.

The following parameters can be set for fixed leases:

MAC address: The client’s MAC address.
IP address: The IP address that will always be assigned to the client.
Remark: An optional description of the device receiving the lease.

Advanced options

In this panel appear three additional options.

Next address: The address of the TFTP server. This and the next two options are useful only in a few cases (see below for an example).
Filename: The boot image file name. Option needed only for thin clients or network boot.
Root path: The path of the boot image file.
Enabled: If this checkbox is not ticked, the fixed lease will be stored but not written down to the file dhcpd.conf.

A use case for a fixed lease.

A use case that shows the usefulness of a fixed lease is the case of thin clients or disk-less workstations on the network that use PXE, i.e., boot the operating system from an image supplied by a networked tftp server. If the tftp server is hosted on the same server with the DHCP, the thin client receives both the lease and the image from the same server. More often, however, the tftp server is hosted on another server on the network, hence the client must be redirected to this server by the DHCP server, an operation that can be done easily adding a fixed lease on the DHCP server for the thin client, adding a next-address and the filename of the image to boot.

Note

All leases assigned by the DHCP server are stored by default in the /var/lib/dhcp/dhcpd.leases file. Although the DHCP daemon takes care of cleaning that file, it may happen that the file stores leases that have already been expired and are quite old. This is not a problem and does not interfere with the normal DHCP server working. A typical entry in that file is:

lease 192.168.58.157 {
starts 2 2019/06/11 13:00:21;
ends 5 2019/06/14 01:00:21;
binding state active;
next binding state free;
hardware ethernet 00:14:22:b1:09:9b;
}

Dynamic leases ¶

After the DHCP server has been activated, and at least one client has received a (dynamic) IP address, the table in this page will feature the list of the clients, with these additional information: assigned dynamic IP addresses, the MAC address of the connecting device and its hostname, the expiry date and time, and the status, which can be either expired or active.

Dynamic DNS ¶

A DNS server provides a service that allows to resolve the (numeric) IP address of a host, given its hostname, and vice-versa, and works perfectly for hosts with fixed IP address and hostname.

DDNS providers, like DynDNS or no-IP, offer a similar service when the IP addresses is dynamic, which is normally the case when using residential ADSL connections: Any domain name can be registered and associated to a server with a dynamic IP address, which communicates any IP address change to the DDNS provider. To be compatible and to integrate with the root DNS servers, each time IP address changes, the update must then be actively propagated from the DDNS provider.

The UTM includes a dynamic DNS client for 33 different providers and if enabled, it will automatically connect to the dynamic DNS provider to communicate the new IP address whenever it changes.

Note

If no dynamic DNS account has been set up, detailed instruction to register a new one, detailed online helps and howtos are available on the web site of the providers.

New accounts can be created by clicking on the Add provider link, providing the following parameters:

Enabled: Tick this checkbox to enable the account, which is the default.
Service: The drop-down menu shows the available DDNS providers.
Hostname and Domain: The hostname and domain as registered with the DDNS provider, for instance “example” and “myddns.org”
Username and Password: The credentials given from dynamic DNS provider to access the service.

Note

The dynamic DNS provider only resolves the domain name and not the associated services. If some service must be accessed from the Internet to the UTM or to some host behind the UTM, it is necessary to set up some port forwarding rules (see Menubar ‣ Firewall ‣ Port forwarding / NAT).

After making a change in the configuration, click on the Apply now button to apply the change to the appliance.

If necessary to remove a DDNS account, you can simply click on the trash icon on the right side of the corresponding entry.

Antispam Engine ¶

The antispam engines available on UTM are: Bitdefender and Basic (spamassassin). They can be used for the detection of SPAM email traffic passing through the SMTP/POP3 proxy services.

Global Settings ¶

The Global Settings tab contains a single drop-down menu, to choose which antispam engine to use.

Default antispam engine: Choose the antispam engine that will be used for all enabled mail proxy services (SMTP/POP3). The default and recommended selection is BitDefender Antispam for all appliances with active maintenance.

Note

For any appliance with expired maintenance, the BitDefender Antispam option will be removed and the only option will be Basic (spamassassin).

Bitdefender Settings ¶

This page includes configuration settings for the anti-spam engine. The following options can be configured:

Enable spamassassin shortcircuit: Check this box to skip spamassassin whenever BitDefender marks a message as spam.

In the SPAM tag level panel the following option can be configured. The valid values are between 1 and 10.

CONFIRMED: Every e-mail with a tag level above this value will be recognised as spam.

Antivirus Engine ¶

New in version 5.2: Bitdefender antivirus

The antivirus engines available on UTM are: Bitdefender and ClamAV. They can be used for the detection of viruses and malware within files and documents and in conjunction with the proxy services, to scan files (web pages, archives, spreadsheets, text documents and so on) that pass through the UTM.

Archive bomb and DoS.

Archive bombs are archives that use a number of tricks to overload an antivirus software to the point that they hog most of the resources of the device hosting it, an action called DoS attack. The result is that the device can not be operate anymore and it must be hard rebooted.

These tricks include: Small archives made of large files with repeated content that compress well (for example, a file of 1 GB size containing only zeros compresses down to just 1 MB using zip); multiple nested archives (i.e., zip files inside zip files); archives that contain a large number of empty files, and so forth. Decompressing archive files with any of those characteristic poses a serious challenge to the normal activities of a server or a workstation, since a lot of resources are needed (especially RAM and CPU) and taken away from users’ availability.

Global Settings ¶

The Global Settings tab contains several drop-down menus, to choose which antivirus to use for which service. It is indeed possible to use both antiviruses at the same time, but not for the same service

Default antivirus engine: Choose the antivirus that will be used by default for all services. The choice made in this drop-down menu will set accordingly the values of the other options. The default and recommended selection is BitDefender Antispam for all appliances with active maintenance.

Note

For any appliance with expired maintenance, the BitDefender Antivirus option will be removed and the only option will be ClamAV Antivirus.
Antivirus engine for HTTP | SMTP | POP: Choose from each of the three drop-down menus the antivirus for each proxy service individually.

Note

This option is available only on software, virtual, and appliances bigger than the Mercury 100 included. For all other appliances, the same antivirus engine will be used for all services.

Bitdefender Settings ¶

New in version 5.2.5: Options Scan Archives, Scan Email and Email databases, and Scan Packed Executables.

These options are available for the Bitdefender Antivirus:

Update cycle: Select from the drop-down menu how often the signatures should be downloaded. Available options are hourly, daily, weekly, and monthly.
Clean infected files: By ticking the checkbox, infected files will be automatically cleaned.
Scan Archives: With this options enabled, also compressed archives will be scanned by Bitdefender.
Scan Email and Email databases: By ticking the checkbox, Bitdefender will check Emails and Email databases, like for example those used by popular email clients, including Outlook and Thunderbird.
Scan Packed Executables: When this option is ticked, executable that are delivered within packed files will be scanned.

Note

When updating from the 5.1 to the 5.2 version, Bitdefender will be automatically set as default antivirus.

Webfilter Engine ¶

The web filtering engines available on UTM are: Bitdefender and Basic. The web filtering engine selected contains the URL and domain database of websites that match a given criteria. These are typically broken down into major categories with sub-categories inside each.

Global Settings ¶

The Global Settings tab contains a single drop-down menu, to choose which webfilter engine to use.

Default Webfilter engine: Choose the webfilter engine that will be used for all enabled web proxy services (HTTP/HTTPS). The default and recommended selection is BitDefender for all appliances with active maintenance.

Note

For any appliance with expired maintenance, the BitDefender option will be removed and the only option will be Basic.

Time server ¶

The UTM uses NTP to keep its system time synchronised with time servers on the Internet. There is only one settings, displayed in the Network time server panel.

Network time server

A number of time server hosts on the Internet are preconfigured and used by the system, along with the time zone. Available options are the following.

Override default NTP servers: Tick the checkbox to replace the default NTP servers. This might prove necessary when running a setup that does not allow the UTM to reach the Internet. Several time servers addresses can be supplied, one per line, in the small form that will show up; each of them will be written in the configuration file, as value of the server option. For better performance, at least two time server should be provided here.

Hint

Each custom time server can be written as a hostname or IP address. Entries can be also vendor-specific, like e.g., 0.endian.pool.ntp.org.

Note

If for some reasons the UTM's clock is not synchronised anymore with the NTP servers and the difference between them is high, there is the chance that a manual synchronisation be necessary. This can be done either by clicking on the Synchronize now button, or in the Localization options, under the System Settings (System ‣ Settings ‣ Localization), by manually entering the correct time and date.

IDS/IPS ¶

The UTM includes the well known Intrusion Detection (IDS) and Prevention (IPS) system snort, which can identify advanced threats using deep-packet inspection technology to analyze network packets.

Settings ¶

If snort is not active, a grey switch Disabled appears on the page and can be clicked on to start the service. After a short interval, the page will contain some options to configure the service.

Intrusion Prevention System settings

This panel allows to define the automatic download and installation of the snort rules.

Operation mode

Here you can toggle the operating mode between IDS mode or IPS mode.

IDS. In this mode, the UTM will inspect traffic in passive mode in order to maximize throughput and minimize traffic disruptions. When this option is selected, you will see the following option:

Zones where IDS will be enabled
Here you can select the internal network zones which are enabled and active within the UTM for which you want to activate the IDS inspection

IPS. In this mode, the UTM will inspect traffic inline in order to provide maximum security at the expense of decreased throughput. This mode provides the capability to instantly block traffic for any IPS enabled signatures. When using this mode, a user must enable IPS inspection within the various components of the firewall for each rule required.

Automatically fetch SNORT Rules: Ticking this box will let the UTM automatically download the snort rules from the Endian Network.

Note

If the UTM is not registered, or its maintenance has expired, rules are not downloaded anymore. An informative message is also shown at the bottom of the page.

SNORT rules update schedule
The frequency of download of the rules: A drop-down menu allows to choose one of the Hourly, Daily, Weekly, or Monthly options. This option appears only if the previous option has been activated.

Rules last updated: An informative message about the last time rules have been manually downloaded, like for example: 2019-08-01 10:48:31
Update rules now: By clicking on this button, the signatures for the IPS service will be immediately downloaded from the emeringthreats.net web site.
SNORT rules: Pick one file from the file selection window that opens upon clicking the button next to this label.
Upload custom rules: Click on this button to upload the file and use it with snort.

Rules ¶

The list of rulesets that are stored on the UTM appears in this page, along with the number of rules they contain and the actions that can be done on them.

It is possible to edit each ruleset independently, by clicking on the icon in the rightmost column, Actions, but when at least one ruleset is selected, atop the table a few buttons will appear, allowing to carry out bulk actions on all the selected rulesets at once. On the right-hand side of the button, a number in a green circle shows how many rulesets are currently selected: Click on it to select all (including those in other pages) or none of the datasets.

The rule policies in snort.

By default, the policy for all the rulesets is set to alert, shown by the passlog icon. This means that whenever a flow of traffic will match the corresponding rule or ruleset, the traffic will be allowed to pass and the intrusion attempt will be logged.

This behaviour can be changed by clicking on the alert icon to toggle the policy into block, shown by the icon blocklog , with the result that the intrusion attempt will be blocked, but no message will be recorded in the log files.

After a policy of a rule or of a whole ruleset has been changed, it is necessary to click on the Apply button, for the changes to be applied.

After clicking on the Edit button, the list of the rules included in the selected ruleset(s) is shown, which can be narrowed down by entering some terms in the text box next to the Search label. To go back to the previous page, click on the Back to rules link on the top left corner of the table.

Warning

Turning on the IPS only implies that snort is running, but not that it is already used to filter the traffic. Indeed, the IPS is used only on those firewall rules, defined in the various Firewall configuration pages, that are configured with the Allow with IPS Filter policy .

SNMP Server ¶

The SNMP is used to monitor network-attached devices, and can be used e.g., to control the status of the internal infrastructure.

To enable the SNMP Server is sufficient to click on the Disabled grey switch. Once done so, a few options will appear in the Settings panel.

Settings

Community String: A key that is needed to read the data with an SNMP client.
Location: An identification string that can be set to anything, but it is suggested that it describe the location of the UTM.

Override global notification email address: The SNMP Server requires to configure an e-mail address as the system contact, and the global e-mail address provided during the installation procedure is used by default. In order to use a custom e-mail address, tick the checkbox to activate the next option.

System contact email address
Write the e-mail address of the administrator to be contacted.

Quarantine ¶

The mail quarantine is a special place on the UTM hard disk where all the e-mails that the SMTP proxy recognises as containing spam, malware, viruses, or with suspicious attachments are stored instead of being delivered. Here, those e-mails can be safely analysed and actions can be taken to manage them. To activate the mail quarantine, go to Menubar ‣ Proxy ‣ SMTP ‣ Configuration and in the SPAM settings, Virus Settings, and File settings boxes, choose the option move to default quarantine location from the drop down menus.

E-mails that land in the Mail Quarantine will remain in a special folder on the UTM until the Quarantine retention time has been reached (see SMTP settings in the SMTP Proxy module). However, when there are many quarantined e-mail stored on disk, the quarantine folder might be filled up and it becomes necessary to manually delete quarantined e-mails.

The space dedicated to the mail quarantine depends on several factors, like e.g., the type of appliance, the size of the quarantined e-mails -especially if they have large attachment, other active services, and so on.

The Mail quarantine is organised in two tabs: Quarantine and Summary Reports. The former contains a list of the e-mail stored in the quarantine and allows to browse and manage them, while the latter allows to generate periodical reports about the quarantine’s content and manage their dispatch.

Quarantine ¶

The mail quarantine page contains a table with the list of all mail moved to the quarantine, above which there is a navigation bar to browse the e-mails.

The table contains the following information about the mail saved in the quarantine.

Select: A checkbox that allows to select one or more messages at a time and carry out an action on all of them.
Quarantine Date: The date and time when the e-mail was moved in the quarantine.
Reason: The reason for which the e-mail was not delivered, which can be one of Malware - the e-mail contains viruses or other types of threats, Spam - the e-mail has been marked as spam, Banned - the e-mail has an attachment that can not be sent, and Bad Header - the information contained in the header are not valid.
From: The sender of the e-mail.
To: The recipient to which the e-mail was originally sent.
Subject: The subject of the e-mail.
Size: The size of the e-mail.
Attachment: The number of the attachments to the e-mail.
Actions: The actions that can be done on each e-mail.

Below the table, a drop-down menu labelled Choose an action will allow to release or delete all the emails or only the selected ones.

When clicking on the view message icon, the list of emails is replaced with a 3-boxed page, showing various details about the selected e-mail.

Quarantined Email ¶

This box presents a more detailed view of the e-mail’s data reported in the e-mail list: The reason why the e-mail ended in the quarantine, the sender and recipients, along with carbon copy (CC) addressee, subject, date and time of receiving, and the e-mail’s size.

Headers ¶

The full header of the original e-mail, which can give useful information, among which for example the path followed by the e-mail.

Content ¶

If the email has one or more attachments, they are shown here along with their details. Moreover, every HTML attachment is shown with its full source code.

At the bottom, there is an option available:

Delete from Quarantine after release: The e-mail will be removed from the quarantine after its release to the original recipient.

Summary Reports ¶

Periodical reports about quarantined e-mails can automatically be sent to inform the original recipient of the e-mail. In this page it is possible to activate and manage the frequency and settings of this service.

Note

This functionality requires that the SMTP Proxy be correctly set up and running, otherwise it would not send any reports.

Alternatives to notify recipients of quarantined e-mails.

There are two approaches to notify users that they received one or more e-mails that ended in the quarantine:

Selecting a whole incoming domain. In this case, all users in that domain will be notified, unless they are in an appropriate list. Incoming domains can be configured in the SMTP Proxy module (Menubar ‣ Proxy ‣ SMTP ‣ Incoming domains). See option Do not send summary report emails to these addresses below.
By explicitly listing users that shall receive notifications. See option Send summary report emails to these addresses below.

These two approaches are not exclusive: It is allowed to employ both of them.

Moreover, there is also the possibility to supply a list of sender addresses whose e-mail will never be part of any summary report.

Finally, wildcards and regular expressions can be used to avoid the necessity to write a long list of addresses.

Warning

Make sure to not misuse wildcards! In particular, writing a single asterisk * on a line will send an email notification to every user in every domain managed by the UTM.

The summary reports service is not enable by default. To start it, click on the grey switch Disabled labelled Enable Summary Reports Emails. It will turn green and a number of configuration options appear.

Use default sender email address: By ticking the checkbox, the default address will appear as the sender of the report.

Note

The default e-mail address is the one specified during the network configuration, see step 6 of the Network configuration.
Email sender address: A custom sender address can be specified here, provided that the previous option is not ticked.
Summary report email schedule: The report can be sent Daily, Weekly, or Monthly.

Note

If the value of option Quarantine retention time in Menubar ‣ Proxy ‣ SMTP ‣ Configuration ‣ Quarantine settings is lower than 30 (days), the Monthly option will not be available.
Emails to include: Two options are available in this drop-down menu. Select Emails received after last report to include only newer quarantined e-mails (i.e., those that arrived after the last report was sent), or All emails in the quarantine to send a bulk of all the quarantine content.
Choose mail template language: The language used to write the summary report, chosen by the available values English, German, Italian, and Japanese.
Contact data to include in the email: This form can be used to include a custom message in the report.

Hint

For example, include an e-mail address that the user can contact to ask for information or release the quarantined e-mail.
Summary report email content: This multiselect box allows to chose which data to include in the summary report for each quarantined e-mail. By default, only the sender, the reason for being in quarantine, the subject, and the date are included, but also the recipient address, information about the attachment, and the size can be included.
Incoming domains: This multiselect box allows to choose which domains shall be monitored for dangerous e-mails and send them to the quarantine. When users in one of these domains receive a mail that ends in the quarantine, they will be notified with an email

Hint

To add a new domain to this box, add it in Menubar ‣ Proxy ‣ SMTP ‣ Incoming domains.
Send summary report emails to these addresses: The list of recipients that will always receive the summary reports, one per line.

Warning

Make sure to not misuse wildcards! In particular, writing a single asterisk * on a line will send an email notification to every user in every domain managed by the UTM!

Do not send summary report emails to these addresses: A list of e-mail addresses, one per line, of an incoming domain that will never receive summary reports.
Do not include emails from these sender addresses: A list of sender whose e-mails will never be included in the summary reports, one per line.

Quality of Service ¶

The purpose of the QoS module is to prioritise the IP traffic that is flowing through the UTM depending on the service. In other words, the QoS is a convenient way to reserve a given amount of the available bandwidth (both incoming and outgoing) for a given service. Applications that typically need to be prioritised over bulk traffic are interactive services such as SSH or VoIP.

The QoS configuration options are arranged into four tabs: Devices, Classes, Rules and Tagging.

Devices ¶

The Device tab is also the starting page for the QoS and is initially empty. Once populated, a table showing a list of all the Quality of Service devices appears and for each device, some parameters and the available actions are displayed.

New QoS devices can be added by clicking on the Add Quality of Service Device link above the list and by configuring a few options.

Target Device: The network interface that will be used by this device. Choices are among the existent network interfaces, the zones enabled on the system, the uplinks, and the OpenVPN tunnels if defined, and can be selected from a drop-down menu.
Downstream Bandwidth (kbit/s): The downstream speed of the interface.
Upstream Bandwidth (kbit/s): The upstream speed of the interface.
Enabled: Enable the QoS (default) or not.

When editing a device, the same form opens as when adding a new device, in which to modify the current device’s parameters.

For every device added, four items will appear under the Classes tab: Three for high, medium, and low priority, respectively, and one for bulk traffic (see below).

Classes ¶

This tab shows a list of all Quality of Service classes that have been created, if any. For each entry, several data are shown. New items can be added by clicking on the Add Quality of Service Class link above the list of classes. The parameters to configure are the same shown in the list:

Name: The name of the Quality of Service class.
QOS Device: The drop down menu allows to choose the Quality of Service device for which the class was created.

Hint

At least one QoS device must have been created before defining a QoS class.
Reserved: The amount of bandwidth that has been reserved for this class from the device’s overall available bandwidth, either in percentage or in kilobit per second.
Limit: The maximum amount of bandwidth this class may use, either in percentage or in kilobit per second.
Priority: The priority of the class, from 0 (low) to 10 (high), selected from a dropdown menu

Note

The sum of reserved percentages can not be greater than 100 per device. Moreover, the reserved bandwidth can not be higher than the limit bandwidth.

Classes can be moved up or down the list: Items closer to the top of the list are the first to be processed when the bandwidth does not suffice for all the traffic and the UTM needs to choose which traffic should be prioritised.

Rules ¶

The third tab displays a list of the already defined Quality of Service Rules and allows to specify which type of traffic should belong to each of the classes. To add a new Quality of Service rule click on the Add Quality of Service Rule link. In the form that will open, which is very similar to the one used to define firewall rules, several values should be configured. Many drop-down menus are employed here to ease the choices and guide through the configuration.

Hint

To define rules that resemble those involving IPsec users in the 2.5.X version, it is necessary to specify the following values for the two options:

Source: The zone to which the IPsec user was bridged.
Destination Network/IP: the remote subnet behind the IPsec user.

Source: Choose from the drop-down menu the traffic source, either a Zone or interface, a network, an IP or MAC address. Depending on this choice, different values can be specified: A zone or interface from the available ones from those that will be displayed, or one or more IP addresses, networks, or MAC addresses.
Destination Device/Traffic Class: Choose the destination device or traffic class from the drop-down menu.
Destination Network/IP: Write in the text area the target network or IP addresses, which must be reachable from the device or traffic class chosen in the previous option.
Service/Port, Protocol: These two drop-down menus are used to define the service, protocol, and destination port for the rule (when choosing one of TCP, UDP, or TCP + UDP protocols). Some predefined combinations Service/Protocol/Port exists, like HTTP/TCP/80, <ALL>/TCP+UDP/0:65535, or <ANY>, which is a shortcut for all services, protocols, and ports. Finally, in the Destination port, one or more custom port number can be supplied (this proves useful when some service does not run on a standard port).
Type: Choose from the drop-down menu which tag to use to mark the traffic: a TOS flag, a DSCP class or a DSCP value. Depending on the choice, one of the following options will appear, unless <ANY> is chosen.
Match Traffic with the following TOS [DSCP] flag: By choosing TOS or DSCP class in the previous drop-down menu allows to choose a suitable value for the traffic to match from another drop-down menu.
DSCP Value: This filed appears only when DSCP value is chosen in the Type option above. It allows to enter a custom value for DSCP, that will be used to fire the rule when matched.
Enabled: Tick the checkbox to enable the rule.
Comment: A comment to identify the rule.

Note

If there is more than one service in a Quality of Service class, then all these services together will share the reserved bandwidth.

Tagging ¶

The fourth tab is different from the others as it is used to classify and prioritise traffic. In other words, the traffic can be marked or tagged to allow external devices to handle it accordingly. This is particularly useful in a scenario with limited bandwidth and the uplink device, e.g., a modem, can only prioritise traffic based on TOS or DSCP flags in the packets. When clicking on the Add Quality of Service Rule link the editor opens, which is similar to the one under the Rules tab. These are the available options:

Source: Choose from the drop-down menu the traffic source, either a Zone or interface, a network or an IP, or a MAC address. Depending on this choice, different values can be specified: A zone or interface from the available ones from those that will be displayed, or one or more IP addresses, networks, or MAC addresses. The default value is <ANY>, meaning the rule will be applied to all traffic.
Destination: Choose from the drop-down menu the traffic destination, either a Zone or interface, a network or an IP. Depending on this choice, different values can be specified: A zone or interface from the available ones from those that will be displayed, or one or more IP addresses or networks.
Service/Port, Protocol: These two drop-down menus are used to choose the service, protocol, and destination port for the rule (when choosing one of TCP, UDP, or TCP + UDP protocols). Some predefined combinations Service/Protocol/Port exists, like HTTP/TCP/80, <ALL>/TCP+UDP/0:65535, or <ANY>, which is a shortcut for all services, protocols, and ports.
Destination port: In this textfield one or more custom port numbers can be supplied; this proves useful when some service does not run on a standard port).
Type: Choose from the drop-down menu which tag to use to mark the traffic: a TOS flag, a DSCP class or a DSCP value. Depending on the choice, one of the following three options will appear.
Tag traffic with the following TOS flag: This dropdown appears only when TOS is chosen in the Type option above. It allows to define the TOS flag that will be set in all matching packets.
Tag traffic with the following DSCP class: This dropdown appears when choosing DSCP Class in the Type option above. It allows to define the DSCP class that will be set in all matching packets.
Tag traffic with the following DSCP value: This field appears only when DSCP value is chosen in the Type option above. It allows to enter a custom value for DSCP, that will be set in all matching packets.
Enabled: Tick the checkbox to enable the rule.
Comment: A comment to identify the rule.

High Availability ¶

Changed in version 6.0: Complete reimplementation of HA.

The HA system on UTM was completely rewritten in 6.0 version; this implementation presents several improvements compared to the HA installed on previous versions. Technical details and a summary of differences and improvements are described in the dedicated box below.

Requirements ¶

In order to set up a HA cluster, it is necessary that all the nodes in the cluster are the same platform, hardware or software, and are equipped with the same software Minor Version. For example, if the cluster is created on a 6.0.3 Switchboard virtual, additional nodes can be added only if they are Switchboard virtual with version 6.0.3 installed.

Hint

To make sure that the nodes also have the same packages installed, carry out an update of both appliances before creating the cluster.

HA implementation in 6.0

Recap: HA in 5.0

In 5.2 and previous versions, whenever the master had a hardware or connectivity problem, the slave immediately took over all the duties and assumed the role of master, until the original master would again become available and regain its role. This approach however had some limits, that the new HA overcomes:

the Slave could only temporary take over the Master duties, hence there was a downtime each time a transitions took place
data synchronisation was one-directional, from the Master to the Slave only
therefore, no change in configuration was possible during the Master unavailability, as the Slave had no means to send any change in configuration to the Master when it came back online

HA in 6.0

The underlying technology of HA is still composed of keepealived, the VRRP protocol, and the management network, which defaults at 192.168.177.1/24, and is used to keep nodes synchronised.

In the 6.0, the most significant and visible changes are:

there are no Master and Slave nodes, but there is a Master role that can be played by one node at a time and a Slave role, that can be played by one or two nodes
all nodes in the HA cluster are kept synchronised
there is no takeover by the original master to get its status back, but it joins cluster as a secondary (slave) node
all configuration, including join and removal of nodes, are executed on the Master node

The immediate consequence is that if the node playing the master goes offline, the slave node will immediately become Master, but it keeps its Master status, unless it goes offline, and when the ‘original’ Master becomes again available, it joins the cluster as Slave and starts synchronising. This also means that it is possible to change configuration at any time, since the Master is always online. Moreover, the Slave node can not be reached anymore, except by using the serial console.

Downtime and possible data and configuration losses are also minimised, as only a small fraction of time is needed for the take over of the slave, and the only case where significant downtime can happen is when both nodes experience problems.

Three nodes HA cluster

Downtime can be virtually eliminated when in the cluster a third node is added, which is now supported. In such a scenario, the concept of priority is introduced and associated to each node (default values are 90 for the active, 50 and 10 for the passive nodes). When the active node leaves the cluster, the node with the higher priority becomes the master. When the node rejoins the cluster, all nodes are checked for their synchronisation status with the current Master and, if they are, they receive a “bonus” that raises their priority. In this scenario, downtime and data loss can take place only in case two nodes are offline and the third is out of sync.

Node Removal and Deletion of a HA Cluster

At any time a secondary node can be removed from the cluster, by simply deleting it from the GUI; the active node can be removed only if it is the last node in the cluster.

Warning

Whenever a node is removed from the cluster, the cluster’s configuration on the node will be deleted and the appliance is restored to factory settings.

When a cluster has not yet been created, the following options are available.

Hint

To accept the default values supplied, simply click on the Create HA Cluster button.

Network address: Write in this textbox the Network address used for HA management.
Network mask: Select the network mask from the drop-down menu.
Network interface: Choose the interface that will serve for the HA management network.

After the cluster has been created, a few boxes appear towards the bottom of the page: one for each node of the cluster, which contain information about the nodes that compose the cluster:

The progressive number of the node (up to three)
The node’s IP address. The node on which the cluster is created will always end with the IP address .1, while each added node will have an incremental IP address.
The status: healthy and online means the node is reachable and synchronised
Role: Master or Slave
Version of the software

An additional box allows to add a node to the cluster. The following data are required:

Node IP: The IP address of the new node.
SSH password: The SSH password of the new node’s root user.

A few moments after the join process is started, a message on top of the page either confirms that the operation was successful, or explains what was gone wrong.

It is also possible to remove one slave node at the time from the cluster, by clicking on the Remove button.

Hint

The Master can be removed only if it is the last node in the cluster.

A dialog window will open to ask for confirmation and to present one more option:

Advanced options

Remove node even if not reachable: Force removal of the node even if it can not currently be reached.

Warning

It is suggested to not remove an unreachable node, because its removal process only remove it from the cluster, but not wipe its configuration. Therefore, as soon as it comes back online it starts contacting the other nodes, and this might lead to the HA cluster disruption.

Remember that a node removed from the cluster will be restored to factory defaults.