Jump to:navigation, search
Wiki


























De.png
Fr.png


Securepoint Cluster Configuration
Best Practice

Last adaptation to the version: 11.8.8


New:


Previous versions: 11.7



Important information

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

The UTM is upgraded by converting it into a Hot-Standy UTM cluster and protects business-critical processes against the failure of a UTM. Securepoint provides an active/passive cluster for this purpose. The UTMs within the cluster monitor each other and automatically switch to the device with the best status if required. An intervention of the administrator is not necessary.

Cluster-01.jpg
Fig. 1.1

Establishment

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 MASTER in the cluster then created. 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 MASTER is also entered on the spare UTM.
The active UTM in the cluster, has the higher priority and is called the MASTER.
The UTM with the lower priority, the passive UTM, is the BACKUP.


Requirements

The following requirements are necessary for cluster operation:


  • A cluster license

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

    End customers are requested to 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 (see Figure 1.1) 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 master/backup 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

Functionality of the cluster
Fig. 1.2


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

The Cluster VRR Protocol
UTM11 BP Cluster pic6.png


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

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


Table, behavior in the cluster, example two HA interfaces:

HA interface 1 HA interface 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
  • Ist gleichzeitig ein Fallback konfiguriert und ein fehlgeschlagener Ping-Check löst das Umschalten auf die Spare aus und diese registriert ebenfalls einen fehlgeschlagenen Ping-Check, wird sie den Master wieder an den ursprünglichen Master zurückgeben.
    Hier entscheidet nun die Priorität, da beide Maschinen gleichwertig beeinträchtigt sind und das Fallback der Master wird aktiv.

  • hotwire interface

    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 master in the cluster to the backup (Fig. 1.3).

    The Hotwire connection should always be a direct cable connection (no switch etc. in between). 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.


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

    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 master at that moment.


    Example configuration: 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

    Erstes Mitglied des Clusters (UTM 1, Master)
    eth0: Externe DSL Verbindung mittels PPPoE.
    eth1: Interne IP-Adresse: 192.168.100.2/24
    eth2: Hotwire-IP-Adresse:192.168.180.2/24
    Zweites Mitglied des Clusters (UTM 2, Spare)
    eth0: Externe DSL Verbindung mittels PPPoE.
    eth1: Interne IP-Adresse:192.168.100.3/24
    eth2: Hotwire-IP-Adresse: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.

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

  • Setting up the UTMs

    To set up the UTM cluster, the installation wizard is used first. 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. In the last step of the installation wizard, the cluster license is selected. After the wizard is completed, the UTMs are restarted.


    hotwire interface

    The UTMs are now physically connected via the selected Hotwire interface. This must occupy the same port on the machines - for example LAN3/eth2.



    Cluster configuration

    The UTMs have different priorities within the cluster. The higher priority is given to the master, the lower to the backup system. In our example, the UTM with the unique internal IP address 192.168.100.2 will be the master. Login via the web interface with this IP and the port for administration (Default: 11115).

    Cluster configuration
    Master-UTM
    Master-UTM
    IP address of the upcoming Hotwire interface
    Master → Network →Network configuration eth2 IP addresses
    IP addresses »192.168.180.2/24 In the clickbox the IP address of the upcoming Hotwire interface is added.
    In the example LAN3/eth2 gets the IP address 192.168.180.2/24.
    UTM v11.8.7 Cluster Schnittstelle1-en.png
    Fig. 1.4


    Start the Cluster Setup Wizard at Master → Network →Cluster configuration Cluster Wizard
    Cluster Wizard Step 1
    hotwire interface eth2: 192.168.180.2/24 The same interface must be selected on both devices! UTM v11.8.7 Cluster-Assistent Schritt1-en.png
    Fig. 1.5
    Local IP‑address: 192.168.180.2/24 IP address of the master UTM
    Remote IP‑address: 192.168.180.3 IP address of the Hotwire remote unit (spare UTM)


    Cluster Wizard Step 2
    Interface: eth1 The upcoming HA interface. In the example the internal interface. UTM v11.8.7 Cluster-Assistent Schritt2-en.png
    Fig. 1.6
    Virtual IP‑address: 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 DHCP server, these IP addresses must not be 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 not synchronize the leases.

    After the wizard has run through, other HA interfaces can also be configured.



    Cluster Wizard Step 3
    Disabled interfaces while the device is in backup mode: ×wan0 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 master 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.
    UTM v11.8.7 Cluster-Assistent Schritt3-en.png
    Fig. 1.7


    Cluster Wizard Step 4
    Disabled applications while the device is in backup mode:×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. UTM v11.8.7 Cluster-Assistent Schritt4-en.png
    Fig. 1.8


    Cluster Wizard Step 5
    Priority High The Master UTM receives the priority "high". UTM v11.8.7 Cluster-Assistent Schritt5-en.png
    Fig. 1.9
    Passphrase insecure The passphrase for the communication between the two UTMs on the HA interfaces (VRR protocol)
    Close the Cluster Wizard with Finish


    Master → Network →Cluster configuration Interfaces
    eth1 Interface used for High Availability Virtual IP 192.168.200.1/24
    IP address: 192.168.100.2/24
    UTM v11.8.7 Cluster Konfig-en.png
    Fig. 1.10
    eth2 Interface is used as Hotwire IP address 192.168.180.2/24
    wan0 Interface is deactivated during backup
    Cluster state The cluster state does not yet indicate a state because the cluster is not yet set to active.
    Sync state The Sync state is red because the remote terminal cannot be reached.



    Master → Netzwerk →Cluster configuration Options
    Local SSH Key: Generate new local SSH key An SSH public key is created in the Options tab. UTM v11.8.7 Netzwerk Cluster-Config Einstellungen-en.png
    Fig. 1.11
    ssh-rsa
    AAAAB3Nz […] zE0SU=
    root@master.cluster.local
    Copy SSH key to the clipboard

    Spare-UTM
    Spare UTM

    Login to the web interface of the spare UTM via the IP address 192.168.180.3
    Spare → Network →Cluster configurationTab Interfaces Button ­
    Name: eth2 eth2 Edit interface UTM v11.8.7 Netzwerk Cluster-Config UTM2 eth2-en.png
    Fig. 1.12
    Usage: Use interface as hotwire The interface eth2 of the spare UTM is marked as Hotwire.
    Local IP‑address: 192.168.180.3/24 IP address of the spare UTM to be used for Hotwire.
    Remote IP‑address: 192.168.180.2 IP address of the already configured Master UTM to be addressed as Hotwire.


    Spare → Netzwerk →Cluster configuration Options
    Local SSH Key: Generate new local SSH key Create SSH Public Key for the Spare-UTM' UTM v11.8.7 Netzwerk Cluster-Config Einstellungen-Spare-en.png
    Fig. 1.13
    ssh-rsa
    AAAAB3Nz […] Q1/k=
    root@spare.cluster.local
    Copy SSH key to the clipboard not yet
    SSH‑Key of the remote terminal: ssh-rsa
    AAAAB3Nz […] zE0SU=
    root@master.cluster.local
    Paste public SSH key of the Master UTM from the clipboard
    Local SSH Key: Now paste the local Public-SSh-Key of the spare UTM into the clipboard.


    Switch to Master → Network →Cluster configuration Options
    SSH‑Key of the remote terminal: ssh-rsa
    AAAAB3Nz […] Q1/k=
    root@spare.cluster.local
    Paste public key of the spare UTM from the clipboard. On the Master-UTM the Spare-UTM represents the remote station

    On both sides there should now be a local SSH key and the SSH key of the remote terminal.
    Save the settings on both UTMs in this dialog by pressing the Save button.
    Sync state The synchronization status should now change from red to orange. This means that the two UTMs see each other via the Hotwire interface, but the configuration is not yet synchronized.
    The status is updated in certain intervals. In the tab interfaces the update can be triggered manually with the synchronize button .
    Master Synchronize configuration
    Sync state 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 Master.
    The cluster Priority → Network →Cluster ConfigurationTab 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 master.



    Activate cluster
    Master & Spare → Network →Cluster configuration

    Connecting external interfaces to the DSL modem
    UTM v11.8.7 Cluster Konfig Ergebnis-en.png
    Fig. 1.14
    Cluster: On

    This step must be executed at both UTMs.

    Cluster state At the master UTM: The cluster is now operational and the cluster master 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


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


    Example Configuration: 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, Master)
    eth0: External IP address (to router) 192.168.175.102/24
    eth1: Internal IP address: 192.168.100.2/24
    eth2: Hotwire IP address: 192.168.180.2/24

    Second member of the cluster (UTM 2, Spare)
    eth0: External IP address (to the router) 192.168.175.103/24
    eth1: Internal IP address: 192.168.100.3/24
    eth2: Hotwire IP address: 192.168.180.3/24

    The virtual IP addresses that both members of the cluster will share are the IP addresses 192.168.200.1/24 for the internal interfaces and 192.168.175.101/24 for the external interfaces (to the router).
    The virtual IP address 192.168.200.1 is the default gateway of the internal network.


    Setting up the UTMs

    To start up the UTM cluster, the installation wizard is used first. This setup is performed separately on each UTM. Up to this point, the configuration of the two UTMs differs only in the internal and external IP address. In the last step of the installation wizard, the cluster license is selected. After the wizard is completed, the UTMs are restarted.


    hotwire interface

    The UTMs are now physically connected via the selected Hotwire interface. This must occupy the same port on the machines - for example LAN3/eth2.


    Cluster configuration

    Cluster configuration
    Master-UTM
    Master-UTM
    IP address of the upcoming Hotwire interface
    Master → Network →Network configuration eth2 IP addresses
    »192.168.180.2/24 In the clickbox the IP address of the upcoming Hotwire interface is added.
    In the example LAN3/eth2 gets the IP address 192.168.180.2/24.
    UTM v11.8.7 Cluster Schnittstelle1-en.png
    Fig. 1.4


    Start the Cluster Setup Wizard at Master → Network →Cluster configuration Cluster Wizard
    Cluster Wizard Step 1
    hotwire interface eth2: 192.168.180.2/24 The same interface must be selected on both devices! UTM v11.8.7 Cluster-Assistent Schritt1-en.png
    Fig. 1.5
    Local IP‑address: 192.168.180.2/24 IP address of the master UTM
    Remote IP‑address: 192.168.180.3 IP address of the Hotwire remote unit (spare UTM)


    Cluster Wizard Step 2
    Interface: eth1 The upcoming HA interface. In the example the internal interface. UTM v11.8.7 Cluster-Assistent Schritt2-en.png
    Fig. 1.6
    Virtuelle IP‑Adresse: 192.168.200.1/24 Die virtuelle IP-Adresse soll 192.168.200.1 sein. Es können auf einer HA-Schnittstelle auch mehrere virtuelle IP-Adressen liegen.
    When using the UTM as DHCP server, these IP addresses must not be 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 not synchronize the leases.
    After the wizard has run through, other HA interfaces can also be configured.


    Cluster Wizard Step 3
    Disabled interfaces while the device is in backup mode: Interfaces that are not booted on the backup system, the spare UTM. In this configuration, that is not required UTM v11.8.7 Cluster-Assistent Schritt3b-en.png
    Fig. 1.7


    Cluster Wizard Step 4
    Disabled applications while the device is in backup mode:×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. UTM v11.8.7 Cluster-Assistent Schritt4-en.png
    Fig. 1.8


    Cluster Wizard Step 5
    High The Master UTM receives the priority "high". UTM v11.8.7 Cluster-Assistent Schritt5.png
    Fig. 1.9
    Passphrase insecure The passphrase for the communication between the two UTMs on the HA interfaces (VRR protocol)
    Close the Cluster Wizard with Finish


    Master → Network →Cluster configurationTab Interfaces
    eth0 (Interface is not yet configured for HA) IP address 192.168.175.102/24 UTM v11.8.7 Cluster Konfig-exr-en.png
    Fig. 1.10
    eth1 Interface used for High Availability Virtuelle IP-Adresse: 192.168.200.1/24
    IP-Adresse: 192.168.100.2/24
    eth2 Interface is used as Hotwire IP address 192.168.180.2/24
    wan0 Interface is deactivated during backup
    Cluster state The cluster state does not yet indicate a state because the cluster is not yet set to active.
    Sync state The Sync state is red because the remote terminal cannot be reached.



    Master → Network →Cluster configuration
    Local SSH Key: Generate new local SSH key An SSH public key is created in the Options tab. UTM v11.8.7 Netzwerk Cluster-Config Einstellungen-en.png
    Fig. 1.11
    ssh-rsa
    AAAAB3Nz […] zE0SU=
    root@master.cluster.local
    Copy SSH key to the clipboard

    Spare-UTM
    Spare UTM

    Login to the web interface of the spare UTM via the IP address 192.168.180.3
    Spare → Network →Cluster configurationTab Interfaces
    Name: eth2 eth2 Edit interface UTM v11.8.7 Netzwerk Cluster-Config UTM2 eth2-en.png
    Fig. 1.12
    Usage: Schnittstelle als Hotwire benutzen Die Schnittstelle eth2 der Spare-UTM wird als Hotwire gekennzeichnet.
    Local IP‑address: 192.168.180.3/24 IP-Adresse der Spare-UTM, die für Hotwire verwendet werden soll.
    Remote IP‑address: 192.168.180.2 IP-Adresse der bereits konfigurierten Master-UTM, die als Hotwire angesprochen werden soll.


    Spare → Network →Cluster configurationTab Options
    Local SSH Key: Generate new local SSH key An SSH public key is created in the Options tab. UTM v11.8.7 Netzwerk Cluster-Config Einstellungen-Spare-en.png
    Fig. 1.13
    ssh-rsa
    AAAAB3Nz […] Q1/k=
    root@spare.cluster.local
    Copy SSH key to the clipboard not yet
    SSH‑Key of the remote terminal: ssh-rsa
    AAAAB3Nz […] zE0SU=
    root@master.cluster.local
    Paste public SSH key of the Master UTM from the clipboard
    Local SSH Key: Now paste the local Public-SSh-Key of the spare UTM into the clipboard.


    Master → Network →Cluster configurationTab Options
    SSH‑Key of the remote terminal: ssh-rsa
    AAAAB3Nz […] Q1/k=
    root@spare.cluster.local
    Paste public key of the spare UTM from the clipboard. On the Master-UTM the Spare-UTM represents the remote station

    On both sides there should now be a local SSH key and the SSH key of the remote terminal.
    Save the settings on both UTMs in this dialog by pressing the Save button.
    Sync state The synchronization status should now change from red to orange. This means that the two UTMs see each other via the Hotwire interface, but the configuration is not yet synchronized.
    The status is updated in certain intervals. In the tab interfaces the update can be triggered manually with the synchronize button .
    Master
    Sync state 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 Master.
    The cluster Priority → Network →Cluster ConfigurationTab 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 master.

    Configure external interface to HA operation
    Master → Network →Cluster configuration eth0
    Name: eth0 Configure external interface to HA operation UTM v11.8.7 Cluster Konfig-exr eth0-en.png
    Fig. 1.26
    Use interface for High Availability Configure high availability
    Virtuelle IP-Adressen: »192.168.175.101/24 Virtual IP address from the network of the router
    Save Synchronize configuration



    Activate cluster
    Master & Spare → Network →Cluster configuration
    On Save This step must be executed at both UTMs. UTM v11.8.7 Cluster Konfig-exr Ergebnis-en.png
    Fig. 1.14
    Cluster state At the master UTM: The cluster is now operational and the cluster master 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


    NAT in der Cluster-Konfiguration

    In beschrieben Konstellationen mit externen HA-Schnittstellen ist es sinnvoll die NAT Einstellungen anzupassen.Die Ausfallzeit des Clusters wird reduziert, da keine neue IP-Adressen für die Kommunikation vergeben werden müssen.
    Wir beziehen uns hier auf das Beispiel „Cluster Konfiguration: Externer Router“.

    Die externe virtuelle IP-Adresse des Clusters ist in der selben Broadcast Domain wie die externen IP-Adressen der Schnittsellen.
    Die Standardroute der UTMs zeigt auf den Router der die Internet Verbindung herstellt.

    External IP UTM 1 Master 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

    tcpdump at master.cluster.local

    Die UTM 1 ist der Master und besitzt die virtuelle IP-Adresse.
    Setzt man nun einen ping aus dem internen Netz auf die IP-Adresse des Routers ab, sieht man nebenstehendes im tcpdump der UTM1 auf dem externen Interface.

    Der Ping wird vom Client im Standard-Regelwerk nicht über die virtuelle IP-Adresse des Clusters geNATet, sondern über die dem Master eindeutige IP-Adresse 192.168.175.102.
    Das kommt zustande, weil die eindeutige IP-Adresse die erste IP auf der Schnittstelle ist und der Router sich in der gleichen Broadcast Domain befindet. Wechselt der Cluster auf das Backup System, wird dort nicht mehr die IP-Adresse der externen Schnittstelle der Master-UTM 192.168.175.102 stehen, sondern die IP-Adresse der externen Schnittstelle der Spare-UTM 192.168.175.103.


    UTM v11.8.7 Cluster Netzwerkobjekt-HA-en.png

    Um das zu ändern wird im Menü Master → Firewall →Portfilter im Reiter Netzwerkobjekte ein neues Objekt mit der virtuellen IP-Adresse auf dem Cluster Interface erstellt.

    Afterwards the corresponding HideNAT rule is edited in the Port filter tab. In the example the rule number 7.
    Afterwards the corresponding HideNAT rule is edited in the Port filter tab. In the example the rule number 7.
    The object external-interface is replaced by the object HA-External-IP just created.
    The object external-interface is replaced by the object HA-External-IP just created.












    Save Update rule Master → Network →Cluster configuration


    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.

    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

    UTM v11.8.7 Cluster Mailrelay Allgemein-en.png

    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 configuration →Cluster configuration

    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.


    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 master 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-ProxyTab GeneralOutgoing 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-ProxyTab GeneralOutgoing 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 Phase 1General 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 Tab Advanced Multihome On

    Communication with applications running on other devices

    SSL VPN clients

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

    CLI commands Meaning
    master.cluster.local> openvpn get Determines the ID of the SSLVPN connection
    master.cluster.local> openvpn set id <ID> local_addr <VIRTUELLE-IP> local_port <FREIER-PORT> Sets the local address
    master.cluster.local> appmgmt restart application openvpn Enables the settings

    Example
    master.cluster.local> openvpn get
    [...]
    master.cluster.local> openvpn set id <1> local_addr <192.168.175.101> local_port <20000>
    master.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.


    Nameservers

    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.


    CLI commands

    The following describes commands for the Securepoint CLI.

    CLI command Output Description:
    cli> cluster info
    cluster_state
    ∣master
    backup
     none
    The cluster state indicates who in the cluster is currently master or backup or whether the cluster is active at all. The output always refers to the machine on which this command is executed.
    sync_state
    ∣synchronized
    pending
     error
    Indicates the status of the configuration. Synchronized" means that it is the same on both UTMs of the cluster. The state "pending" means that the UTMs have a different state. In both cases the members can communicate with each other. The state "error" shows that they cannot exchange data. This could be the case if no hotwire interface is configured, the wiring is not correct, the SSH keys have not been exchanged, or the wrong SSH keys are used.
    hotwire_dev
    ∣ethx
    Specifies the interface on which the Hotwire interface is configured.
    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.
    cli> extc value get application "securepoint_firewall" variable "UPDATE_TRIGGER_DELAY" Value ∣2 Displays the delay in seconds before switching from master to backup 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 master to backup. 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.

    Restrictions

    Combine DHCP client with HA interface

    Do not configure an HA interface on an Ethernet or VLAN interface on which you have configured DHCP client, i.e. the UTM on the interface is dynamically assigned an IP address. If the DHCP server is not available after you have started the UTM and it is also the master 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