Setting Up High Availability

To use high availability, (you must install SunScreen as an HA system, as described in the SunScreen Installation Guide. High availability, its limitations, topology, set up, and capability are described in detail in "High Availability" in SunScreen 3.2 Administrator's Overview. For examples of HA configuration, see SunScreen 3.2 Configuration Examples manual.

The network used for HA traffic must be kept physically secure because all secret keys and configurations are transmitted in the clear over the HA interface.

HA lets you deploy multiple Screens in situations where the connection between a protected inside network and an unprotected outside network is critical. One member of the HA cluster, the active HA Screen, performs packet filtering, network address translation, logging, and encryption/decryption of packets travelling between the inside and outside networks. The other members of the HA cluster, which can be as many as 31 passive HA Screens, receive the same packets, perform the same calculations, and mirror the configuration of the active HA Screen, but they do not forward traffic between the inside network and the outside network. If the active HA Screen fails, one of the passive HA Screens takes over (failover) as the active HA Screen and begins routing and filtering network traffic within seconds. Because the passive HA Screens mirror the active HA Screen, few connections are lost if a failover occurs.

The routing interfaces of all the systems in the HA cluster have the same interface names with the same IP addresses. When a firewall becomes a secondary Screen, the MAC address of each routing interface is changed so that it is the same as the MAC address of the same interface on the primary Screen. Each HA Screen, therefore, receives the same traffic, ensuring that passive Screens can duplicate the state of the packet filter engine should the active Screen fail. The secondary firewalls have the same rules and process the packets in the same way.

Both Screens mirror configuration. They attempt to mirror state by independently building the same state table, since they see the same traffic. They do not exchange information about what is in each others' state tables, however. That means that if one Screen is rebooted, it will have the same rules, configuration, MAC addresses, etc., but will not have the same state in memory. This Screen will never learn old information from the other Screen; it will only be able to learn new information from listening on the wire. The internal state as far as memory and state tables are concerned will be out of sync for some undetermined amount of time, until all the old state entries time out or are closed from the other Screen.

HA Policy

When you set up an HA cluster, you designate one Screen as the primary HA Screen, and you configure it with the common objects and policy rules that the HA cluster will use. When you activate the policy, it is copied from the primary HA Screen to the other members of the HA cluster. The Solaris system and network configuration are not copied from the primary HA Screen; they must be identical on all the Screens in the HA cluster.

Be sure to keep the HA network physically secure. The HA cluster transmits secret keys and policies in the clear over the dedicated HA network.

The interfaces for network connections must be the same for each HA cluster member. For example, if one HA host uses the le0 interface as its dedicated internal network connection, all HA hosts must use the le0 network interface as their dedicated internal network connections. Similarly, all Screens in the HA cluster must use the same IP address on their non-dedicated interfaces.