High Availability (HA)

HA lets you deploy groups of Screens together in situations where the connection between a protected inside network and a nonsecure outside network is critical. At any time, one member of the HA cluster is the active Screen, which performs packet filtering, network address translation, logging, and encryption or decryption of packets travelling between the inside and outside networks. The other members of the HA cluster, the passive Screens, receive the same packets, perform the same calculations as the active Screen, and mirror the state of the active Screen, but they do not forward traffic.

HA Policy

When you set up an HA cluster, you designate one Screen as its primary HA Screen that is configured with the policy's configuration objects, including named Screen objects, like Address or Service with attributes that include these settings, and policy rules that the HA cluster will use. When you activate the security policy, the SunScreen EFS 3.0 and SunScreen SKIP policies are copied from the primary HA Screen to the secondary Screens in the HA cluster.

Solaris policy settings, such as network interfaces and routing configuration, are not copied from the primary Screen and must be identical on all the Screens in the HA cluster.

Because the HA cluster transmits secret keys and policies in the clear over the dedicated HA network, you must keep the HA network physically secure.

The interfaces for network connections must be the same for each HA cluster member. Similarly, you must assign all HA Screens the same IP addresses on their non-dedicated interfaces as well. The following figure shows a network protected by two Screens in an HA cluster. Each Screen in the HA cluster connects to the external and internal networks through Ethernet hubs, which pass the same signals to all HA cluster members at the same time. Each HA Screen therefore sees the same traffic, ensuring that passive Screens can duplicate the state of the packet filter engine should the active Screen fail.

Figure 2-7 Network With HA Cluster of Screens

HA Network Connections and Failovers

When the active HA cluster Screen is an x86 machine running Solaris 7, failover does not work properly. The ETHER_ADDRESS for the primary does not set correctly.

Once the HA cluster is running, the active and passive Screens poll each other every few seconds to verify connectivity and status. If the active Screen fails or becomes unavailable, the passive Screen that has been running the longest takes over as the active Screen within 15 seconds. During this time (before the passive Screen takes over), no traffic will go through the HA policy.

HA is designed to maintain the great majority of network connections. In the case of a reboot (an orderly shutdown), the active Screen being rebooted notifies the passive Screens, and the appropriate passive Screen takes over as the active Screen without loss of connections. Because the passive Screens do not forward, reject, or log packets, the load on passive Screens is less than the load on the active Screen. Consequently, load-induced faults that affect the active Screen are unlikely to affect the passive Screens.

If a failover occurs, these connections may be disrupted:

• Continued connections, for protocols that keep state (memory), such as TCP connections.

• Stateful connections, such as FTP, NFS, NIS, and RPC.

These connections may be lost if one of the following conditions occurs:

• The Screen taking over filtering does not have all the same state information when the failover condition occurs.

• Although rare, a connection through the HA cluster uses dynamic NAT and two or more connections have identical destination addresses, destination ports, or source ports.

HA automatically disconnects if it is only running on one machine, allowing it to act like a standard SunScreen EFS 3.0 Screen.

You choose to configure SunScreen EFS 3.0 as an HA cluster during installation. Alternatively, you can configure HA settings through the command line, as described in Appendix B, "Command Line Reference."

HA Alerts

Note the following HA limitations:

• HA is currently only supported in routing mode.

• HA does not work on x86 machines running Solaris 7.

• Screens in an HA cluster do not exchange state information, they independently accumulate state by processing the same packets. For optimal performance, whenever possible, it is recommended that an HA cluster comprise systems of equal size (same CPU speed, and memory size). A slower Screen in passive mode can fall behind in processing and eventually fail to have the same state as the active Screen.

• To reinstate a repaired Screen back into an HA cluster, install it as a secondary Screen and add it to the cluster.

It is not necessary to switch back to the original Screen except when its abilities or speeds are better. If they are, you can force the faster machine to take over as the active Screen, or wait until both machines have the same state because eventually the out-of-sync connections will timeout and become synchronized, then force the failover.

• Secrets are sent in the clear on the dedicated HA network. This is done intentionally to facilitate administrative communication within the HA cluster. Reserve the HA interface as a separate network from other traffic to avoid the possibility of the Screen's private certificates being discovered.

• Each Screen in an HA cluster must have a unique nodename and a unique IP address on the dedicated HA network. All other aspects of the Solaris system configurations must be identical on all Screens in the HA cluster. This includes the configuration of all network interfaces (other than the HA interface).

• HA does not work well with proxies because proxy state tables are not present on all HA machines.

• The HA Screens must be connected to each other through a shared network (such as a 10BaseT or 100BaseT hub) and not through a switched network (such as an Ethernet switch because it would send each packet to only one HA Screen, rather than to all of them).

• HA cannot be used on networks that use media other than Ethernet, such as FDDI, Token-Ring, or ATM.

• Because passive HA hosts do not generate traffic (other than automatic administrative traffic, such as HA administration and HA heartbeat), you cannot telnet into passive HA Screens. You can telnet into an active HA Screen only.

• In general, the HA cluster decides internally which member will be the active Screen. If you need to remotely administer the HA cluster, you may first need to connect to the secondary Screen and direct it to become passive so that you can communicate with the primary Screen.