Aller à :navigation, rechercher
Wiki

Cluster

De Securepoint Wiki





























In dieser Seite werden die Variablen für unterschiedliche Sprachen definiert.
Diese Seite wird auf folgenden Seiten eingebunden



























































































































































































| Some pictures and menu paths updated }}


| Configuration note for external interfaces added }}

| Layout adjustments }}











Securepoint Cluster Configuration - Best Practice

Last adaptation to the version: 14.2.0 (07.2026)

New:
  • Beta For participants on the Beta Channel only:
  • Applications section newly documented
  • Einige Bilder und Menüpfade aktualisiert
Last updated: 
    04.2026
  • Konfigurationshinweis für externe Schnittstellen ergänzt
  • Layoutanpassungen
notempty
This article refers to a Beta version

14.1.0 14.0 12.6 12.4 12.1 11.7

Access: UTM-IP:Port or UTM-URL:Port
Port as configured at Network / Appliance Settings / Webserver
Default-Port: 11115
i.e.: https://utm.ttt-point.de:11115
Default: https://192.168.175.1:11115 Network Cluster Configuration

notempty
Current software
The latest version of the software should always be installed.
Only the latest version contains the latest features, security enhancements and error corrections.


Fields of application

High availability of the UTM can be ensured by using the UTM in a hot standby cluster.
The UTMs within the cluster monitor each other and, if necessary, automatically switch to the device with the best status. Intervention by the administrator is not necessary.


Installation

When setting up the UTM cluster, two UTMs with identical firmware are connected via a Hotwire interface. The installation with the "Cluster Setup Wizard" is performed on the Original UTM, which will be the Primary in the newly created cluster. This UTM will be used to synchronize the configuration. On the Spare UTM, which will be the BACKUP in the cluster, the Hotwire interface is defined and an SSH key is generated during installation. The SSH key of the Primary is also entered on the spare UTM.
The active UTM in the cluster, has the higher priority and is called the Primary.
The UTM with the lower priority, the passive UTM, is the Spare.


Requirements

The following requirements are necessary for cluster operation:

  • One Cluster-Primary license
    One cluster Spare license

    To configure and operate the UTM cluster, a valid cluster license is required, which contains two different licenses and which can be applied for in the Securepoint Reseller Portal.

    End customers should contact their authorized Securepoint reseller.

  • The menu items for cluster configuration are visible as soon as a cluster license is installed.
    • Two identical appliances* with at least 3 Ethernet interfaces and the same firmware

      In the smallest scenario there is one input interface (internal LAN) and one output interface (external LAN) as well as the third free interface. This interface, also referred to as the Hotwire interface in the following, is required for configuration adjustment and connection tracking. It cannot take over any other network function.

    • The used switches and routers support gratuitous ARP

      If there is a Primary/Spare change in the UTM cluster, the now active UTM sends gratuitous ARP packets to its environment to announce the new MAC address.
      If the switches or routers do not support this function, they can only communicate via the active UTM with a delay.


    Functionality of the cluster

    Hover over the image for more details!
    Fig.: 1.1

    The cluster uses unique IP and MAC addresses for the two members of the cluster and virtual IP addresses for the cluster itself. The virtual IP addresses are only active on the active member of the UTM cluster. If the active member of the cluster fails completely or partially, the virtual IP addresses change to the second member of the cluster.
    For the clients and servers in a cluster configuration, the virtual IP address is the communication partner in the routing (e.g. the standard gateway, see Fig. 1.2).


    The Cluster VRR Protocol

    VRRP (Virtual Router Redundancy Protocol) is the communication protocol of the cluster. It is only active on interfaces that are configured as High-Availability interfaces. The Primary of the UTM cluster sends data packets to the spare via this protocol. If the spare does not receive any data packets, it upgrades itself to the primary.

    Using tcpdump the protocol can be made visible on a HA interface (see figure)

    No special firewall rules are required to enable communication with the VRR protocol.

    Switching the cluster

    The following states or events trigger a switchover within the cluster:

    • The active member of a cluster is restarted or shut down completely.
    • One or more HA interfaces no longer have a physical link.
    • The link of an HA interface is active, but due to a defective or incorrectly configured switch, the VRRP packets do not arrive at the cluster partner.
    • The cluster function is deactivated on the active cluster partner by the administrator.

    If more than two HA interfaces are activated, it is possible that a different number of HA interfaces may no longer be able to communicate in the event of an error. In this case, the UTM on which most interfaces have a link will become the active member as long as the UTMs still see each other via at least one HA interface. If the UTMs no longer see each other on any interface, both assume that the second member of the cluster no longer exists and both become the primary.
    Table, behavior in the cluster, example two HA interfaces:

    HA interfaces 1 HA interfaces 2 UTM 1 Status UTM 2 Status
    UTM 1 UP
    , UTM 2 UP    		 UTM 1 UP
    , UTM 2 UP
    Active
    Passive
    UTM 1 DOWN
    , UTM 2 UP    		 UTM 1 UP
    , UTM 2 UP
    Passive
    Active
    UTM 1 DOWN
    , UTM 2 DOWN    		 UTM 1 UP
    , UTM 2 UP
    Active
    Passive
    UTM 1 DOWN
    , UTM 2 DOWN    		 UTM 1 UP
    , UTM 2 DOWN
    Active
    Active
    UTM 1 DOWN
    , UTM 2 DOWN    		 UTM 1 DOWN
    , UTM 2 DOWN
    Active
    Active

    Please note that UTM-1 has a higher priority than UTM-2. If the state in the table is active and marked as red, this means that the two members of the cluster no longer see each other and assume that the respective other partner is no longer present. Both members of the cluster are then active. However, network communication is then generally no longer possible because the problem is in the environment.


    Fallback in a cluster
  • If a fallback is configured at the same time and a failed ping check triggers the switch to the Spare and this also registers a failed ping check, it will return the primary to the original Primary.
    Here now the priority decides, because both machines are equally affected and the fallback of the Primary becomes active.

    • notempty
    When setting up a fallback in a cluster, it is essential to ensure that, in addition to the HA IP addresses, static IP addresses are also configured on an HA interface.
    • The fallback interface also requires a static IP address.
    • With PPPoE, the fallback interface cannot be configured as an HA interface.

    If fixed IP addresses are missing, this can lead to malfunctions during the ping check.

    Configuration example for external interfaces
    hide
    Klicken für dauerhafte Anzeige
    If A0 is used as the main line and A4 as the fallback line, both interfaces (if they are HA interfaces) must have both HA IP addresses and fixed IP addresses.

    Hotwire interface:

    Fig.: 1.3

    The Hotwire interface is an exclusive interface that is only used to synchronize the configuration of the cluster members and to synchronize the running connections (connection tracking). This interface has this task exclusively. When selecting the appliances, it must be ensured that one interface is free for the Hotwire network in each case.
    The SSH protocol (TCP/22) is used to synchronize the configuration. The connection tracking is synchronized via port 3780 (UDP). If an Ethernet interface is marked as Hotwire, the rules for communication are generated automatically. For the SSH connection, public keys must be exchanged between the members of the UTM cluster. The configuration can be synchronized in both directions between the members of the cluster. The connection tracking is always automatically transferred from the primary in the cluster to the backup (Fig. 1.3).

    notempty
    It must be ensured that nobody is administratively using the member of the cluster to which the synchronization is to be made at the time.
    notempty
    hide
    Klicken für dauerhafte Anzeige
    -



    Adjusting the configuration

    The respective start configuration is synchronized via the hotwire interface. Changes made on one machine in the cluster are transferred to the other device via this interface. Usually, after the cluster has been commissioned, the configuration is carried out on a UTM alone. We recommend using the primary.

    notempty
    The adjustment is always performed manually. The administrator decides when to adjust the configuration in the UTM cluster.


    The following parts of the configuration are not adjusted:

    1. IP addresses that uniquely belong to a machine and are configured to Ethernet or VLAN interfaces.
      These are the IP addresses that are set in the web interface under the Network Network Configuration item. If an Ethernet or VLAN interface is newly created, this will be transmitted, but not the information about the IP addresses of these interfaces. If necessary, these must be configured manually on the cluster member, as they are always uniquely assigned to a UTM. These IP addresses are not to be confused with virtual IP addresses on an HA interface shared by both machines in the cluster.
    2. Active Directory appliance account.
      This account is always unique in AD. You create different names on both machines and log each one separately into Active Directory.
    Configuration example for internal interfaces
    hide
    Klicken für dauerhafte Anzeige
    It is not absolutely necessary to configure unique IP addresses on interfaces on which an HA interface with virtual IP addresses is operated.
    However, if the member of the UTM cluster is to be uniquely identified via this interface, this is necessary.
    In this case, the virtual IP address is used to access the UTM that is the primary at that moment.


    Replacement unit configuration
  • If a device is defective and needs to be replaced, the configuration of exactly this machine must be restored on the new device.
    (e.g. the primary configuration must not be copied to the spare in order to change only the IP addresses).
    If neither a local nor a cloud backup of the configuration is available, the replacement unit can be integrated into the cluster with a new configuration.
    For this purpose, the setup steps as Spare must be carried out as described below: • Spare UTM with external modem • UTM_2 Spare UTM with external modem
  • The SSH keys must be copied both from the current active device vice versa to the respective counterpart
  • For a replacement unit, the priority must be set to High for Primary or to Low for Spare according to the future purpose.


    • Example configuration 1: External DSL modem

    This example shows a configuration with which a UTM cluster can be operated on a DSL modem. The dial-up is done directly by the UTM.


    Network configuration

    First member of the cluster (UTM 1, Primary)
    LAN1: External DSL connection using PPPoE.
    LAN2: Internal IP address: 192.168.175.1/24
    LAN3: Hotwire IP address:192.168.180.2/24

    Second member of the cluster (UTM 2, Spare)
    LAN1: External DSL connection using PPPoE.
    LAN2: Internal IP address:192.168.175.2/24
    LAN3: Hotwire IP address:192.168.180.3/24


    The virtual IP address is defined as 192.168.200.1/24.
    This IP address is the default gateway of the internal network.

    notempty
    When using the DHCP server, the virtual IP address must not be in the same network as the physical IP address of the interface.
    Otherwise the DHCP server would access the physical address of the spare UTM during the fallback and not synchronize the leases.


    Preparations

    Setting up the UTMs
    • To set up the UTM cluster, the installation wizard is used first
    • A (cluster) license is already required to log on to the UTM
    • To prevent double dial-up, the DSL modem should not be connected
    • Up to this point, the configuration of the two UTMs differs only in the internal and external IP address
    • After the wizard is completed, the UTMs are restarted


    IP addresses of the upcoming Hotwire interfaces
    Primary Network Network configuration LAN3 → IP addresses:
    IP addresses: »192.168.180.2/24 Primary In the clickbox the IP address of the upcoming Hotwire interface is added.
    In the example the Primary LAN3/A2 gets the IP address 192.168.180.2/24.     		Edit Ethernet interface UTMuser@firewall.name.fqdn Network Network configuration
    Hotwire IP of the Primary
    Spare Network Network configuration LAN3 → IP addresses:
    IP addresses: »192.168.180.3/24 Spare In the example LAN3/A2 the spare gets the IP address 192.168.180.3/24.


    Connect Hotwire interface

    The UTMs are now physically connected via the selected Hotwire interface. This must occupy the same port on the machines - Designation depending on the hardware and software used A2, eth2 or LAN3.< br>(Any other port may also be used, provided it is the same on both devices.)


    Cluster configuration UTMuser@firewall.name.fqdn Network Datei:UTM v14.2.0 Clusterkonfiguration mit DSL-Schnittstellen unkonfiguriert-en.png
    Example configuration 1: External DSL modem Cluster configuration Initial situation

    Cluster configuration

    • The UTMs have different priorities within the cluster.
    • The higher priority is given to the active device (Primary), the lower to the backup system Spare.
    • In our example, the UTM with the unique internal IP address 192.168.175.1 will be the primary.
    • Login via the web interface with this IP and the port for administration (Default: 11115).
    Cluster configuration
    Start the Cluster Setup Wizard at Primary Network Cluster configuration button Cluster Wizard
    Primary Cluster Wizard Step 1
    Primary Cluster Wizard Step 1
    • Start with the Primary configuration is started
    		 Cluster Wizard UTMprimary.firewall.fqdn Network Cluster configuration
    Step 1
    Primary Cluster Wizard Step 1
    Example UTM on external DSL modem

    Primary Cluster Wizard Step 2
    Primary Cluster Wizard Step 2
    Hotwire interface:: LAN3
  • The same interface must be selected on both devices!
    		•
    Step 2
    Primary Cluster Wizard Step 2
    Example UTM on external DSL modem
    Local IP‑address: 192.168.180.2/24 IP address of the primary UTM
    Remote IP‑address: 192.168.180.3/--- IP address of the Hotwire remote unit (spare UTM)

    Primary Cluster Wizard Step 3
    Primary Cluster Wizard Step 3
    HA interfaces: LAN2 The upcoming HA interface. In the example the internal interface.
    Step 3
    Primary Cluster Wizard Step 3
    Example UTM on external DSL modem
    Virtual IP‑addressesw: 192.168.200.1/24 The virtual IP address should be 192.168.200.1. There can also be several virtual IP addresses on one HA interface.
  • When using the UTM as a DHCP server, the virtual IP address must not be in the same Broadcast Domain as the primary and spare UTM.
    Otherwise the DHCP server would key itself to the physical address of the spare UTM during the fallback and not synchronize the leases.
  • After the wizard has run through, other HA interfaces can also be configured.

    •
    Primary Cluster Wizard Step 4
    Primary Cluster Wizard Step 4
    Interfaces: wan0 wg0 Interfaces that are not booted on the backup system, the spare UTM.
    In the example wan0 (the DSL interface). The dial-in should only be done by the currently active primary UTM in the cluster.
    This makes it possible to connect both external interfaces of the UTMs to the DSL modem. If the modem has only one LAN port, a separate switch must be used.
    WireGuard connections (in the example ‘'wg0’') are also deactivated in backup mode.
    Step 4
    Primary Cluster Wizard Step 4
    Example UTM on external DSL modem
    Applications: Clientless VPN DHCP Server Greylisting Filter HTTP Proxy IPSEC L2TP VPN Mailrelay POP3 Proxy Routing Server SPF Filter SSL-VPN Spamfilter WLAN ServerDefault Here applications are listed that should be disabled by default if the spare UTM is in backup mode.
    It may not be possible to use Wireguard in cluster operation if the spare has a path towards the Wireguard peer, e.g. via a public management IP. In this case, the wireguard tunnel to the peer is established and there is a tunnel between the spare and the wireguard peer. The following command must then be entered:
    interface set name wg0 flags "DISABLED_IF_SPARE" (if i.e. the interface is wg0)
    From UTM v12.4.0 this happens automatically, but for existing configurations this must be done retrospectively.

    Primary Cluster Wizard Step 5
    Primary Cluster Wizard Step 5
    Passphrase: insecure The passphrase for the communication between the two UTMs on the HA interfaces (VRR protocol)
    Step 5
    Primary Cluster Wizard Step 5
    Example UTM on external DSL modem

    Primary Cluster Wizard Step 6
    Primary Cluster Wizard Step 6
    Setting for the spare: [Primary]
    Hotwire Interface: LAN3
    Remote IP adress: 192.168.180.3
    ...    		 These configurations must be inserted when configuring the spare. To do this, they can be copied to the clipboard using the button.
    Step 6
    Primary Cluster Wizard Step 6
    Example UTM on external DSL modem

    Spare Cluster Wizard Step 1
    Spare Cluster Wizard Step 1
    Now switch to Spare
    • The cluster wizard is also started here under Network Cluster configuration with the Cluster wizard button
    • And then the spare configuration is selected
    		 Cluster Wizard UTMuser@spare.firewall-name.fqdn Network Cluster configuration
    Step 1
    Spare Cluster Wizard Step 1
    Example UTM on external DSL modem

    Spare Cluster Wizard Step 2
    Spare Cluster Wizard Step 2
    • You will then be prompted to run the Cluster Wizard for the Primary UTM up to step 6
    • When this is done, you can continue with step 3
    Step 2
    Spare Cluster Wizard Step 2
    Example UTM on external DSL modem

    Spare Cluster Wizard Step 3
    Spare Cluster Wizard Step 3
    Setting the primary: [Primary]
    Hotwire Interface: LAN3
    Remote UP adress: 192.168.180.3
    ...    		 The configuration of the Primary UTM must be inserted here. These can be copied in Step 6 of the Primary Cluster Wizard.
    Step 3
    Spare Cluster Wizard Step 3
    Example UTM on external DSL modem

    Spare Cluster Wizard Step 4
    Spare Cluster Wizard Step 4
    Local IP‑address: 192.168.180.3/24 IP address of the Spare UTM
    Step 4
    Spare Cluster Wizard Step 4
    Example UTM on external DSL modem
    Remote IP‑address: 192.168.180.2/--- IP address of the Hotwire remote peer (here: Primary UTM)
  • These values should have been automatically adopted from the configuration of the primary. If this is not the case, both configurations should be checked!

    •
    Spare Cluster Wizard Step 5
    Spare Cluster Wizard Step 5
    Passphrase: insecure The passphrase for the communication between the two UTMs on the HA interfaces (VRR protocol)
    Step 5
    Spare Cluster Wizard Step 5
    Example UTM on external DSL modem
    Key of the remote station: ssh-rsa AAAABNza... The primary UTM key for encrypted data exchange
  • These values should have been automatically adopted from the configuration of the primary. If this is not the case, both configurations should be checked!

    •
    Spare Cluster Wizard Step 6
    Spare Cluster Wizard Step 6
    Setting for the primary: [Spare]
    Local SSH Key: ssh-rsa AAAAB3Nza...    		 This configuration must be inserted when configuring the primay. To do this, it can be copied to the clipboard using the button.
    Step 6
    Spare Cluster Wizard Step 6
    Example UTM on external DSL modem

    Primary Cluster Wizard Step 7
    Primary Cluster Wizard Step 7
  • The system switches back to Primary!
    • Setting the spare: [Spare]
    Local SSH Key: ssh-rsa AAAAB3Nza...    		 The configuration of the Spare UTM must be inserted here. These can be copied in Step 6 of the Spare Cluster Wizard. Cluster Wizard UTMuser@primary.firewall-name.fqdn Network Cluster configuration
    Step 7
    Primary Cluster Wizard Step 7
    Example UTM on external DSL modem
  • This value should have been automatically adopted from the spare configuration. If this is not the case, both configurations should be checked!

    •
    Primary Cluster Wizard Step 8
    Primary Cluster Wizard Step 8
    Key of the remote station: ssh-rsa AAAAB3Nza... The Spare UTM key for encrypted data exchange
    Step 8
    Primary Cluster Wizard Step 8
    Example UTM on external DSL modem
  • This value should have been automatically adopted from the spare configuration. If this is not the case, both configurations should be checked!

    •
    Primary & Spare Cluster Wizard Conclusion
    Primary & Spare Cluster Wizard Conclusion
    • The Cluster Wizard can now be completed on both UTMs with Done
    		 Cluster Wizard UTMprimary.firewall.fqdn Network Cluster configuration
    Step 9
    Primary Cluster Wizard Step 9
    Example UTM on external DSL modem
    Cluster Wizard UTMspare.firewall.fqdn Network Cluster configuration
    Step 7
    Spare Cluster Wizard Step 7
    Example UTM on external DSL modem
    Status of the cluster configuration
    Primary Network Cluster configuration
    Sync state pending The synchronisation status should now change from error (red) to pending (yellow).

    This means that the two UTMs can see each other via the Hotwire interface, but the configuration is not yet synchronised.
    This status can also be recognised by the following: Note in the header "not synchronised", warning sign in the side menu (), note when calling up the admin web interface of the primary UTM

    .     		Cluster configuration UTM Network
    Primary

    Cluster configuration UTM Network
    Spare
  • The status display is refreshed at certain intervals. In the Interfaces tab, the display can be refreshed manually using the button.
  • The cluster must always be synchronised manually
  • Information on the Management area can be found in the article Management Cluster Management.
    • Sync state Synchronize configuration By clicking on the button, the configuration is transferred from the primary to the spare.
    No security query is displayed.     		Cluster configuration UTMuser@firewall.name.fqdn (active cluster) Network
    Primary Status nach Aktivierung des Clusters
    Example UTM on external DSL modem

    Cluster configuration UTMuser@firewall.name.fqdn (passive cluster) Network
    Spare Status nach Aktivierung des Clusters
    Example UTM on external DSL modem
    synchronized
    Cluster status At the primary UTM: The cluster is now operational and the cluster primary has the virtual IP address 192.168.200.1 on the internal interface.
    At the Spare UTM: The Spare-UTM runs as hot standby in backup mode in the background
    notempty
    The cluster must always be synchronised manually
    Primary Network Cluster configuration Area Interfaces
    LAN 1 Cluster configuration UTMuser@firewall.name.fqdn Network
    Primary Cluster configuration
    Example UTM on external DSL modem
    LAN2 Interface used for High Availability Virtual IP 192.168.200.1/24
    IP address: 192.168.100.2/24
    LAN3 Interface is used as Hotwire IP address 192.168.180.2/24
    wg0 Interface is disabled on the passive cluster UTM
    wan0 Interface is disabled on the passive cluster UTM
    Virtual IP addresses 192.168.200.1/24 This address is only available on the respective active Primary device
    Remote IP addresses 192.168.180.3 Addresses of other devices in the cluster

    Sync state synchronized If the synchronization was completed successfully, the synchronization status is now green. The two UTMs are synchronized.
    This process can be checked by calling up a configuration on the spare UTM that has been changed in the primary.
    The cluster Priority Network Cluster Configuration Area Settings of the spare UTM (backup) has been automatically set to low.
  • If the priority on the current spare UTM were set to high and the configuration were synchronized from there, the first machine would automatically be degraded to spare and the former spare UTM to primary.
    		•  Cluster configuration UTMuser@firewall.name.fqdn Network
    Spare
    Example UTM on external DSL modem

    If the status is not updated immediately, this can again be triggered manually via the button for updating .

    Example Configuration 2: External Router

    • This example describes a configuration with an external router.
    • The router is the gateway to the Internet.
    • It is possible that a public network was given by the provider.
      A private network is used in this example. The procedure is then the same as for the public network.
    • Two HA interfaces are now configured here.
      One for the internal and one for the external interface.


    Network configuration

    First member of the cluster (UTM 1, Primary)
    LAN1: External IP address (to router) 192.168.175.102/24
    LAN2: Internal IP address: 192.168.175.1/24
    LAN3: Hotwire IP address: 192.168.180.2/24

    Second member of the cluster (UTM 2, Spare)
    LAN1: External IP address (to the router) 192.168.175.103/24
    LAN2: Internal IP address: 192.168.175.2/24
    LAN3: Hotwire IP address: 192.168.180.3/24


    The virtual IP addresses that both members of the cluster will share are:
    External interfaces (to the router) 192.168.175.101/24.
    Internal interfaces 192.168.200.1/24 | This IP is the default gateway of the internal network.

    notempty
    When using the DHCP server, the virtual IP address must not be in the same network as the physical IP address of the interface.


    Otherwise the DHCP server would access the physical address of the spare UTM during the fallback and not synchronize the leases.


    Preparations

    Setting up the UTMs
    • To set up the UTM cluster, the installation wizard is used first
    • A (cluster) license is already required to log on to the UTM
    • To prevent double dial-up, the DSL modem should not be connected
    • Up to this point, the configuration of the two UTMs differs only in the internal and external IP address
    • After the wizard is completed, the UTMs are restarted


    IP addresses of the upcoming Hotwire interfaces
    Primary Network Network configuration LAN3 → IP addresses:
    IP addresses: »192.168.180.2/24 Primary In the clickbox the IP address of the upcoming Hotwire interface is added.
    In the example the Primary LAN3/A2 gets the IP address 192.168.180.2/24.     		Edit Ethernet interface UTMuser@firewall.name.fqdn Network Network configuration
    Hotwire IP of the Primary

    Spare Network Network configuration LAN3 → IP addresses:
    IP addresses: »192.168.180.3/24 Spare In the example LAN3/A2 the spare gets the IP address 192.168.180.3/24.


    Connect Hotwire interface

    The UTMs are now physically connected via the selected Hotwire interface. This must occupy the same port on the machines - Designation depending on the hardware and software used A2, eth2 or LAN3.< br>(Any other port may also be used, provided it is the same on both devices.)


    Network configuration UTMuser@firewall.name.fqdn Network
    Example Configuration 2: External Router Cluster configuration Initial situation

    Cluster configuration

    • The UTMs have different priorities within the cluster.
    • The higher priority is given to the active device (Primary), the lower to the backup system Spare.
    • In our example, the UTM with the unique internal IP address 192.168.175.1 will be the primary.
    • Login via the web interface with this IP and the port for administration (Default: 11115).
    Primary-UTM
    Cluster configuration
    Start the Cluster Setup Wizard at Primary Network Cluster configuration button Cluster Wizard
    Primary Cluster Wizard Step 1
    Primary Cluster Wizard Step 1
    • Start with the Primary configuration is started
    		 Cluster Wizard UTMuser@firewall.name.fqdn Network Cluster configuration
    Step 1
    Primary Cluster Wizard Step 1
    Example UTM on external router

    Primary Cluster Wizard Step 2
    Primary Cluster Wizard Step 2
    Hotwire interface:: LAN3
  • The same interface must be selected on both devices!
    		•
    Step 2
    Primary Cluster Wizard Step 2
    Example UTM on external router
    Local IP‑address: 192.168.180.2/24 IP address of the primary UTM
    Remote IP‑address: 192.168.180.3/--- IP address of the Hotwire remote unit (spare UTM)

    Primary Cluster Wizard Step 3
    Primary Cluster Wizard Step 3
    HA interfaces: LAN1 LAN2
    notempty
    New as of v14.2.0:
    		The upcoming HA interfaces. In the example the external and the internal interface.
    Step 3
    Primary Cluster Wizard Step 3
    Example UTM on external router
    Virtual IP‑addressesw: »192.168.200.1/24 (LAN2) »192.168.10.201/24 The virtual IP address should be 192.168.200.1. There can also be several virtual IP addresses on one HA interface.
    		LAN2
  • When using the UTM as a DHCP server, the virtual IP address must not be in the same Broadcast Domain as the primary and spare UTM.
    Otherwise the DHCP server would key itself to the physical address of the spare UTM during the fallback and not synchronize the leases.
  • After the wizard has run through, other HA interfaces can also be configured.

    •
    Primary Cluster Wizard Step 4
    Primary Cluster Wizard Step 4
    Interfaces:     Interfaces that are not booted on the backup system, the spare UTM. In this configuration, that is not required
    Step 4
    Primary Cluster Wizard Step 4
    Example UTM on external router
    Applications: Clientless VPN DHCP Server Greylisting Filter HTTP Proxy IPSEC L2TP VPN Mailrelay POP3 Proxy Routing Daemon SPF Filter SSL-VPN Spamfilter WLAN ServerDefault Here applications are listed that should be disabled by default if the spare UTM is in backup mode.
    It may not be possible to use Wireguard in cluster operation if the spare has a path towards the Wireguard peer, e.g. via a public management IP. In this case, the wireguard tunnel to the peer is established and there is a tunnel between the spare and the wireguard peer. The following command must then be entered:
    interface set name wg0 flags "DISABLED_IF_SPARE" (if i.e. the interface is wg0)
    From UTM v12.4.0 this happens automatically, but for existing configurations this must be done retrospectively.

    Primary Cluster Wizard Step 5
    Primary Cluster Wizard Step 5
    Passphrase: insecure The passphrase for the communication between the two UTMs on the HA interfaces (VRR protocol)
    Step 5
    Primary Cluster Wizard Step 5
    Example UTM on external router

    Primary Cluster Wizard Step 6
    Primary Cluster Wizard Step 6
    Setting for the spare: [Primary]
    Hotwire Interface: LAN3
    Remote UP adress: 192.168.180.3
    ...    		 These configurations must be inserted when configuring the spare. To do this, they can be copied to the clipboard using the button.
    Step 6
    Primary Cluster Wizard Step 6
    Example UTM on external router

    Spare Cluster Wizard Step 1
    Spare Cluster Wizard Step 1
    Now switch to Spare
    • The cluster wizard is also started here under Network Cluster configuration with the Cluster wizard button
    • And then the spare configuration is selected
    		 Cluster Wizard UTMuser@spare.firewall-name.fqdn Network Cluster configuration
    Step 1
    Spare Cluster Wizard Step 1
    Example UTM on external router

    Spare Cluster Wizard Step 2
    Spare Cluster Wizard Step 2
    • You will then be prompted to run the Cluster Wizard for the Primary UTM up to step 6
    • When this is done, you can continue with step 3
    Step 2
    Spare Cluster Wizard Step 2
    Example UTM on external router

    Spare Cluster Wizard Step 3
    Spare Cluster Wizard Step 3
    Setting the primary: [Primary]
    Hotwire Interface: LAN3
    Remote UP adress: 192.168.180.3
    ...    		 The configuration of the Primary UTM must be inserted here. These can be copied in ‘'Step 6 of the Primary Cluster Wizard’'.
    Step 3
    Spare Cluster Wizard Step 3
    Example UTM on external router

    Spare Cluster Wizard Step 4
    Spare Cluster Wizard Step 4
  • These values should have been automatically adopted from the configuration of the primary. If this is not the case, both configurations should be checked!
    		•
    Step 4
    Spare Cluster Wizard Step 4
    Example UTM on external router
    Local IP‑address: 192.168.180.3/24 IP address of the Spare UTM
    Remote IP‑address: 192.168.180.2/--- IP address of the Hotwire remote peer (here: Primary UTM)

    Spare Cluster Wizard Step 5
    Spare Cluster Wizard Step 5
  • These values should have been automatically adopted from the configuration of the primary. If this is not the case, both configurations should be checked!
    		•
    Step 5
    Spare Cluster Wizard Step 5
    Example UTM on external router
    Passphrase: insecure The passphrase for the communication between the two UTMs on the HA interfaces (VRR protocol)
    Key of the remote station: ssh-rsa AAAABNza... The primary UTM key for encrypted data exchange

    Spare Cluster Wizard Step 6
    Spare Cluster Wizard Step 6
    Setting for the primary: [Spare]
    Local SSH Key: ssh-rsa AAAAB3Nza...    		 This configuration must be inserted when configuring the primay. To do this, it can be copied to the clipboard using the button.
    Step 6
    Spare Cluster Wizard Step 6
    Example UTM on external router

    Primary Cluster Wizard Step 7
    Primary Cluster Wizard Step 7
  • The system switches back to Primary!
    		•  Cluster Wizard UTMuser@primary.firewall-name.fqdn Network Cluster configuration
    Step 7
    Primary Cluster Wizard Step 7
    Example UTM on external router
    Setting the spare: [Spare]
    Local SSH Key: ssh-rsa AAAAB3Nza...    		 The configuration of the Spare UTM must be inserted here. These can be copied in Step 6 of the Spare Cluster Wizard.

    Primary Cluster Wizard Step 8
    Primary Cluster Wizard Step 8
    Key of the remote station: ssh-rsa AAAAB3Nza... The Spare UTM key for encrypted data exchange
    Step 8
    Primary Cluster Wizard Step 8
    Example UTM on external router

    Primary & Spare Cluster Wizard Conclusion
    Primary & Spare Cluster Wizard Conclusion
    • The Cluster Wizard can now be completed on both UTMs with Done
    		 Cluster Wizard UTMuser@primary.firewall-name.fqdn Network Cluster configuration
    Step 9
    Primary Cluster Wizard Step 9
    Example UTM on external router
    Cluster Wizard UTMuser@spare.firewall-name.fqdn Network Cluster configuration
    Step 7
    Spare Cluster Wizard Step 7
    Example UTM on external router
    Status of the cluster configuration
    Primary Network Cluster configuration Area Interfaces
    LAN1 Interface used for High Availability Virtual IP: 192.168.10.201/24
    IP address 192.168.10.111/24     		Cluster configuration UTMuser@firewall.name.fqdn Network Datei:UTM v14.2.0 Clustekonfiguration mit Router Schnittstellen-en.png
    Primary Cluster configuration
    Example UTM on external router
    LAN2 Interface used for High Availability Virtual IP 192.168.200.1/24
    IP address: 192.168.100.2/24
    LAN3 Interface is used as Hotwire IP address 192.168.180.2/24
    Virtual IP addresses 192.168.200.1/24 This address is only available on the respective active Primary device
    Remote IP addresses 192.168.180.3 Addresses of other devices in the cluster
    Cluster status offline The cluster state does indicate offline (black) because the cluster is not yet set to active
    Sync state error The Sync state is shows error (red), because the remote terminal cannot be reached

    Sync state pending The synchronisation status should now change from error (red) to pending (yellow).

    This means that the two UTMs can see each other via the Hotwire interface, but the configuration is not yet synchronised.
    This status can also be recognised by the following: Note in the header "not synchronised", warning sign in the side menu (), note when calling up the admin web interface of the primary UTM

    .
  • The status display is refreshed at certain intervals. In the Interfaces tab, the display can be refreshed manually using the button.
  • The cluster must always be synchronised manually
  • Information on the Management area can be found in the article Management Cluster Management.
    • Sync state synchronized If the synchronization was completed successfully, the synchronization status is now green. The two UTMs are synchronized.
    This process can be checked by calling up a configuration on the spare UTM that has been changed in the primary.
    The cluster Priority Network Cluster Configuration Area Settings of the spare UTM (backup) has been automatically set to low.
  • If the priority on the current spare UTM were set to high and the configuration were synchronized from there, the first machine would automatically be degraded to spare and the former spare UTM to primary.
    		•  Cluster configuration UTMuser@firewall.name.fqdn Network
    Spare
    Example UTM on external router

    Activate cluster
    Primary & Spare Network Cluster configuration Area Management
    Cluster On → Save This step must be executed at both UTMs. Cluster configuration UTMuser@firewall.name.fqdn (active cluster) Network
    Primary Status nach Aktivierung des Clusters
    Example UTM on external router
    Cluster configuration UTMuser@firewall.name.fqdn (passive cluster) Network
    Spare Status nach Aktivierung des Clusters
    Example UTM on external router
    Cluster status At the primary UTM: The cluster is now operational and the cluster primary has the virtual IP address 192.168.200.1 on the internal interface.
    At the Spare UTM: The Spare-UTM runs as hot standby in backup mode in the background
    notempty
    The cluster must always be synchronised manually


    NAT in the cluster configuration

    In the described constellations with external HA interfaces, it makes sense to adjust the NAT settings.
    The downtime of the cluster is reduced because no new IP addresses have to be assigned for communication.

    We refer here to the example »Cluster configuration: External router«.
    The external virtual IP address of the cluster is in the same broadcast domain as the external IP addresses of the interfaces.
    The default route of the UTMs points to the router that connects to the Internet.

    tcpdump at primary.cluster.local
    External IP UTM 1 Primary 192.168.175.102/24
    External IP UTM 2 Spare 192.168.175.103/24
    Virtual IP Cluster  Cluster 192.168.175.101/24
    IP of the Router 192.168.175.1/24


    To change this, create a new object with the virtual IP address on the cluster interface in the menu Primary Firewall Network Objects. Add Networkobjects UTMuser@firewall.name.fqdn (active cluster) Firewall Networkobjects
    Primary
    Next, the corresponding HideNAT rule is edited under Primary Firewall Packet filter. Edit rule UTMuser@firewall.name.fqdn (active cluster) Firewall Packetfilter
    Primary
    • The object external-interface is replaced by the object HA-External-IP just created.
    • Save and close
    • Update rule
    • Primary Network Cluster configuration Area Management → Sync state:


    tcpdump

    If the ping test is now repeated, the cluster IP 192.168.175.101 is used.

  • If the ping to the router ran without interruption, it is still stored in the Conntrack, so the ping is still being NATed via the wrong IP address.
    The ping must be interrupted. After 30 seconds at the earliest the ping can be restarted.

    • notempty
    For NAT settings, unique IP addresses must always be used in the network objects when configuring NAT via an HA interface.
    This applies not only to HideNATs but also to port forwarding or destination NATs.


    Applications in the cluster configuration

    Mailrelay UTMuser@firewall.name.fqdn Applications Mailrelay Log

    Applications use IP addresses to identify themselves to other servers.
    For some applications, it is possible to set the cluster IP for this.

    This is shown here as an example for the mailrelay.

    Emails are to be sent and received via the mailrelay of the UTMs.
    For this purpose, corresponding PTR, A, MX records and SPF entries were made in the TXT records of the domain, which point to the external virtual IP address of the cluster.

  • Of course, these IP addresses must be routed by the router that forwards the Internet access to your own network.
    In order for the mail relay to send emails via this virtual IP, the outgoing IP address must be set correctly in the application. In our case the virtual IP 192.168.175.101

    • Save
    Then the cluster configuration must be synchronized again.

    Network Cluster configuration Area Management → Sync state:

  • The mail relay now always communicates with the virtual IP address 192.168.175.101. The internal mail server is also contacted with this IP as sender. This has to be taken into account when configuring the mail server if it only accepts SMTP connections from certain IPs.

    • Deactivate applications on the backup

    Cluster configuration UTMuser@firewall.name.fqdn (active cluster) Network Cluster Wizard
    Section
    Applications{{{2}}}

    Under Network Cluster configuration Area Applications, individual applications can be deactivated on the backup UTM using the slide button in the table to prevent problems.

    notempty
    Buttons label updated



    Communication of applications running on the firewall

    All applications that establish a connection from the firewall itself use the primary IPs of the interfaces for this purpose (unless otherwise configured). If management IPs from the same broadcast domain are used, these primary IPs are not the virtual IP addresses.


    Syslog

    Syslog messages are sent by the management IP of the primary if it is the active machine in the cluster, and by the management IP of the spare if it has been activated.


    Http-proxy

    If a parent proxy is in use, which accepts connections only from a certain IP, it must be configured in the menu Applications HTTP Proxy Area General → Outgoing address can be specified.


    Mailrelay

    If a parent proxy is in use, which accepts connections only from a certain IP, it must be configured in the menu Applications HTTP Proxy Area General → Outgoing address can be specified.


    RADIUS/LDAP/AD connection

    If the server only allows connections from certain IPs, the management IPs of both devices must be released on the target server.


    IPSec

    All IPSec connections must be adjusted in phase 1 so that one of the virtual IPs is permanently entered in the "Local Gateway" field.
    VPN IPSec Area Connections button Phase 1 → General Local Gateway 192.168.175.101


    SSL-VPN Server

    In all SSL-VPN server instances the option Multihome must be activated:
    VPN SSL-VPN button → Advanced Multihome: On


    Communication with applications running on other devices

    SSL-VPN Clients

    All SSL-VPN client instances must be customized to use one of the virtual IPs to connect. The following CLI commands are required for this:

    Meaning
    primary.cluster.local> openvpn get Determines the ID of the SSL-VPN connection
    primary.cluster.local> openvpn set id <ID> local_addr <VIRTUELLE-IP> local_port <FREIER-PORT> Sets the local address
    primary.cluster.local> appmgmt restart application openvpn Enables the settings
    Example
    primary.cluster.local> openvpn get
    [...]
    primary.cluster.local> openvpn set id <1> local_addr <192.168.175.101> local_port <20000>
    primary.cluster.local> appmgmt restart application openvpn    		 Example


    POP3 Proxy

    The POP3 proxy always communicates 'with the management IP, if this is in the same broadcast domain as the default gateway. This should be noted when restricting access to POP3 servers to certain IP addresses in their configuration.


    Clientless VPN

    Connections to RDP/VNC servers are always established with the management IPs. This must be considered when restricting access to RDP/VNC servers to certain IP addresses in their configuration.


    Nameserver

    Connections to DNS servers are always established with the management IPs. This must be taken into account when restricting access to DNS servers to certain IP addresses in their configuration.






























    In dieser Seite werden die Variablen für unterschiedliche Sprachen definiert.
    Diese Seite wird auf folgenden Seiten eingebunden



















    CLI commands

    The following describes commands for the Securepoint CLI.

    CLI command Output Description
    cli> cluster info 
    attribute    |value
-------------+-----
cluster_state|primary
sync_state   |synchronized
hotwire_dev  |A2 
maintainance |false
    cluster_state
    ∣primary
     spare
     disabled
    notempty
    v14.2.0
    sync_state
    ∣synchronized
     pending
     error
     disabled
    hotwire_dev
    ∣Ax
    		 Specifies the interface on which the Hotwire interface is configured.
    maintenance
    ∣false
    cli> system config save name <Name der Konfiguration> If a configuration change has been made in the CLI, it must be saved locally first. Only then is a synchronization of the cluster transferred.
    cli> system config synchronize With this command the respective start configuration can be transferred to the Cluster Partner via the Hotwire interface.
    The configuration from the UTM on which the command is executed is used.
    An article of system commands can be found here.
    cli> extc value get application "securepoint_firewall" variable "UPDATE_TRIGGER_DELAY" Value ∣2 Displays the delay in seconds before switching from primary to spare in case of an error. The default value is 2 seconds.
    cli> extc value set application "securepoint_firewall" variable "UPDATE_TRIGGER_DELAY" value 2 OK Changes the delay, for the case of an error, which is switched from the primary to the spare. The default value is 2 seconds and should not be set lower. If the appliances in the cluster have a high base load, the value can be set higher.
    The setting is immediately active and can be transferred to the partner via system config synchronize.

    Maintenance Mode

    cli> cluster maintainance get value
    -----
    1     resp. value
    -----
    0    		 Outputs whether maintenance mode is active (1) or not (0)
    cli> cluster maintainance set value "1"
    cli> system update interface    		 OK Activates the maintenance mode
    • The maintenance mode is used to switch to the spare in a controlled manner and prevents multiple switching in the case of several individual steps (update, change IP addresses etc.)
    • The services available in maintenance mode are configured in the wizard in step 4 or under Network Cluster configuration Area Applications.
    • The UTM is not accessible via the virtual IP in maintenance mode, but only via a fixed IP address.
    cli> cluster maintainance set value "0"
    cli> system update interface         		OK Disables the maintenance mode
    Primary
    cli> cluster maintainance set value "1"
    cli> cluster info    		 
    attribute    |value
-------------+-----
cluster_state|spare
sync_state   |synchronized
hotwire_dev  |A2 
maintainance |true
    		State during the set "Maintainance Mode" on the Primary
    Spare
    cli> cluster info 
    attribute    |value
-------------+-----
cluster_state|primary
sync_state   |synchronized
hotwire_dev  |A2 
maintainance |false
    		 State during the set "Maintenance Mode" on the Spare


    Restrictions

    Combine DHCP client with HA interface

  • No HA interface may be configured on an Ethernet or VLAN interface if the interface has been configured as a DHCP client and UTM is dynamically assigned an IP address there.
    If the DHCP server is not available after you have started the UTM and it is also the primary in the cluster at that moment, the virtual IP address is removed from the interface as soon as the DHCP server is available again and the UTM receives a new IP address from the DHCP server.

    • DHCP server in a cluster environment

  • When using the UTM as DHCP server, these IP addresses must not be located in the same Broadcast Domain of the other IP addresses.
    Otherwise the DHCP server would key itself to the physical address of the spare UTM during the fallback and would not synchronize the leases. See: Cluster Configuration Step 2
    • Récupérée de "https://wiki.securepoint.de/index.php?title=UTM/NET/Cluster&oldid=109402"