17Redundancy

There are several different ways of compensating for errors using the mGuard  so that an ex­isting connection is not interrupted.

–Firewall redundancy: two identical mGuard  devices can be combined to form a re­dundancy pair, meaning one takes over the functions of the other if an error occurs.

–VPN redundancy: an existing firewall redundancy forms the basis for VPN redundan­cy. In addition, the VPN connections are designed so that at least one mGuard  in a re­dundancy pair operates the VPN connections.

–Ring/network coupling: in ring/network coupling, another method is used. Parts of a network are designed as redundant. In the event of errors, the alternative path is select­ed.

17.1Firewall redundancy

Using firewall redundancy, it is possible to combine two identical mGuard  devices into a re­dundancy pair pair (single virtual router). One mGuard  takes over the functions of the other if an error occurs. Both mGuard  devices run synchronously, meaning an existing connection is not interrupted when the device is switched.

Figure 17-1: Firewall redundancy (example)

Basic requirements for firewall redundancy

–Only identical mGuard  devices can be used together in a redundancy pair.

–In Router network mode, firewall redundancy is only supported with “Static” Router mode.

–With mGuard  firmware Version 7.5 or later, firewall redundancy is also supported in Stealth mode, but only when stealth configuration is set to “Multiple clients”.

–For further restrictions, see “Requirements for firewall redundancy” on page 422 and “Limits of firewall redundancy” on page 432.

17.1.1Components in firewall redundancy

Firewall redundancy is comprised of several components:

–Connectivity check

Checks whether the necessary network connections have been established.

–Availability check

Checks whether an active mGuard  is available and whether this should remain active.

–State synchronization of the firewall

The mGuard  on standby receives a copy of the current firewall database state.

–Virtual network interface

Provides virtual IP addresses and MAC addresses that can be used by other devices as routes and default gateways.

–State monitoring

Coordinates all components.

–Status indicator

Shows the user the state of the mGuard .

Connectivity check

On each mGuard  in a redundancy pair, checks are constantly made as to whether a con­nection is established via which the network packets can be forwarded.

Each mGuard  checks its own internal and external network interfaces independently of each other. Both interfaces are tested for a continuous connection. This connection must be in place, otherwise the connectivity check will fail.

ICMP echo requests can also be sent (optional). The ICMP echo requests can be set via the   Redundancy >> Firewall Redundancy >> Connectivity Checks   menu.

Availability check

On each mGuard  in a redundancy pair, checks are also 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.

The active mGuard  constantly sends presence notifications via its internal and external net­work interface while both mGuard  devices listen. If a dedicated Ethernet link for state syn­chronization of the firewall is available, the presence notification is also sent via this link. In this case, the presence notification for the external network interface can also be sup­pressed.

The availability check fails if an mGuard  does not receive any presence notifications within a certain time. The check also fails if an mGuard  receives presence notifications with a lower priority than its own.

The data is always transmitted via the physical network interface and never via the virtual network interface.

State synchronization

The mGuard  on standby receives a copy of the state of the mGuard  that is currently active.

This includes a database containing the forwarded network connections. This database is filled and updated constantly by the forwarded network packets. It is protected against un­authorized access. The data is transmitted via the physical LAN interface and never via the virtual network interface.

To keep internal data traffic to a minimum, a VLAN can be configured to store the synchro­nization data in a separate multicast and broadcast domain.

Virtual IP addresses

Each mGuard  is configured with virtual IP addresses. The number of virtual IP addresses depends on the network mode used. Both mGuard  devices in a redundancy pair must be assigned the same virtual IP addresses. The virtual IP addresses are required by the mGuard  to establish virtual network interfaces.

Two virtual IP addresses are required in Router network mode, while others can be created. One virtual IP address is required for the external network interface and the other for the in­ternal network interface.

These IP addresses are used as a gateway for routing devices located in the external or in­ternal LAN. In this way, the devices can benefit from the high availability resulting from the use of both redundant mGuard  devices.

The redundancy pair automatically defines MAC addresses for the virtual network interface. These MAC addresses are identical for the redundancy pair. In Router network mode, both mGuard  devices share a MAC address for the virtual network interface connected to the ex­ternal and internal Ethernet segment.

In Router network mode, the mGuard  devices support forwarding of special UDP/TCP ports from a virtual IP address to other IP addresses, provided the other IP addresses can be reached by the mGuard . In addition, the mGuard  also masks data with virtual IP addresses when masquerading rules are set up.

State monitoring

State monitoring is used to determine whether the mGuard  is active, on standby or has an error. Each mGuard  determines its own state independently, based on the information pro­vided by other components. State monitoring ensures that two mGuard  devices are not ac­tive at the same time.

Status indicator

The status indicator contains detailed information on the firewall redundancy state. A sum­mary of the state can be called via the   Redundancy >> Firewall Redundancy >> Redun­dancy   or   Redundancy >> Firewall Redundancy >> Connectivity Checks   menu.

17.1.2Interaction of the firewall redundancy components

During operation, the components work together as follows: both mGuard  devices perform ongoing connectivity checks for both of their network interfaces (internal and external). In addition, an ongoing availability check is performed. Each mGuard  listens continuously for presence notifications (CARP) and the active mGuard  also sends them.

Based on the information from the connectivity and availability checks, the state monitoring function is made aware of the state of the mGuard  devices. State monitoring ensures that the active mGuard  mirrors its data to the other mGuard  (state synchronization).

17.1.3Firewall redundancy settings from previous versions

Existing configuration profiles for firmware Version 6.1.x (and earlier) can be imported with certain restrictions. For more information, please contact Phoenix Contact .

17.1.4Requirements for firewall redundancy

–To use the redundancy function, both mGuard  devices must have the same firmware.

–The firewall redundancy function can only be activated if a valid license key is installed.

(under:   Redundancy >> Firewall Redundancy >> Redundancy   >>  Enable redundancy )

–  Redundancy >> Firewall Redundancy >> Redundancy  >>  Interface which is used for state synchronization  

The Dedicated Interface value is only accepted on mGuard  devices which have more than two physical and separate Ethernet interfaces. This is currently the mGuard Centerport (Innominate) , FL MGUARD CENTERPORT  .

–Each set of targets for the connectivity check can contain more than ten targets. (A fail-over time cannot be guaranteed without an upper limit.)

  Redundancy >> Firewall Redundancy >> Redundancy  

–>>  External Interface  >>  Primary External Targets (for ICMP echo requests)  

–>>  External Interface  >>  Secondary External Targets (for ICMP echo requests)  

–>>  Internal Interface  >>  Primary External Targets (for ICMP echo requests)  

–>>  Internal Interface  >>  Secondary External Targets (for ICMP echo requests)  

If “at least one target must respond” or “all targets of one set must respond” is selected under   External Interface  >>  Kind of check  , then   External Interface  >>  Primary External Targets (for ICMP echo requests)  must not be empty. This also applies to the internal interface.

–In Router network mode, at least one external and one internal virtual IP address must be set. A virtual IP address cannot be listed twice.

17.1.5Fail-over switching time

The mGuard  calculates the intervals for the connectivity check and availability check auto­matically according to the variables under Fail-over switching time.

Connectivity check

The factors which define the intervals for the connectivity check are specified in Table 17-1 on page 423.

64 kB ICMP echo requests are sent for the connectivity check. They are sent on Layer 3 of the Internet protocol. When VLAN is not used, 18 bytes for the MAC header and checksum are added to this with Ethernet on Layer 2. The ICMP echo reply is the same size.

The bandwidth is also shown in Table 17-1. This takes into account the values specified for a single target and adds up the bytes for the ICMP echo request and reply.

The timeout on the mGuard  following transmission includes the following:

–The time required by the mGuard  to transmit an ICMP echo reply. If other data traffic is expected, half duplex mode is not suitable here.

–The time required for the transmission of the ICMP echo request to a target. Consider the latency during periods of high capacity utilization. This applies especially when rout­ers forward the request. The actual latency may be twice the value of the configured la­tency in unfavorable circumstances (connectivity check error).

–The time required on each target for processing the request and transmitting the reply to the Ethernet layer. Please note that full duplex mode is also used here.

–The time for transmission of the ICMP echo reply to the mGuard .

If secondary targets are configured, then additional ICMP echo requests may occasionally be sent to these targets. This must be taken into account when calculating the ICMP echo request rate.

The timeout for a single ICMP echo request is displayed in Table 17-1. This does not indi­cate how many of the responses can be missed before the connectivity check fails. The check tolerates a negative result for one of two back-to-back intervals.

Availability check

Presence notifications (CARP) are up to 76 bytes in size on Layer 3 of the Internet protocol. When VLAN is not used, 18 bytes for the MAC header and checksum are added to this with Ethernet on Layer 2. The ICMP echo reply is the same size.

Table 17-2 shows the maximum frequency at which the presence notifications (CARP) are sent from the active mGuard . It also shows the bandwidth used in the process. The fre­quency depends on the mGuard  priority and the   Fail-over switching time  .

Table 17-2 also shows the maximum latency tolerated by the mGuard  for the network that is used to transmit the presence notifications (CARP). If this latency is exceeded, the redun­dancy pair can exhibit undefined behavior.

17.1.6Error compensation through firewall redundancy

Firewall redundancy is used to compensate for hardware failures.

Figure 17-2: Possible error locations (1 ... 8)

Figure 17-2 shows a diagram containing various error locations (not related to the network mode).

Each of the mGuard  devices in a redundancy pair is located in a different area (A and B). The mGuard  in area A is connected to switch A1 through its external Ethernet interface and to switch A2 through its internal Ethernet interface. mGuard  B is connected accordingly to switches B1 and B2. In this way, the switches and mGuard  devices connect an external Ethernet network to an internal Ethernet network. The connection is established by forward­ing network packets (in Router network mode).

Firewall redundancy compensates for errors shown in Figure 17-2 if only one occurs at any given time. If two errors occur simultaneously, they are only compensated if they occur in the same area (A or B).

For example, if one of the mGuard  devices fails completely due to a power outage, then this is detected. A connection failure is compensated if the connection fails completely or par­tially. When the connectivity check is set correctly, a faulty connection caused by the loss of data packets or an excessive latency is detected and compensated. Without the connectiv­ity check, the mGuard  cannot determine which area caused the error.

A connection failure between switches on a network side (internal/external) is not compen­sated for (7 and 8 in Figure 17-2).

17.1.7Handling firewall redundancy in extreme situations

Restoration in the event of a network lobotomy

A network lobotomy occurs if a redundancy pair is separated into two mGuard  devices op­erating independently of one another. In this case, each mGuard  deals with its own tracking information as the two mGuard  devices can no longer communicate via Layer 2. A network lobotomy can be triggered by a rare and unfortunate combination of network settings, net­work failures, and firewall redundancy settings.

Each mGuard  is active during a network lobotomy. The following occurs after the network lobotomy has been rectified: if the mGuard  devices have different priorities, the device with the higher priority becomes active and the other switches to standby mode. If both mGuard  devices have the same priority, an identifier sent with the presence notifications (CARP) de­termines which mGuard  becomes active.

Both mGuard  devices manage their own firewall state during the network lobotomy. The ac­tive mGuard  retains its state. Connections on the other mGuard , which were established during the lobotomy, are dropped.

Fail-over when establishing complex connections

Complex connections are network protocols which are based on different IP connections. One example of this is the FTP protocol. In the case of FTP, the client establishes a control channel for a TCP connection. The server is then expected to open another TCP connection over which the client can then transmit data. The data channel on port 20 of the server is set up while the control channel on port 21 of the server is being established.

If the relevant connection tracking function is activated on the mGuard  (see “Advanced” on page 278), complex connections of this type are tracked. In this case, the administrator only needs to create a firewall rule on the mGuard  which allows the client to establish a control channel to the FTP server. The mGuard  enables the server to establish a data channel au­tomatically, regardless of whether the firewall rules allow for this.

The tracking of complex connections is part of the firewall state synchronization process. However, to keep the latency short, the mGuard  forwards the network packets inde­pendently of the firewall state synchronization update that has been triggered by the net­work packets themselves.

Therefore, it may be the case for a very brief period that a state change for the complex con­nection is not forwarded to the mGuard  on standby if the active mGuard  fails. In this case, tracking of the connection from the mGuard  which is active after the fail-over is not contin­ued correctly. This cannot be corrected by the mGuard . The data link is then reset or inter­rupted.

Fail-over when establishing semi-unidirectional connections

A semi-unidirectional connection refers to a single IP connection (such as UDP connec­tions) where the data only travels in one direction after the connection is established with a bidirectional handshake.

The data flows from the responder to the initiator. The initiator only sends data packets at the very start.

The following applies only to certain protocols which are based on UDP. Data always flows in both directions on TCP connections.

If the firewall of the mGuard  is set up to only accept data packets from the initiator, the fire­wall accepts all related responses per se. This happens regardless of whether or not a rel­evant firewall rule is available.

A scenario is conceivable in which the mGuard  allows the initiating data packet to pass through and then fails before the relevant connection entry has been made in the other mGuard . The other mGuard  may then reject the responses as soon as it becomes the active mGuard .

The mGuard  cannot correct this situation due to the single-sided connection. As a counter­measure, the firewall can be configured so that the connection can be established in both directions. This is normally already handled via the protocol layer and no additional assign­ment is required.

Loss of data packets during state synchronization

If data packets are lost during state synchronization, this is detected automatically by the mGuard , which then requests the active mGuard  to send the data again.

This request must be answered within a certain time, otherwise the mGuard  on standby is assigned the “outdated” state and asks the active mGuard  for a complete copy of all state information.

The response time is calculated automatically from the fail-over switching time. This is lon­ger than the time for presence notifications (CARP), but shorter than the upper limit of the fail-over switching time.

Loss of presence notifications (CARP) during transmission

A one-off loss of presence notifications (CARP) is tolerated by the mGuard , but it does not tolerate the loss of subsequent presence notifications (CARP). This applies to the availabil­ity check on each individual network interface, even when these are checked simultane­ously. It is therefore very unlikely that the availability check will fail as a result of a very brief network interruption.

Loss of ICMP echo requests/replies during transmission

ICMP echo requests or replies are important for the connectivity check. Losses are always observed, but are tolerated under certain circumstances.

The following measures can be used to increase the tolerance level for ICMP echo re­quests.

–Select at least one target must respond under Kind of check in the   Redundancy >> Firewall Redundancy >> Connectivity Checks  menu.

–Also define a secondary set of targets here. The tolerance level for the loss of ICMP echo requests can be further increased by entering the targets of unreliable connec­tions under both sets (primary and secondary) or listing them several times within a set.

Restoring the primary mGuard   following a failure

If a redundancy pair is defined with different priorities, the secondary mGuard  becomes ac­tive if the connection fails. The primary mGuard  becomes active again after the failure has been rectified. The secondary mGuard  receives a presence notification (CARP) and returns to standby mode.

State synchronization

If the primary mGuard  becomes active again after a failure of the internal network connec­tion, it may contain an obsolete copy of the firewall database. This database must, there­fore, be updated before the connection is reestablished. The primary mGuard  ensures that it receives an up-to-date copy before becoming active.

17.1.8Interaction with other devices

Virtual and real IP addresses

With firewall redundancy in Router network mode, the mGuard  uses real IP addresses to communicate with other network devices.

Virtual IP addresses are used in the following two cases:

–Virtual IP addresses are used when establishing and operating VPN connections.

–If DNS and NTP services are used according to the configuration, they are offered to internal virtual IP addresses.

The use of real (management) IP addresses is especially important for the connectivity check and availability check. Therefore, the real (management) IP address must be config­ured so that the mGuard  can establish the required connections.

The following are examples of how and why mGuard  communication takes place:

–Communication with NTP servers to synchronize the time

–Communication with DNS servers to resolve host names (especially those from VPN partners)

–To register its IP address with a DynDNS service

–To send SNMP traps

–To forward log messages to a SysLog server

–To download a CRL from an HTTP(S) server

–To authenticate a user via a RADIUS server

–To download a configuration profile via an HTTPS server

–To download a firmware update from an HTTPS server

With firewall redundancy in Router network mode, devices connected to the same LAN seg­ment as the redundancy pair must use their respective virtual IP addresses as gateways for their routes. If these devices were to use the actual IP address of either of the mGuard  de­vices, this would work until that particular mGuard  failed. However, the other mGuard  would then not be able to take over.

Targets for the connectivity check

If a target is set for ICMP echo requests as part of the connectivity check, these requests must be answered within a certain time, even if the network is busy with other data. The net­work path between the redundancy pair and these targets must be set so that it is also able to forward the ICMP responses when under heavy load. Otherwise, the connectivity check for an mGuard  could erroneously fail.

Targets can be configured for the internal and external interface in the connectivity check (see “Connectivity Checks” on page 405). It is important that these targets are actually con­nected to the specified interface. An ICMP echo reply cannot be received by an external in­terface when the target is connected to the internal interface (and vice versa). When the static routes are changed, it is easy to forget to adjust the configuration of the targets ac­cordingly.

The targets for the connectivity check should be well thought out. Without a connectivity check, all it takes are two errors for a network lobotomy to occur.

A network lobotomy is prevented if the targets for both mGuard  devices are identical and all targets have to answer the request. However, the disadvantage of this method is that the connectivity check fails more often if one of the targets does not offer high availability.

In Router network mode, we recommend defining a high-availability device as the target on the external interface. This can be the default gateway for the redundancy pair (e.g., a virtual router comprised of two independent devices). In this case, either no targets or a se­lection of targets should be defined on the internal interface.

Please also note the following information when using a virtual router consisting of two in­dependent devices as the default gateway for a redundancy pair. If these devices use VRRP to synchronize their virtual IP, then a network lobotomy could split the virtual IP of this router into two identical copies. These routers could use a dynamic routing protocol and only one may be selected for the data flows of the network being monitored by the mGuard . Only this router should keep the virtual IP. Otherwise, you can define targets which are ac­cessible via this route in the connectivity check. In this case, the virtual IP address of the router would not be a sensible target.

Redundancy group

Several redundancy pairs can be connected within a LAN segment (redundancy group). You define a value as an identifier (using the router ID) for each virtual instance of the redun­dancy pair. As long as these identifiers are different, the redundancy pairs do not come into conflict with each other.

Data traffic

In the event of a high latency in a network used for state synchronization updates or a seri­ous data loss on this network, the mGuard  on standby is assigned the “outdated” state. This does not occur, however, as long as no more than two back-to-back updates are lost. This is because the mGuard  on standby automatically requests a repeat of the update. The la­tency requirements are the same as those detailed under “Fail-over switching time” on page 423.

Sufficient bandwidth

The data traffic generated as a result of the connectivity check, availability check, and state synchronization uses bandwidth in the network. The connectivity check also generates complicated calculations. There are several ways to limit this or stop it completely.

If the impact on other devices is unacceptable:

–The connectivity check must either be deactivated, or must only relate to the actual IP address of the other mGuard  .

–The data traffic generated by the availability check and state synchronization must be moved to a separate VLAN.

–Switches must be used which allow separation of the VLANs.

Dedicated interface

The mGuard Centerport (Innominate)  / FL MGUARD CENTERPORT  supports a dedicated interface. This is a reserved, direct Ethernet interface or a dedicated LAN segment, via which the state synchronization is sent. This separates the load physically from the internal LAN segment.

17.1.9Transmission capacity with firewall redundancy

These values apply to Router network mode when the data traffic for state synchronization is transmitted without encryption. If the transmission capacity described here is exceeded, in the event of errors the switching time may be longer than that set.

Fail-over switching time

The fail-over switching time can be set to 1, 3 or 10 seconds in the event of errors.

The upper limit of 1 second is currently only adhered to by the mGuard Centerport (Innominate) , FL MGUARD CENTERPORT , even under high load.

17.1.10Limits of firewall redundancy

–In Router network mode, firewall redundancy is only supported with “Static” mode.

–Access to the mGuard  via the HTTPS, SNMP, and SSH management protocols is only possible with a real IP address from each mGuard . Attempts to access virtual ad­dresses are rejected.

–The following features cannot be used with firewall redundancy.

–A secondary external Ethernet interface

–A DHCP server

–A DHCP relay

–A SEC-Stick server

–A user firewall

–CIFS Integrity Monitoring

–The redundancy pair must have the same configuration. Take this into account when making the following settings:

–NAT settings (masquerading, port forwarding, and 1:1 NAT)

–Flood protection

–Packet filter (firewall rules, MAC filter, advanced settings)

–Queues and rules for QoS

–Some network connections may be interrupted following a network lobotomy. (See “Restoration in the event of a network lobotomy” on page 426.)

–After a fail-over, semi-unidirectional or complex connections that were established in the second before the fail-over may be interrupted. (See “Fail-over when establishing complex connections” on page 426 and “Fail-over when establishing semi-unidirection­al connections” on page 426.)

–Firewall redundancy does not support the FL MGUARD PCI 533/266  in Driver mode.

–State synchronization does not replicate the connection tracking entries for ICMP echo requests forwarded by the mGuard . Therefore, ICMP echo replies can be dropped ac­cording to the firewall rules if they only reach the mGuard  after the fail-over is complet­ed. Please note that ICMP echo replies are not suitable for measuring the fail-over switching time.

–Masquerading involves hiding the transmitter behind the first virtual IP address or the first internal IP address. This is different to masquerading on the mGuard  without fire­wall redundancy. When firewall redundancy is not activated, the external or internal IP address hiding the transmitter is specified in a routing table.

17.2VPN redundancy

VPN redundancy can only be used together with firewall redundancy.

The concept is the same as for firewall redundancy. In order to detect an error in the system environment, the activity is transmitted from the active mGuard  to the mGuard  on standby.

At any given point in time, at least one mGuard  in the redundancy pair is operating the VPN connection (except in the event of a network lobotomy).

Basic requirements for VPN redundancy

VPN redundancy does not have any of its own variables. It currently does not have its own menu in the user interface – it is activated together with firewall redundancy instead.

VPN redundancy can only be used if the corresponding license has been purchased and installed on the mGuard .

As VPN connections must be established for VPN redundancy, a corresponding VPN li­cense is also necessary.

If you only have the license for firewall redundancy and VPN connections are installed, VPN redundancy cannot be activated. An error message is displayed as soon as an attempt is made to use firewall redundancy.

Only identical mGuard  devices can be used together in a redundancy pair.

17.2.1Components in VPN redundancy

The components used in VPN redundancy are the same as described under firewall redun­dancy. One additional component is available here – VPN state synchronization. A small number of components are slightly extended for VPN redundancy. However, the connectiv­ity check, availability check, and firewall state synchronization are all performed in the same way as before.

VPN state synchronization

The mGuard  supports the configuration of firewall rules for the VPN connection.

VPN state synchronization monitors the state of the different VPN connections on the active mGuard . It ensures that the mGuard  on standby receives a valid, up-to-date copy of the VPN state database.

As with state synchronization of the firewall, VPN state synchronization sends updates from the active mGuard  to the mGuard  on standby. If requested to do so by the mGuard  on standby, the active mGuard  sends a complete record of all state information.

Dedicated interface (mGuard Centerport (Innominate) , FL MGUARD CENTERPORT )

In the case of the mGuard Centerport (Innominate) , FL MGUARD CENTERPORT  , you can permanently assign the third Ethernet interface for VPN state synchronization.

As with the state synchronization of the firewall, the data traffic for VPN state synchroniza­tion for the dedicated interface is transmitted when a variable is set. Under   Redundancy >> Firewall Redundancy >> Redundancy  set the  Interface which is used for state synchroniza­tion   to Dedicated Interface.

Establishing VPN connections

In VPN redundancy, the virtual network interface is used for an additional purpose – to es­tablish, accept, and operate VPN connections. The mGuard  only listens for the first virtual IP address.

In Router network mode, it listens at the first external and internal virtual IP addresses.

State monitoring

State monitoring is used to monitor state synchronization on both the VPN and firewall.

Status indicator

The status indicator shows additional detailed information on the status of VPN state syn­chronization. This is located directly next to the information for firewall state synchroniza­tion.

As an ancillary effect, the status indicator of the VPN connection can also be seen on the mGuard  on standby. You can therefore find the contents of the VPN state database repli­cated under the normal status indicator for the VPN connection (under   IPsec VPN >> IPsec Status ).

Only the state of the synchronization process is shown in the status indicator for firewall re­dundancy ().

17.2.2Interaction of the VPN redundancy components

The individual components interact in the same way as described for firewall redundancy. VPN state synchronization is also controlled by state monitoring. The state is recorded and updates are sent.

Certain conditions must be met for the states to occur. VPN state synchronization is taken into account here.

17.2.3Error compensation through VPN redundancy

VPN redundancy compensates for the exact same errors as firewall redundancy (see “Error compensation through firewall redundancy” on page 425).

However, the VPN section can hinder the other VPN gateways in the event of a network lo­botomy. The independent mGuard  devices then have the same virtual IP address for com­municating with the VPN partners. This can result in VPN connections being established and disconnected in quick succession.

17.2.4Setting the variables for VPN redundancy

If the required license keys are installed, VPN redundancy is automatically activated at the same time as firewall redundancy. This occurs as soon as   Enable redundancy   is set to Yes in the   Redundancy >> Firewall Redundancy >> Redundancy   menu.

There is no separate menu for VPN redundancy. The existing firewall redundancy variables are extended.

17.2.5Requirements for VPN redundancy

–VPN redundancy can only be activated if a license key is installed for VPN redundancy and a VPN connection is activated.

–Only for TC MGUARD RS4000 3G , TC MGUARD RS4000 4G , FL MGUARD RS4004 , FL MGUARD RS4000 , FL MGUARD GT/GT , and FL MGUARD RS  

If a VPN connection is controlled via a VPN switch, then VPN redundancy cannot be activated.

(under:  IPsec VPN >> Global >> Options  >> VPN Switch)

During VPN state synchronization, the state of the VPN connection is sent continuously from the active mGuard  to the one on standby so that it always has an up-to-date copy in the event of errors. The only exception is the state of the IPsec replay window. Changes there are only transmitted sporadically.

The volume of the data traffic for state synchronization does not depend on the data traffic sent over the VPN tunnels. The data volumes for state synchronization are defined by a range of parameters that are assigned to the ISAKMP SAs and IPsec SAs.

17.2.6Handling VPN redundancy in extreme situations

The conditions listed under “Handling firewall redundancy in extreme situations” on page 426 also apply to VPN redundancy. They also apply when the mGuard  is used exclu­sively for forwarding VPN connections. The mGuard  forwards the data flows via the VPN tunnels and rejects incorrect packets, regardless of whether firewall rules have been de­fined for the VPN connections or not.

An error interrupts the flow of data traffic

An error that interrupts the data traffic running via the VPN tunnels represents an extreme situation. In this case, the IPsec data traffic is briefly vulnerable to replay attacks. (A replay attack is the repetition of previously sent encrypted data packets using copies which have been saved by the attacker.) The data traffic is protected by sequential numbers. Indepen­dent sequential numbers are used for each direction in an IPsec tunnel. The mGuard  drops ESP packets which have the same sequential number as a packet that has already been decrypted for a specific IPsec tunnel by the mGuard . This mechanism is known as the IPsec replay window.

The IPsec replay window is only replicated sporadically during state synchronization, as it is very resource-intensive. Therefore, the active mGuard  may have an obsolete IPsec re­play window following a fail-over. An attack is then possible until the real VPN partner has sent the next ESP packet for the corresponding IPsec SA, or until the IPsec SA has been renewed.

To avoid having an insufficient sequential number for the outgoing IPsec SA, VPN redun­dancy adds a constant value to the sequential number for each outgoing IPsec SA before the mGuard  becomes active. This value is calculated so that it corresponds to the maximum number of data packets which can be sent through the VPN tunnel during the maximum fail-over switching time. At worst (1 Gigabit Ethernet and a switching time of 10 seconds), this is 0.5% of an IPsec sequence. At best, this is only one per thousand.

Adding a constant value to the sequential number prevents the accidental reuse of a se­quential number already used by the other mGuard  shortly before it failed. Another effect is that ESP packets sent from the previously active mGuard  are dropped by the VPN partner if new ESP packets are received earlier from the mGuard  that is currently active. To do this, the latency in the network must differ from the fail-over switching time.

An error interrupts the initial establishment of the ISAKMP SA or IPsec SA

If an error interrupts the initial establishment of the ISAKMP SA or IPsec SA, the mGuard  on standby can continue the process seamlessly, as the state of the SA is replicated synchro­nously. The response to an IKE message is only sent from the active mGuard  after the mGuard  on standby has confirmed receipt of the corresponding VPN state synchronization update.

When an mGuard  becomes active, it immediately repeats the last IKE message which should have been sent from the previously active mGuard . This compensates for cases where the previously active mGuard  has sent the state synchronization but has failed before it could send the corresponding IKE message.

In this way, the establishment of the ISAKMP SA or IPsec SA is only delayed by the switch­ing time during a fail-over.

An error interrupts the renewal of an ISAKMP SA

If an error interrupts the renewal of an ISAKMP SA, this is compensated in the same way as during the initial establishment of the SA. The old ISAKMP SA is also kept for Dead Peer Detection until the renewal of the ISAKMP SA is complete.

An error interrupts the renewal of an IPsec SA

If an error interrupts the renewal of an IPsec SA, this is compensated in the same way as during the initial establishment of the SA. Until renewal of the ISAKMP SA is complete, the old outgoing and incoming IPsec SAs are retained until the VPN partner notices the change.

VPN state synchronization ensures that the old IPsec SAs are retained throughout the entire time that the mGuard  remains on standby. When the device becomes active, it can then continue with the encryption and decryption of the data traffic without the need for further action.

Loss of data packets during VPN state synchronization

State synchronization can cope with the loss of one of two back-to-back update packets. If more data packets are lost, this can result in a longer switching time in the event of errors.

The mGuard  on standby has an obsolete machine certificate

X.509 certificates and private keys used by a redundancy pair to authenticate itself as a VPN partner may need to be changed. The combination of a private key and certificate is hereinafter referred to as a machine certificate.

Each mGuard  in a redundancy pair must be reconfigured in order to switch the machine cer­tificate. Both mGuard  devices also require the same certificate so that their VPN partners view them as one and the same virtual VPN appliance.

As each mGuard  has to be reconfigured individually, it may be the case that the mGuard  on standby has an obsolete machine certificate for a brief period.

If the mGuard  on standby becomes active at the exact moment when the ISAKMP SAs are being established, this procedure cannot be continued with an obsolete machine certificate.

As a countermeasure, VPN state synchronization replicates the machine certificate from the active mGuard  to the mGuard  on standby. In the event of a fail-over, the mGuard  on standby will only use this to complete the process of establishing the ISAKMP SAs where this has already been started.

If the mGuard  on standby establishes new ISAKMP SAs after a fail-over, it uses the ma­chine certificate that has already been configured.

VPN state synchronization therefore ensures that the currently used machine certificates are replicated. However, it does not replicate the configuration itself.

The mGuard  on standby has an obsolete pre-shared key (PSK)

Pre-shared keys (PSK) also need to be renewed on occasion in order to authenticate VPN partners. The redundant mGuard  devices may then have a different PSK for a brief period. In this case, only one of the mGuard  devices can establish a VPN connection as most VPN partners only accept one PSK. The mGuard  does not offer any countermeasures for this.

If VPN state synchronization replicates the PSKs being sent to the mGuard  on standby for a prolonged period, an incorrect configuration remains concealed during this period, mak­ing it difficult to detect.

17.2.7Interaction with other devices

Resolving host names

If host names are configured as VPN gateways, the mGuard  devices in a redundancy pair must be able to resolve the host names for the same IP address. This applies especially when   DynDNS Monitoring   (see   page 319  ) is activated.

If the host names are resolved from the mGuard  on standby to another IP address, the VPN connection to this host is interrupted following a fail-over. The VPN connection is reestab­lished through another IP address. This takes place directly after the fail-over. However, a short delay may occur, depending (among other things) on what value is entered under   Dy­nDNS Monitoring   for the  Refresh interval  .

Obsolete IPsec replay window

IPsec data traffic is protected against unauthorized access. To this end, each IPsec tunnel is assigned an independent sequential number. The mGuard  drops ESP packets which have the same sequential number as a packet that has already been decrypted for a specific IPsec tunnel by the mGuard . This mechanism is known as the IPsec replay window. It pre­vents replay attacks, where an attacker sends previously recorded data to simulate some­one else's identity.

The IPsec replay window is only replicated sporadically during state synchronization, as it is very resource-intensive. Therefore, the active mGuard  may have an obsolete IPsec re­play window following a fail-over. This means that a replay attack is possible for a brief pe­riod until the real VPN partner has sent the next ESP packet for the corresponding IPsec SA, or until the IPsec SA has been renewed. However, the traffic must be captured completely for this to occur.

Dead Peer Detection

Please note the following point for Dead Peer Detection.

Otherwise, the VPN partners may think that the redundancy pair is dead, even though it is only dealing with a fail-over.

Data traffic

In the event of a high latency in a network used for state synchronization updates, the mGuard  on standby is assigned the “outdated” state. The same thing also happens in the event of serious data losses on this network.

This does not occur, however, as long as no more than two back-to-back updates are lost. This is because the mGuard  on standby automatically requests a repeat of the update. The latency requirements are the same as those detailed under “Fail-over switching time” on page 423.

Real IP addresses

VPN partners may not send ESP traffic to the real IP address of the redundancy pair. VPN partners must always use the virtual IP address of the redundancy pair to send IKE mes­sages or ESP traffic.

17.2.8Transmission capacity with VPN redundancy

These values apply to Router network mode when the data traffic for state synchronization is transmitted without encryption. If the transmission capacity described here is exceeded, in the event of errors the switching time may be longer than that set.

Fail-over switching time

The fail-over switching time can be set to 1, 3 or 10 seconds in the event of errors.

The upper limit of 1 second is currently only adhered to by the mGuard Centerport (Innominate) , FL MGUARD CENTERPORT , even under high load.

17.2.9Limits of VPN redundancy

The limits documented above for firewall redundancy also apply to VPN redundancy (see “Limits of firewall redundancy” on page 432). Further restrictions also apply.

–The redundancy pair must have the same configuration with respect to the following:

–General VPN settings

–Each individual VPN connection

–The mGuard  only accepts VPN connections to the first virtual IP address.

–In Router network mode, this means the first internal IP address and the first exter­nal IP address.

–The following features cannot be used with VPN redundancy:

–Dynamic activation of the VPN connections using a VPN switch or the CGI script command nph-vpn.cgi (only on TC MGUARD RS4000 3G , TC MGUARD RS4000 4G , FL MGUARD RS4004 , and FL MGUARD RS4000 )

–Archiving of diagnostic messages for VPN connections

–VPN connections are only supported in Tunnel mode. Transport mode does not take sufficient account of VPN connections.

–The upper limit of the fail-over switching time does not apply to connections which are encapsulated with TCP. Connections of this type are interrupted for a prolonged period during a fail-over. The encapsulated TCP connections must be reestablished by the initiating side after each fail-over. If the fail-over occurred on the initiating side, they can start immediately after the transfer. However, if the fail-over occurred on the an­swering side, the initiator must first detect the interruption and then reestablish the con­nection.

–VPN redundancy supports masquerading in the same way as without VPN redundan­cy. This applies when a redundancy pair is masked by a NAT gateway with a dynamic IP address.

For example, a redundancy pair can be hidden behind a DSL router, which masks the redundancy pair with an official IP address. This DSL router forwards the IPsec data traffic (IKE and ESP, UDP ports 500 and 4500) to the virtual IP addresses. If the dy­namic IP address changes, all active VPN connections which run via the NAT gateway are reestablished.

The connections are reestablished by means of Dead Peer Detection (DPD) using the relevant configured time. This effect is beyond the influence of the mGuard .

–The redundancy function on the mGuard  does not support path redundancy. Path re­dundancy can be achieved using other methods, e.g., by using a router pair. This router pair is seen on the virtual side of the mGuard  devices. By contrast, on the other side, each of the routers has different connections.

Path redundancy must not use NAT mechanisms such as masquerading to hide the vir­tual IP addresses of the mGuard  devices. Otherwise, a migration from one path to an­other would change the IP addresses used to mask the redundancy pair. This would mean that all VPN connections (all ISAKMP SAs and all IPsec SAs) would have to be reestablished.

The connections are reestablished by means of Dead Peer Detection (DPD) using the relevant configured time. This effect is beyond the influence of the mGuard .

–In the event of path redundancy caused by a network lobotomy, the VPN connections are no longer supported. A network lobotomy must be prevented whenever possible.

X.509 certificates for VPN authentication

The mGuard  supports the use of X.509 certificates when establishing VPN connections. This is described in detail under “Authentication” on page 342.

However, there are some special points to note when X.509 certificates are used for authen­ticating VPN connections in conjunction with firewall redundancy and VPN redundancy.

Switching machine certificates

A redundancy pair can be configured so that it uses an X.509 certificate and the correspond­ing private key together to identify itself to a remote VPN partner as an individual virtual VPN instance.

These X.509 certificates must be renewed regularly. If the VPN partner is set to check the validity period of the certificates, these certificates must be renewed before their validity ex­pires (see “Certificate Settings” on page 248).

If a machine certificate is replaced, all VPN connections which use it are restarted by the mGuard . While this is taking place, the mGuard  cannot forward any data via the affected VPN connections for a certain period of time. This period depends on the number of VPN connections affected, the performance of the mGuard  and VPN partners, and the latency of the mGuard  devices in the network.

If this is not feasible for redundancy, the VPN partners of a redundancy pair must be config­ured so that they accept all certificates whose validity is confirmed by a set of specific CA certificates (see “CA Certificates” on page 252 and “Authentication” on page 342).

If the new machine certificate is issued from a different sub-CA certificate, the VPN partner must be able to recognize this before the redundancy pair can use the new machine certif­icate.

The machine certificate must be replaced on both mGuard  devices in a redundancy pair. However, this is not always possible if one cannot be reached. This might be the case in the event of a network failure, for example. The mGuard  on standby may then have an obsolete machine certificate when it becomes active. This is another reason for setting the VPN part­ners so that they use both machine certificates.

The machine certificate is normally also replicated with the corresponding key during VPN state synchronization. In the event of a fail-over, the other mGuard  can take over and even continue establishing incomplete ISAKMP SAs.

Switching the remote certificates for a VPN connection

The mGuard  can be set to authenticate VPN partners directly using the X.509 certificates shown by these VPN partners. For this to happen, the relevant X.509 certificate must be set on the mGuard . This is known as the   Remote CA certificate  .

If a remote certificate is renewed, for a brief period, only one of the mGuard  devices will have a new certificate. We therefore recommend authenticating the VPN partners using CA cer­tificates instead of remote certificates in VPN redundancy.

Adding a new CA certificate to identify VPN partners

The mGuard  can be set to authenticate VPN partners using CA certificates (see “CA Certif­icates” on page 252 and “Authentication” on page 342).

With this setting, a new CA certificate can be added without affecting the established VPN connections. However, the new CA certificates are used immediately. The X.509 certificate used by the VPN partner to authenticate itself to the mGuard  can then be replaced with min­imal interruption. The only requirement is ensuring that the new CA certificate is available first.

The mGuard  can be set to check the validity period of the certificates provided by the VPN partner (see “Certificate Settings” on page 248). In this case, new trusted CA certificates must be added to the mGuard  configuration. These certificates should also have a validity period.

If CRL checking is activated (under   Authentication >> Certificates >> Certificate Settings ), one URL (where the corresponding CRL is available) must be maintained for each CA cer­tificate. The URL and CRL must be published before the mGuard  uses the CA certificates in order to confirm the validity of the certificates shown by the VPN partners.

Using X.509 certificates with limited validity periods and CRL checking

The use of X.509 certificates is described under “Certificate Settings” on page 248 (  “Au­thentication >> Certificates >> Certificate Settings”    menu).

If X.509 certificates are used and Check the validity period of certificates and CRLs is set, the system time has to be correct. We recommend synchronizing the system time using a trusted NTP server. Each mGuard  in a redundancy pair can use the other as an additional NTP server, but not as the only NTP server.