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.