Using HP-UX IPFilter with MC/ServiceGuard

HP-UX IPFilter supports local failover in an MC/ServiceGuard environment.




	CAUTION: NAT functionality is not supported with MC/ServiceGuard.

Local Failover




	NOTE: Refer to the MC/ServiceGuard documentation for information on configuring a local failover system in MC/ServiceGuard.

IPFilter local failover is transparent to users. Network sessions are not disrupted during failover or failback.

You do not need to configure any additional rules in IPFilter. When an interface fails over, the HP-UX IPFilter rules that specify interface names are automatically changed.

For example, a node in an MC/ServiceGuard cluster has a primary interface named lan0 and a standby interface named lan1. The following rule is configured for lan0:

pass in on lan0 proto tcp from any to any port = telnet

Upon failover, the rule is automatically modified to:

pass in on lan1 proto tcp from any to any port = telnet

The rule will be changed back automatically on failback.

All rules that filter on interface names are changed at failover and failback in both the active ruleset and the inactive ruleset. In addition, logging reflects the changes; the standby interface name will appear in logs and reports when it is in use.

Remote Failover

HP-UX IPFilter is a system firewall and as such should be installed on end systems. Connections to an IPFilter system that are lost during a remote failover must be reinitiated.

Install and configure HP-UX IPFilter on each node of an MC/ServiceGuard cluster that must be protected. The IPFilter configuration for the primary node might be different from the configuration for the backup nodes.

For example, the backup node might be multi-homed and require a different rule set. Also, rules could be configured to filter on the static IP address of the receiving node that would be different for each node in the cluster. Rules that filter on interface names will also be different on different nodes in a cluster.

Filtering on a Package IP Address

HP-UX IPFilter can filter on a package IP address. The package IP address is an IP address that corresponds to a logical network interface.

For example, a telnet connection is made to the primary cluster node with a package IP address of 17.13.24.105. You want to configure IPFilter to let telnet traffic through. Configure the following rule for incoming telnet connections made to the telnet package:

pass in proto tcp from any to 17.13.24.105 flags S keep state

You can replace 17.13.24.105 with the package name in this rule if the package has been configured properly and has a DNS entry.

Configure this rule on the backup nodes as well. This ensures that when the telnet package fails to a backup, there is a rule on the backup that lets telnet connections pass through as required.

This type of configuration can be used with any package.

Mandatory Rules

Each node in an MC/ServiceGuard cluster has specific rules that must be configured. These rules ensure that:

Normal remote failovers are not disrupted.
No false remote failovers occur because traffic is blocked by IPFilter that should not be blocked.

The classes of mandatory rules cover:

Intra-Cluster Communication
Quorum Server
Remote Command Execution
Cluster Object Manager
ServiceGuard Manager

The following services should not be blocked:

hacl-qs  1238/tcp	   # High Availability (HA) Quorum Server
clvm-cfg 1476/tcp   # HA LVM configuration
hacl-hb  5300/tcp	   # High Availability (HA) Cluster heartbeat
hacl-hb  5300/udp	   # High Availability (HA) Cluster heartbeat
hacl-gs  5301/tcp   # HA Cluster General Services
hacl-cfg 5302/tcp   # HA Cluster TCP configuration
hacl-cfg 5302/udp   # HA Cluster UDP configuration
hacl-probe 5303/tcp # HA Cluster TCP probe
hacl-probe 5303/udp # HA Cluster UDP probe
hacl-local 5304/tcp # HA Cluster commands
hacl-test  5305/tcp # HA Cluster test
hacl-dlm   5408/tcp # HA Cluster distributed lock manager




	NOTE: This list of HA services is not exhaustive. In addition, MC/ServiceGuard also uses dynamic ports (typically in the 49152-65535 range) for some cluster services. If you have adjusted the dynamic port range using kernel tunable parameters, alter your rules accordingly. This list does not include all HA applications (such as Continental Cluster). New HA applications might be developed that use port numbers different from those previously listed. You must add new rules as appropriate to ensure that all HA applications run properly. The current list of ports used by MC/ServiceGuard are documented in the MC/ServiceGuard Release Notes.

Intra-Cluster Communication

To ensure proper operation of your MC/ServiceGuard cluster, each of the configured MC/ServiceGuard heartbeat subnets must allow intra-cluster communication. The following rules must be applied to each subnet.

For a simplified HP-UX IPFilter configuration, use the following rules:

pass in quick from <clusternodes> to any

pass out quick from any to <clusternodes>

For more restrictive HP-UX IPFilter configurations, use the following rules to allow only the required cluster services to pass through:

pass in quick proto tcp from <clusternodes> to <clusternodes> port 5299 >< 5305 flags S keep state

pass in quick proto udp from <clusternodes> to <clusternodes> port = 5300 keep state

pass in quick proto udp from <clusternodes> to <clusternodes> port = 5302 keep state

pass in quick proto tcp from <clusternodes> to <clusternodes> port = 5408 flags S keep state

pass in quick proto tcp from <clusternodes> to <clusternodes> port 49151><65536 keep state

pass in quick proto udp from <clusternodes> to <clusternodes> port 49151><65536 keep state

pass out quick proto tcp from <clusternodes> to <clusternodes> port 5299 >< 5305 flags S keep state

pass out quick proto udp from <clusternodes> to <clusternodes> port = 5300 keep state

pass out quick proto udp from <clusternodes> to <clusternodes> port = 5302 keep state

pass out quick proto tcp from <clusternodes> to <clusternodes> port = 5408 flags S keep state

pass out quick proto tcp from <clusternodes> to <clusternodes> port 49151><65536 keep state

pass out quick proto udp from <clusternodes> to <clusternodes> port 49151><65536 keep state

In the previous set of rules, <clusternodes> are all nodes in the cluster, including the local node.

Running the cmscancl command requires the “shell” port be open.

Quorum Server

If your MC/ServiceGuard configuration uses a Quorum Server, each node in the cluster must have the following rule configured:

pass out quick proto tcp from <clusternodes> to <quorumserver> port = 1238 flags S keep state

Any node providing Quorum Service for another cluster must have the following rule configured:

pass in quick proto tcp from <clusternodes> to <quorumserver> port = 1238 flags S keep state

In the previous set of rules, <clusternodes> are all nodes in the cluster utilizing the Quorum Service and <quorumserver> is the IP address used to access the MC/ServiceGuard Quorum Service software.

Remote Command Execution

If you want nodes outside the cluster to execute MC/ServiceGuard commands, as specified in the etc/cmcluster/cmclnodelist file, additional rules are required.

Each node in the cluster must have the following rules configured:

pass in quick proto tcp from <remotenodes> to <clusternodes> port = 5302 flags S keep state

pass in quick proto udp from <remotenodes> to <clusternodes> port = 5302 keep state

pass out quick proto tcp from <clusternodes> to <remote node name> port 49151><65536 keep state

pass out quick proto udp from <clusternodes> to <remote node name> port 49151><65536 keep state

Each remote node must have the following rules configured:

pass in quick proto tcp from <clusternodes> to <remote node name> port 49151 >< 65536 keep state

pass in quick proto udp from <clusternodes> to <remote node name> port 49151 >< 65536 keep state

pass out quick proto tcp from <remotenodes> to <clusternodes> port = 5302 flags S keep state

pass out quick proto udp from <remotenodes> to <clusternodes> port = 5302 keep state

In the previous set of rules, <clusternodes> are all nodes in the cluster, <remote node name> is the specific remote node, and <remotenodes> are all other nodes outside the cluster that are designated in the cmclnodelist file for remote command access.

Running the cmscancl command requires the “shell” port be open.

Cluster Object Manager

If you are using a Cluster Object Manager (COM) on a node outside of the cluster to provide connections to ServiceGuard Manager clients, each node in the cluster must have the following rules configured:

pass in quick proto tcp from <comnode> to <clusternodes> port = 5302 flags S keep state

pass in quick proto udp from <comnode> to <clusternodes> port = 5302 keep state

pass out quick proto tcp from <clusternodes> to <comnode> port 49151 >< 65536 keep state

pass out quick proto udp from <clusternodes> to <comnode> port 49151 >< 65536 keep state

The node running COM must have the following rules configured:

pass in quick proto tcp from <comclient> to <comnode> port = 5303 flags S keep state

pass in quick proto tcp from <clusternodes> to <comnode> port 49151 >< 65536 keep state

pass in quick proto udp from <clusternodes> to <comnode> port 49151 >< 65536 keep state

pass out quick proto tcp from <comnode> to <clusternodes> port = 5302 flags S keep state

pass out quick proto udp from <comnode> to <clusternodes> port = 5302 keep state

Each COM client must have the following rules configured:

pass out quick proto tcp from <comclient> to <comnode> port = 5303 flags S keep state

In the previous set of rules, <clusternodes> are all nodes in the cluster, <comclient> are nodes that are clients of COM for ServiceGuard Manager or Continental Clusters products, and <comnode> is the node running the COM.

ServiceGuard Manager

If you are using ServiceGuard Manager, you must configure rules to let SNMP traffic pass between all nodes in the cluster and the ServiceGuard Manager node.

Each cluster node must have the following rules configured:

pass in quick proto udp from <SGMgr node> to <clusternodes> port = 161 keep state

pass out quick proto udp from <clusternodes> to <SGMgr node> port = 162 keep state

Each ServiceGuard Manager node must have the following rules configured:

pass out quick proto udp from <SGMgr node> to <clusternodes> port = 161 keep state

pass in quick proto udp from <clusternodes> to <SGMgr node> port = 162 keep state

In the previous set of rules, <clusternodes> are all nodes in the cluster, including the local node, and <SGMgr node> is the node or nodes running ServiceGuard Manager.




	NOTE: The previous sections are examples and meant to serve as guidelines. You might need to modify them to work with your network configuration and the applications you use. Specific applications used within the MC/ServiceGuard cluster might require additional ports to be opened.

DCA Remote Failover

Normally, IPFilter keep state rules are configured with the flags S parameter. This parameter instructs IPFilter to create a TCP state entry only when a SYN packet is parsed.

To enable transparent failover between IPFilter DCA nodes, do not use flags S with keep limit rules. If incoming TCP/IP traffic is switched from the active to the standby node, DCA can rebuild the previous IPFilter state table and IPFilter DCA limit tables from the data stream. Without flags S in the keep limit rule, IPFilter creates a new state entry from any TCP/IP packet, not just a SYN packet. A limit table entry is created. Any new connections that exceed the connection limit are rejected.

After the state table entry is created for a particular IP address source/destination and TCP port source/destination 4-tuple, further packets of this connection are processed in the state table entry. These packets are not processed by the rules’ table.

For example, when MC/Service Guard detects that the primary IPFilter DCA gateway has failed, the IP addresses of the primary systems are switched to the standby DCA system. The standby system contains the same set of configured rules as the primary system. Therefore, the standby system can completely rebuild the TCP state tables and limit entries that were previously on the primary system.

If a client has active connection to an IPFilter system and is attempting to make new connections when MC/ServiceGuard fails over, the new connections replace the existing connections in the limit table entry for the client only if the established connections are not generating traffic.