SunScreen HA Configurations

You can configure in both routing and stealth mode. See "Routing and Stealth Mode Interfaces" for more information.

Basic SunScreen HA in Routing Mode

The figure below shows a network protected by at least two identical Screens in an HA cluster. They are administered remotely.

Figure 8-1 Network With HA Cluster of Screens

Each Screen in the HA cluster connects to the external and internal networks through Ethernet hubs, which pass the same packets to all members of the HA cluster at the same time.

The routing interfaces of all the systems in the HA cluster have the same interface names with the same IP addresses. When a Screen becomes a secondary Screen, the MAC address of its routing interfaces is changed so that it is the same as the MAC address of the corresponding 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 Screens 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 other's state tables, however. That means that when one Screen is rebooted, it has the same rules, configuration, MAC addresses, etc., but does not have the same state in memory. This Screen never learns old information from the other Screen; it only learns new information from listening on the wire. The internal state as far as memory and state tables are concerned is out of sync for some undetermined amount of time, until both systems have the same state (eventually the statetables entries of the Screens that have been up longer will time-out or terminate and the statetables will be synchronous) .

The policy is stored on the primary Screen and pushed in the clear to the secondary Screens over the dedicated network connection between the primary Screen and the secondary Screens, called the HA heartbeat network.

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

To prevent the secondary Screen from sending out duplicate packets, packet transmission is automatically disabled on their filtering interfaces.

If you are administering an HA cluster remotely, there are special considerations. Because SunScreen uses the same IP addresses on all routing interfaces, it is not possible to tell from the Administration Station which Screen you are connecting to.

If the remote Administration Station connects to the IP address 172.16.3.1, the active HA Screen responds. This could be the HA primary or an HA secondary Screen. The configuration is only present on the HA primary Screen. For this reason, you must point your browser to the HA interface, which is unique, to administer the HA primary Screen:

http://172.16.4.1:3852

To keep the HA heartbeat network private, do not broadcast Routing Information Protocol)(RIP). You must, therefore, add a static route on the remote Administration Station--by executing the Solaris command, route add net 172.16.2.0 172.16.3.1 1, for example.

If you are using NAT with HA, depending on the configuration for NAT that you are using, you must add a static address resolution protocol (ARP) entry to the primary and secondary Screens in active or passive mode so that NAT works after failover. You must replicate all non-SunScreen ARP entries, including static ARP entries, on all HA Screens. Because you must do this every time an HA Screen fails over, it is easier if you edit or create your own startup script to add the static ARP entries. See Chapter 7, Network Address Translation and the arp(1M) man page for more information.

Remotely Administered SunScreen HA Configuration in Routing or Stealth Mode

It is possible to have a dedicated ADMIN interface for all administrative traffic. The HA cluster can be set up in routing or stealth mode.

In stealth mode, you must have a separate ADMIN interface because the filtering interfaces (type STEALTH) have no IP addresses.

You must define an interface as type ADMIN on each Screen in the cluster that you want to administer and connect these ADMIN interfaces with their own network. You must configure the ADMIN interfaces under Solaris first.

By default, the only traffic a Screen allows on an ADMIN interface is the TCP ports 3852 or 3853 that remote administration uses. You must encrypt all traffic over an ADMIN port using certificates that you have defined in the Screen's configuration. The default configuration uses a remote administration rule that allows access to the Screen from any system that has a certificate in the certificate group admin-group. The Screen does not check its IP address, just its certificate.

The Administration Station must have the correct SKIP ACLs (access control lists) or the ipsecconf correctly setup to encrypt traffic to the ADMIN interfaces using the certificate defined as admin.screen_name. You can check the SKIP configuration on the Administration Station with the skiptool GUI or by looking at the file /etc/skip/acl.interface_name. See the man page for ipsecconf(1M) for information on configuring IPsec on the Administration Station.

The certificate names are the same because the secondary Screens do not have unique certificates. They have the same certificate as the primary Screen. When a policy is activated, the primary sends its private key and public key to the secondary Screens over the HA interface along with the objects and rules that are used in the policy. This information is not encrypted, so the HA interfaces should connect only to other HA interfaces and should be kept secure.

Services Allowed on The HA and ADMIN Interfaces

By default, only administrative traffic (ping and SunScreen Administration services) is allowed on the HA interface. This design keeps the network as secure as possible. However, an administrator may have some need to open up other services on this private network. This can be accomplished by adding filtering rules that include the HA network as the destination address. For example, suppose that the dedicated HA network is 172.16.0.0/24. The following policy would allow Telnet traffic to and from any address on the HA network:

edit> list interface 
qfe0 "qfe0" HA "hanetwork"  INCOMPLETE
edit> list address hanetwork
"hanetwork" RANGE 172.16.0.0/24
edit> list rule 1
1 "telnet" "hanetwork" "hanetwork" ALLOW

The destination address must be the same network object that is used in the interface definition. An equivalent object with a different name will not work. See "To Allow Non-Administrative Traffic on an HA Network" in the SunScreen 3.2 Administration Guide for more information.

Traffic allowed over the ADMIN interface is defined by the service Remote Administration, which by default is just TCP port 3852 or port 3853. To allow the Administration Station to Telnet to any of the Screens, add a filter to the Remote Administration service.

The traffic on the ADMIN interface must be encrypted. If it is not encrypted, the Screen drops it.

Before changing the default behavior, consider the security implications of opening up access to your firewall. Do you really want or need to allow access? If you decide to make changes, be sure that Administration Station is in a secure location.

Administering the Secondary Screen

You usually do not change a configuration by administering the secondary Screen. If you connect to the secondary Screen and change the configuration, you are actually editing a different policy. The policy that you are editing is usually the one created during installation to allow the primary Screen to administer the secondary Screen. If you change the configuration on the secondary Screen, the primary and secondary Screens are no longer synchronized. If you do not break the HA cluster when you change the configuration, the changed configuration will be overwritten the next time you activate a policy on the primary Screen.

Connect to the secondary Screen only to do the following:

• Perform Solaris administration, such as adding patches

• Check the HA status of the Screen

• Manually failover the Screen

• Download logs that do not exist on the primary Screen. If the primary Screen was down, the logs exist only on the secondary Screen.

• Change the policy, if the primary Screen fails and is down for an extended period.

HA Using Switches

The switch keeps a lookup table of which MAC address is attached to which physical port on the switch. It does not send packets out of the second port to a secondary Screen. This means that the hub for the HA cluster must be between the switch and the HA cluster.

Ideally, a security policy should not have a single-point of failure through which all traffic must pass. Using the same switch for both sides of the firewall, therefore, is not a good idea, even if each side of the switch is a different VLAN (virtual local area network).

You can configure some switches to work like virtual hubs. These switches work with SunScreen.