10Redundancy menu

 

 

inset_39.jpg 

Firewall redundancy can currently only be enabled if no VPN connections are configured on the device.

 

 

inset_40.jpg 

The firewall redundancy functions are not available on the devices of the FL MGUARD 2000 series.

 

 

inset_32.jpg 

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

 

 

inset_33.jpg 

To use the redundancy function, the same firmware must be installed on both mGuard de­vices.

 

 

inset_38.jpg 

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

Redundanz_Firewall-Redundanz_Redundanz.png

 

10.1Redundancy >> Firewall Redundancy 

10.1.1Redundancy

Redundancy >> Firewall Redundancy >> Redundancy

 

Enable redundancy

Deactivated (default): firewall redundancy is disabled.

Activated: firewall redundancy is enabled.

 

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

 

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 device that you want to be active. The device on standby is set to low.

Both devices in a redundancy pair may either be set to differ­ent priorities or to high priority. .

Section1400502.jpg

 

Passphrase for avail­ability checks

On an mGuard device which is part of a redundancy pair, checks are constantly performed to determine whether an ac­tive mGuard is available and whether it should remain active. A variation of the CARP (Common Address Redundancy Pro­tocol) 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.

Section1400504.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 286.

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 one device 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 device has been replaced, it must first be con­figured with the old password before it is connected.

 

How to proceed in the event of an incorrect password

Section1400506.jpg

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

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

Wait until the device 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 device.

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

If the other device is already using the new password, you must make sure that the device 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 device 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 device too.

Restart the device 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 (IP)

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

The active mGuard device can receive ICMP requests via this IP address. It responds to these ICMP requests according to the menu settings under Network Security >> Packet Filter >> Advanced.

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 device transmits the network mask and VLAN setting from the real external IP address to the corre­sponding virtual IP address.

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

Section1400508.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 (IP)

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

Under Internal virtual IP addresses (IP), IP addresses are defined 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 device is configured as a server for the protocols.

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.

10.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 device.

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.

Section1400510.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)

10.2Ring/Network Coupling 

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