14Redundancy menu

 

 

inset_32.jpg 

Redundancy is described in detail in Section 17, “Redundancy”.

 

 

inset_33.jpg 

To use the redundancy function, both mGuards must have the same firmware.

 

 

inset_35.jpg 

When the redundancy function is activated, VLAN cannot be used in Stealth mode.

Redundanz_Firewall-Redundanz_Redundanz.png

 

14.1Redundancy >> Firewall Redundancy

 

 

inset_36.jpg 

This menu is not available on the FL MGUARD RS2000, FL MGUARD RS2005, TC MGUARD RS2000 3G, and TC MGUARD RS2000 4G.

 

14.1.1Redundancy

Redundancy >> Firewall Redundancy >> Redundancy

 

Enable redundancy

Deactivated (default): firewall redundancy is disabled.

Activated: firewall redundancy is enabled.

This function can only be activated when a suitable license key is installed.

Further conditions apply if VPN redundancy is to be enabled at the same time, see “VPN redundancy” on page 433.

General

Status of redundancy

Shows the current status.

 

Fail-over switching time

Maximum time that is allowed to elapse in the event of errors before switching to the other mGuard.

 

Latency before fail-over

0 ... 10,000 milliseconds, default: 0

Time the redundancy system ignores an error.

The connectivity and availability checks ignore an error unless it is still present after the time set here has elapsed.

 

Priority of this device

high/low

Specifies the priority associated with the presence notifica­tions (CARP).

Set the priority to high on the mGuard that you want to be ac­tive. The mGuard on standby is set to low.

Both mGuard devices in a redundancy pair may either be set to different priorities or to high priority. .

Section1400620.jpg

 

Passphrase for avail­ability checks

On an mGuard which is part of a redundancy pair, checks are constantly performed to determine whether an active mGuard is available and whether it should remain active. A variation of the CARP (Common Address Redundancy Protocol) is used here.

CARP uses SHA-1 HMAC encryption together with a pass­word. This password must be set so it is the same for both mGuard devices. It is used for encryption and is never trans­mitted in plain text.

Section1400622.jpg

 

When changing the password, proceed as follows:

Set the new password on both mGuard devices. It does not matter which order you do this in but the same password must be used in both cases. If you inadvertently enter an incor­rect password, follow the instructions under “How to proceed in the event of an incorrect password” on page 400.

As soon as a redundancy pair has been assigned a new password, it automatically negotiates when it can switch to the new password without interruption.

 

If an mGuard fails while the password is being changed, the following scenarios apply:

Password replacement has been started on all mGuard devices and then interrupted because of a network error, for example. This scenario is rectified automatically.

Password replacement has been started on all mGuard devices. However, one mGuard then fails and must be replaced.

Password replacement has been started but not performed on all mGuard devices because they have failed. Password replacement must be started as soon as a faulty mGuard is back online. If an mGuard has been replaced, it must first be configured with the old password before it is connected.

 

How to proceed in the event of an incorrect password

Section1400624.jpg

If you can still remember the old password, proceed as follows:

Reconfigure the mGuard on which the incorrect password was entered so that it uses the old password.

Wait until the mGuard indicates that the old password is being used.

Then enter the correct password.

If you have forgotten the old password, proceed as follows:

Check whether you can read the old password from the other mGuard.

If the other mGuard is disabled or missing, you can simply enter the correct new pass­word on the active mGuard on which you inadvertently set the incorrect password. Make sure that the other mGuard is assigned the same password before operating it again.

If the other mGuard is already using the new password, you must make sure that the mGuard with the incorrect password is not active or able to be activated, e.g., by re­moving the cable at the LAN or WAN interface.

In the case of remote access, you can enter a destination for the connectivity check that will not respond. Prior to provoking this type of error, check that there is no redun­dancy error on any of the mGuard devices. One mGuard must be active and the other must be on standby. If necessary, rectify any errors displayed and only then use this method. After that, follow these steps:

Replace the incorrect password with a different one.

Enter this password on the active mGuard too.

Restart the mGuard that is not active. You can do this, for example, by reconnect­ing the Ethernet cable or restoring the old settings for the connectivity check.

External Virtual Interfaces

External virtual router ID

1, 2, 3, ... 255 (default: 51)

Only in Router network mode.

This ID is sent by the redundancy pair with each presence no­tification (CARP) via the external interface and is used to iden­tify the redundancy pair.

This ID must be the same for both mGuard devices. It is used to differentiate the redundancy pair from other redundancy pairs that are connected to the same Ethernet segment via their external interface.

Please note that CARP uses the same protocol and port as VRRP (Virtual Router Redundancy Protocol). The ID set here must be different to the IDs on other devices which use VRRP or CARP and are located in the same Ethernet segment.

 

External virtual IP addresses

Default: 10.0.0.100

Only in Router network mode.

These are IP addresses which are shared by both mGuard de­vices as virtual IP addresses of the external interface. These IP addresses must be the same for both mGuard devices.

These addresses are used as a gateway for explicit static routes for devices located in the same Ethernet segment as the external network interface of the mGuard.

The active mGuard can receive ICMP requests via this IP ad­dress. It responds to these ICMP requests according to the menu settings under Network Security >> Packet Filter >> Ad­vanced.

No network masks or VLAN IDs are set up for the virtual IP ad­dresses as these attributes are defined by the real external IP address. For each virtual IP address, a real IP address must be configured whose IP network accommodates the virtual address. The mGuard transmits the network mask and VLAN setting from the real external IP address to the corresponding virtual IP address.

The applied VLAN settings determine whether standard MTU settings or VLAN MTU settings are used for the virtual IP ad­dress.

Section1400626.jpg

Internal Virtual Interfaces

Internal virtual router ID

1, 2, 3, ... 255 (default: 52)

Only in Router network mode.

This ID is sent by the redundancy pair with each presence no­tification (CARP) via the external and internal interface and is used to identify the redundancy pair.

This ID must be set so it is the same for both mGuard devices. It is used to differentiate the redundancy pair from other Ether­net devices that are connected to the same Ethernet segment via their external/internal interface.

Please note that CARP uses the same protocol and port as VRRP (Virtual Router Redundancy Protocol). The ID set here must be different to the IDs on other devices which use VRRP or CARP and are located in the same Ethernet segment.

 

Internal virtual IP addresses

As described under External virtual IP addresses, but with two exceptions.

Under Internal virtual IP addresses, IP addresses are de­fined for devices which belong to the internal Ethernet seg­ment. These devices must use the IP address as their default gateway. These addresses can be used as a DNS or NTP server when the mGuard is configured as a server for the pro­tocols.

For each virtual IP address, a real IP address must be config­ured whose IP network accommodates the virtual address.

The response to ICMP requests with internal virtual IP ad­dresses is independent from the settings made under Network Security >> Packet Filter >> Advanced.

Encrypted State Synchroni­zation

Encrypt the state mes­sages

When the function is activated, state synchronization is en­crypted.

Section1400628.jpg

 

Passphrase

The password is changed as described under “Passphrase for availability checks” on page 399.

Only deviate from the prescribed approach if an incorrect password has been inadvertently entered.

 

How to proceed in the event of an incorrect password

Section1400630.jpg

Scenario 1: only one mGuard has an incorrect password. The process of changing the password has not yet begun on the other mGuard.

Reconfigure the mGuard on which the incorrect password was entered so that it uses the old password.

Wait until the mGuard indicates that the old password is being used.

Then enter the correct password.

Scenario 2: the other mGuard is already using the new password.

The status of both mGuard devices must be such that they are using an old password but expecting a new one (red cross). To ensure that this is the case, enter random passwords successively.

Finally, generate a secure password and enter it on both mGuard devices. This pass­word is used immediately without any coordination.

During this process, the state of the mGuard on standby may briefly switch to “outdated”. However, this situation resolves itself automatically.

 

Encryption algorithm

DES, 3DES, AES-128, AES-192, AES-256 (default)

Section1400632.jpg

 

Hash algorithm

MD5, SHA1, SHA-256 (default), SHA-512

Section1400634.jpg

Interface for State Synchro­nization

(Only for mGuard Centerport (Innominate), FL MGUARD CENTERPORT)

Interface which is used for state syn­chronization

Internal Interface/Dedicated Interface

The mGuard Centerport (Innominate), FL MGUARD CENTERPORT supports a dedicated inter­face. This is a reserved, direct Ethernet interface or a dedi­cated LAN segment, via which the state synchronization is sent.

The redundancy pair can be connected via an additional ded­icated Ethernet interface or an interconnected switch.

When set to Dedicated Interface, presence notifications (CARP) are also listened for on the third Ethernet interface. Presence notifications (CARP) are also sent when the mGuard is active.

However, no additional routing is supported for this interface.

Frames received on this interface are not forwarded for secu­rity reasons.

The connection status of the third Ethernet interface can be queried via SNMP.

 

IP of the dedicated interface

(Only available when Dedi­cated Interface is selected.)

IP

IP address used on the third network interface of the mGuard Centerport (Innominate), FL MGUARD CENTERPORT for state synchronization with the other mGuard.

Default: 192.168.68.29

Netmask 

Network mask used on the third network interface of the mGuard Centerport (Innominate), FL MGUARD CENTERPORT for state synchronization with the other mGuard.

Default: 255.255.255.0

Use VLAN 

When Yes is selected, a VLAN ID is used for the third network interface.

VLAN ID 

1, 2, 3, ... 4094 (default: 1)

VLAN ID if this setting is activated.

 

Disable the availability check at the external interface

(Only available when Dedi­cated Interface is selected.)

When the function is activated, no presence notifications (CARP) are sent or received via the external interface. This is useful in some scenarios for protection against external at­tacks.

14.1.2Connectivity Checks

Redundanz_Firewall-Redundanz_Konnektivitätspruefung.png

Targets can be configured for the internal and external interface in the connectivity check. It is important that these targets are actually connected to the specified interface. An ICMP echo reply cannot be received by an external interface when the corresponding target is connected to the internal interface (and vice versa). When the static routes are changed, the targets may easily not be checked properly.

Redundancy >> Firewall Redundancy >> Connectivity Checks

External Interface

Kind of check

Specifies whether a connectivity check is performed on the external interface, and if so, how.

If Ethernet link detection only is selected, then only the state of the Ethernet connection is checked.

If at least one target must respond is selected, it does not matter whether the ICMP echo request is answered by the pri­mary or secondary target.

The request is only sent to the secondary target if the primary target did not provide a suitable response. In this way, config­urations can be supported where the devices are only pro­vided with ICMP echo requests if required.

If all targets of one set must respond is selected, then both targets must respond. If a secondary target is not specified, then only the primary target must respond.

 

Connectivity check result of the external interface

Indicates whether the connectivity check was successful (green check mark).

 

Connectivity check state of the external interface

Indicates the status of the connectivity check.

Primary External Targets (for ICMP echo requests)

(Not available when Ethernet link de­tection only is selected.)

IP

This is an unsorted list of IP addresses used as targets for ICMP echo requests. We recommend using the IP addresses of routers, especially the IP addresses of default gateways or the real IP address of the other mGuard.

Default: 10.0.0.30, 10.0.0.31 (for new addresses)

Each set of targets for state synchronization can contain a maximum of ten targets.

Secondary External Targets (for ICMP echo requests)

(Not available when Ethernet link detection only is selected.)

IP

(See above)

Only used if the primary targets check has failed.

Failure of a secondary target is not detected in normal opera­tion.

Default: 10.0.0.30, 10.0.0.31 (for new addresses)

Each set of targets for state synchronization can contain a maximum of ten targets.

Internal Interface

Kind of check

Specifies whether a connectivity check is performed on the in­ternal interface, and if so, how.

If Ethernet link detection only is selected, then only the state of the Ethernet connection is checked.

Section1400636.jpg

If at least one target must respond is selected, it does not matter whether the ICMP echo request is answered by the pri­mary or secondary target.

The request is only sent to the secondary target if the primary target did not provide a suitable response. In this way, config­urations can be supported where the devices are only pro­vided with ICMP echo requests if required.

If all targets of one set must respond is selected, then both targets must respond. If a secondary target is not specified, then only the primary target must respond.

 

Connectivity check result of the internal interface

Indicates whether the connectivity check was successful (green check mark).

 

Connectivity check state of the internal interface

Indicates the status of the connectivity check.

Primary Internal Targets (for ICMP echo requests)

(Not available when Ethernet link detection only is selected.)

 

(See above)

Default: 192.168.1.30, 192.168.1.31 (for new addresses)

Secondary Internal Targets (for ICMP echo requests)

(Not available when Ethernet link detection only is selected.)

 

(See above)

Default: 192.168.1.30, 192.168.1.31 (for new addresses)

14.2Ring/Network Coupling 

 

 

inset_34.jpg 

The ring/network coupling function is not supported by the mGuard Centerport (Innominate).

Ring/network coupling with restrictions:

mGuard delta (Innominate): the internal side (switch ports) cannot be switched off.

FL MGUARD PCI 533/266: in driver mode, the internal network interface cannot be switched off (however, this is possible in Power-over-PCI mode).

14.2.1Ring/Network Coupling

Redundanz_Ring-Netzkopplung.png

Redundancy >> Firewall Redundancy >> Ring/Network Coupling

Settings

Enable ring/network coupling/dual homing

When activated, the status of the Ethernet connection is trans­mitted from one port to another in Stealth mode. This means that interruptions in the network can be traced easily.

 

Redundancy port

Internal / External

Internal: if the connection is lost/established on the LAN port, the WAN port is also disabled/enabled.

External: if the connection is lost/established on the WAN port, the LAN port is also disabled/enabled.