Cluster

notempty

Dieser Artikel bezieht sich auf eine nicht mehr aktuelle Version!

notempty

Der Artikel für die neueste Version steht hier

notempty

Zu diesem Artikel gibt es bereits eine neuere Version, die sich allerdings auf eine Reseller-Preview bezieht

Securepoint Cluster Configuration - Best Practice

Last adaption: 12.1

New:

• Maintenance mode for the cluster
• Clearer wording for virtual IP with DHCP (03.2023)

notempty

This article refers to a Resellerpreview

11.7

---

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.

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

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

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 master to the original Master.
Here now the priority decides, because both machines are equally affected and the fallback of the Master becomes active.

---

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.

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 master 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 • Spare UTM with external router

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 Master or to Low for Spare according to the future purpose.

---

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

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
• A (cluster) licence 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

---

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.

---

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.	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!	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.	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 a DHCP server, the virtual IP address must not be in the same Broadcast Domain as the master 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.
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.	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. 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 (if the interface is wg0): interface set name wg0 flags "DISABLED_IF_SPARE" From UTM v12.4.0 this happens automatically, but for existing configurations this must be done retrospectively.	Fig.: 1.8
Cluster Wizard Step 5
Priority	High	The Master UTM receives the priority "high".	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
Status of the cluster configuration
Master → Network →Cluster configurationTab Interfaces
eth1	Interface used for High Availability	Virtual IP 192.168.200.1/24 IP address: 192.168.100.2/24	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.
Settings für clusterconfiguration
Master → Network →Cluster configurationTab Options
Local SSH Key:	Generate new local SSH key	An SSH public key is created in the Options tab.	Fig.: 1.11
	ssh-rsa AAAAB3Nz […] zE0SU= root@master.cluster.local	Copy SSH key to the clipboard
Spare-UTM Spare UTM
Spare interface configuration
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	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.
Settings für clusterconfiguration
Spare → Network →Cluster configurationTab Options
Priority	low	The priority of the spare must be set to "Low".	Fig.: 1.13
Passphrase	insecure	The passphrase for the communication between the two UTMs on the HA interfaces (VRR protocol)
Local SSH Key:	Generate new local SSH key	Create SSH Public Key for the Spare-UTM'
	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 configurationTab Options
Connecting external interfaces to the DSL modem			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 set up the UTM cluster, the installation wizard is used first
• A (cluster) licence is already required to log on to the UTM
• 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
• 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 - Designation depending on the hardware and software used A2, eth2 or LAN3.

---

Cluster configuration

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.	Fig.: 1.4
Start the Cluster Setup Wizard at Master → Network →Cluster configurationTab Cluster Wizard Button +
Cluster Wizard Step 1
Hotwire interface:	eth2: 192.168.180.2/24	The same interface must be selected on both devices!	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.	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 a DHCP server, the virtual IP address must not be in the same Broadcast Domain as the master 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.
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	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.	Fig.: 1.8
Cluster Wizard Step 5
Priority	High	The Master UTM receives the priority "high".	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
Status of the cluster configuration
Master → Network →Cluster configurationTab Interfaces
eth0	(Interface is not yet configured for HA)	IP address 192.168.175.102/24	Fig.: 1.10
eth1	Interface used for High Availability	Virtual IP 192.168.200.1/24 IP address: 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.
Settings für clusterconfiguration
Master → Network →Cluster configurationTab Options
Local SSH Key:	Generate new local SSH key	An SSH public key is created in the Options tab.	Fig.: 1.11
	ssh-rsa AAAAB3Nz […] zE0SU= root@master.cluster.local	Copy SSH key to the clipboard
Spare UTM Spare UTM
Spare interface configuration
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	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.
Settings für clusterconfiguration
Spare → Network →Cluster configurationTab Options
Priority	low	The priority of the spare must be set to "Low".	Fig.: 1.13
Passphrase	insecure	The passphrase for the communication between the two UTMs on the HA interfaces (VRR protocol)
Local SSH Key:	Generate new local SSH key	An SSH public key is created in the Options tab.
	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	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
Synchronize configuration
Save Synchronize configuration
Activate cluster
Master & Spare → Network →Cluster configuration
Cluster	On → Save	This step must be executed at both UTMs.	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 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 master.cluster.local

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

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.

To change this, create a new object with the virtual IP address on the cluster interface in the menu Master → Firewall →Port Filter on the tab Network Objects.

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.

Save Close Update rule Master → Network →Cluster configuration Button Synchronize 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

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 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-ProxyTab 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 → 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 Tab Advanced

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.
Maintenance Mode
cli> cluster maintainance set value "1" cli> system update interface	OK	Enables the maintenance mode
cli> cluster maintainance set value "0" cli> system update interface	OK	Disables the maintenance mode
Master cli> cluster info	attribute |value -------------+----- cluster_state|backup sync_state |synchronized hotwire_dev |eth2 maintainance |true	State during the set "Maintainance Mode" on the Master
Spare cli> cluster info	attribute |value -------------+----- cluster_state|master sync_state |synchronized hotwire_dev |eth2 maintainance |false	State during the set "Maintainance 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 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

---