Nokia IPSO VRRP Clusters


If a simple HA cluster solution is required for the Nokia platform, a VRRP configuration should be considered. In this section, we provide an overview of the VRRP protocol, how to configure it on IPSO, and how to configure FireWall-1 NG FP3 for a VRRP cluster. We'll then talk about how you can test the cluster and go over any special considerations that you need to keep in mind when using a cluster.

Nokia Configuration

To configure a Nokia VRRP cluster, you need to take the following steps:

  • Configure the interfaces of a Nokia.

  • Configure FireWall-1.

  • Configure VRRP in Voyager.

We assume that you have installed IPSO 3.6 FCS-4 on your Nokia and that you have the Check Point FireWall-1 NG FP3 package installed and configured. As with setting up all clusters, it is recommended that you complete and test the physical connectivity first so that any problems that you encounter later aren't due to a misconfigured switch or interface, because these could be difficult to spot later.

In Figure 21.76, you can see an example Nokia VRRP configuration. Plenty of the information shown won't make much sense yet, so just look at the topology and IP addresses for now.

click to expand
Figure 21.76: Our Example Configuration: A Nokia VRRP Cluster

Unlike Nokia clustering, a VRRP configuration does not require a separate cluster control network. As you can see from Figure 21.76, each network that has a VIP also has a virtual MAC address—a unicast VRRP MAC that is used for the VIP. From a network perspective of neighboring equipment on the same network as the cluster interfaces, it looks the similar to Check Point ClusterXL in Load-Sharing mode, but with unicast MAC addresses involved rather than multicast.

You should be able to perform basic IPSO configuration, install Check Point NG FP3, and configure the Gateway Cluster object in the same way as you would for IPSO clustering, with one exception: When configuring the gateway cluster object Availability Mode, select High Availability.

Configuring the Nokia VRRP Rule Base

You have some choices as to the rule base you want to install. You can either see if the configuration of your cluster object is going to work and install an open policy, or you can create a strict policy now. Remember, there is still one more step to do, which is to configure VRRP using Voyager, so you might want to install an open policy now and then tighten it later once you are happy that your clustering is working correctly.

The VRRP protocol is multicast based. VRRP multicasts are sent by whichever member currently considers itself VRRP master. In IPSO 3.6, this traffic bypasses the firewall kernel, so no rules accepting the traffic are required in the security policy. If your switches are performing "IGMP snooping" to detect multicast group members, you need to allow the IGMP protocol from the cluster to multicast addresses, as shown in Figure 21.77.

click to expand
Figure 21.77: Rule Allowing IGMP Multicasts from the Cluster

Note

If you are running IPSO 3.5 or earlier, your security policy must also allow the VRRP protocol from the cluster member addresses (use the cluster object) to multicast addresses.

As with other cluster solutions, it is a good idea to make sure that the time between the cluster members does not drift by implementing NTP time synchronization—so make sure that the rule base accepts NTP between cluster members.

You need to configure a group of host node objects that represent all the VRRP VIPs and use this in your "stealth" rule and elsewhere. For details, see the "IPSO Clustering" section.

Once you have configured your policy, install it to the cluster and test. You now have to complete the last step in configuring a Nokia VRRP cluster: Configure IPSO to use VRRP.

Nokia VRRP Configuration on Voyager

When we configured the Gateway Cluster object in the SmartDashboard GUI, we did not configure the gateway cluster to have ClusterXL installed. This feature is not available on the Nokia platform, but Nokia provides its own solution for HA: VRRP. However, you have to configure it within the Voyager interface.

Note

Remember that you have to configure VRRP on each Nokia in the cluster, so you will have to repeat the procedure on each Nokia.

In the section that follows, we deal with one particular VRRP configuration: VRRP monitored circuits with a single virtual router, and single virtual IP address, for each connected subnet, with two systems participating in the cluster. This is probably the most common and well-tested configuration, but VRRP provides many other possibilities. VRRP is a standard protocol for router redundancy and is well documented elsewhere, and brave readers might want to refer to RFC2338. For more details regarding IPSO VRRP configuration, refer to Nokia Network Security Solutions Handbook (Syngress Publishing, ISBN 1931836701).

Voyager Configuration

Make sure you have network connectivity from your browser to your Nokia FireWall-1 modules in your cluster, and make sure that the security policy you installed on the firewall does not prevent you from accessing Voyager from your browser. Navigate to Voyager on the system that you want to become the master member of the cluster. In our example, we would do this by going to https://195.166.16.131 (see Figure 21.78).

click to expand
Figure 21.78: Voyager's Main Screen

Here are the steps that you need to follow after you have authenticated and are presented with the main screen:

  1. From the main Voyager screen, click Router Services Configuration.

  2. Click VRRP. The initial configuration page appears.

  3. Enter a cold start value. This introduces a delay after the VRRP system initializes, before it will consider itself a potential master router. A value of 30 seconds provides ample time for FireWall-1 to initialize (see Figure 21.79). Click Apply.

    click to expand
    Figure 21.79: Initial VRRP Configuration Page in Voyager

  4. Select the VRRP mode for each interface on which redundancy is required. Typically, VRRP is enabled on all interfaces except the dedicated Check Point "sync" network. In this example, we use VRRP monitored circuits mode. The cluster configuration screen then expands to include more parameters that can be configured within the cluster. Click Apply.

  5. Enter a virtual router ID (VRID) for each VRRP-enabled interface. Select a different VRID for each interface. In this case, we have simply based them on interface port numbers, but you could use, for example, network numbers (see Figure 21.80). Click Apply.

    click to expand
    Figure 21.80: Cluster Configuration Defining VRIDs

  6. The next page allows you to configure VRRP for each interface. Supply values for each interface as follows:

    • Priority This should indicate your preference as to which member runs as master. In this example, we give a priority of 100 to our preferred member for each interface. When configuring the other member, we give a value of 90.

    • Hello interval The interval in seconds between each announcement from the current master. We are using a value of 1 second to give the quickest failover. If bursts of serious network congestion results in loss of some of these hello packets, a greater value might be specified, resulting in slow failover but less chance of "false" failover.

    • VMAC Mode Choose VRRP for default VRRP behavior.

    • Backup Address The virtual cluster IP address on this interface's subnet (see Figure 21.81).

    click to expand
    Figure 21.81: Configuration for One of the Virtual Routers

    Once values have been specified for all the interfaces, click Apply.

  7. For each interface, we can now identify which other interfaces are monitored. This identification is key to the operation of Monitored Circuits mode. We want to ensure that if any one of the cluster interfaces fails on the current master, the backup system will become master and take over routing. To do this, each interface monitors all other VRRP enabled interfaces, with a priority delta of greater than the difference between the priority specified on the preferred master and the backup. In our example, the priority on our preferred master was 100 and on the backup, 90. We will use priority deltas of 15, ensuring that failure of any interface will reduce the effective priority of the current master to below that of the backup member (refer back to Figure 21.76 and see Figure 21.82).

    click to expand
    Figure 21.82: A Virtual Router with Monitored Interfaces Enabled

  8. We will also configure authentication for each virtual router by enabling Simple Authentication, supplying a password, and clicking Apply (see Figure 21.83). This simple authentication is far from secure; the password given appears in Voyager after it is set and is transmitted in VRRP traffic as plaintext! It does, however, protect against simple attacks, or more likely, problems caused by other VRRP devices that have coincidentally been configured with the same VRID. Be aware that if the password (or lack of one) does not match that used by other members, this member will assume itself as master (there being no other devices with "correct" passwords enabled)—so always set the password correctly immediately on configuration of a new member's VRRP interfaces.

    click to expand
    Figure 21.83: Configuring VRRP Interface Authentication

  9. Finally, don't forget to click Save.

  10. To verify that the members have correctly identified themselves as master and backup, click the link at the bottom of the page to VRRP Monitor (see Figure 21.84). The preferred member should indicate that all its virtual routers are in Master mode. The backup member should indicate that its virtual routers are in Backup mode.


    Figure 21.84: VRRP Monitor on Preferred Member Showing All Three Virtual Routers in Master Mode

Testing the Nokia VRRP Cluster

Once your Nokia VRRP cluster is configured, you need to test it to make sure that it is functioning correctly. Again, keep in mind the way that this particular clustering technology works and how it differs from the other clustering solutions we have covered so far.

Test 1: Pinging the Virtual IP Address for Interface

You should be able to ping the local VIP addresses (VRRP backed-up addresses) from a host that is on the same subnet as the cluster interfaces.

You will receive a response if everything is working properly. If you do not receive a response, verify that your rule base allows echo-request to the cluster IPs and that Accept Connections to VRRP IPs is enabled in the Voyager VRRP page.

In the test we ran on our example network, a ping was initiated from the FireWall-1 management station (195.166.16.134) to the VIP of the cluster (195.166.16.130). A packet trace was run at the same time on the management station to analyze the packet for the ping session. If you look at the ARP cache of the local host initiating the ping, you should now have the VRRP MAC address of the VIP. In our case, this is 0:0:5e:0:1:1 (which you can check against Figure 21.76). This in itself does not tell you much—just that the VIP address is up and running, and that a member in the cluster responded—but can we tell which member?

Unlike other solutions, because the source MAC address of the echo reply is the VRRP MAC address, there is no indication of which member actually replied.

However, if we ping a host behind the cluster—as long as doing so is allowed by the firewall policy—the source MAC address of the reply packet will be the real MAC address of the member that passed the packet.

Test 2: Finding Which Member Responds to Administrative Connections to the VIPs

A rather unconventional test for the cluster is to attempt an administrative connection—in other words, Telnet, FTP, Voyager (HTTP or HTTPS) to a cluster VIP. The responding member will indicate its host name in its response, allowing you to deduce which member is the current master. If the connection fails, make sure that your rule base allows that type of connection to the cluster IP and that that type of access is supported by your IPSO configuration.

Test 3: Determining the Status of Each Member in the Cluster

In a VRRP configuration, there are two tools for monitoring the status of the cluster and its members. One is the SmartView Status GUI, and the other is Voyager monitoring.

The SmartView Status GUI shows you the health of each member and if it is in state table sync with other members of the cluster. What it won't show you is the correct status of each interface of each member. For this information, you have to use the Nokia Voyager screens on each member in the cluster.

Checking the monitoring of the cluster through Voyager is straightforward. Connect your browser to one of the members, and select Monitor VRRP. The summary information will indicate whether the member considers itself a master or backup (see Figures 6.85 and 6.86). More detailed information is available in the interface and stats pages (linked from this page).

click to expand
Figure 21.85: The VRRP Monitor Interface Page

click to expand
Figure 21.86: The VRRP Monitor Stats Page

Test 4; FTPing through a VRRP Cluster During Interface Failure

We can follow the same steps as suggested for IPSO clustering configurations to perform a test. If SmartView Monitor is available, this provides a good method of observing the failover (or not).

Command-Line Stats

We can use the IPSO clish command to monitor VRRP from a console session. This command provides very similar information to that provided by Voyager but provides a useful alternative.

Once in the clish shell, you can use these commands:

  • show vrrp Shows a summary of VRRP status.

  • show vrrp interface <interface name> Provides for more details for a particular interface.

  • show vrrp interfaces All interfaces.

  • show vrrp stats Detailed VRRP statistics.

You can use the cphaprob command on the Nokia platform if you want, but the information that it will tell you is limited. For example, it can't tell you which interfaces are up or down, but it can tell you whether the state table synchronization is working or not.

How VRRP Works

The VRRP solution is considerably simpler in operation than the Check Point or Nokia cluster technology. VRRP makes no attempt to monitor the firewall software so it does not failover if the master firewall software has failed. VRRP is designed to provide router resilience, so if one physical router fails, another takes over, hopefully transparently in terms of through connectivity.

Each VRIP address is associated with a unicast MAC address. This MAC address comes from a range allocated for VRRP. Although it is a unicast address, it floats between members so that devices on the local subnet see a single (virtual) router. When considering whether a member is in master or backup state, it is important to realize that the state is defined per virtual router per interface. This means that it is possible that a member has some of its virtual routers in Master mode and others in Backup mode. In our example, we configured each virtual router on a member to use the same priority and monitor all its other VRRP enabled interfaces and associate those with the same delta; this should ensure that all virtual routers on a member are in a consistent state. In more advanced configurations, this flexibility can be used to advantage because it allows a member to be a preferred master for some routes but backup for others by using multiple virtual routers.

Communication between members is simple; in fact, there is no two-way communication as such. There are reasonably straightforward rules governing when members switch a VR between Master and Backup state:

  • The member that believes itself to be the master for a given virtual router (VR) will send VRRP announcements for that VR at intervals as configure—in our example, every second—advertising its effective priority (that is, its base priority less the deltas of any failed interfaces). This concept is illustrated in Figure 21.87.

    click to expand
    Figure 21.87: VRRP Announcements

  • If a member with a VR in master state sees an announcement with a higher effective priority than its own, it switches itself to backup state and stops sending announcements.

  • If a member with a VR in backup state sees an announcement that has a higher effective priority, it will switch to master state itself and begin announcements.

  • If a member with a VR in backup state does not see any advertisements for a given timeout period, it will switch to master state.

Let's walk through an example of how a connection would work through a VRRP cluster. In our example, host 192.168.1.200 initiates a Telnet session through the cluster to our ISP router on IP address 195.166.16.129, and we address hide the connection behind the cluster external IP address of 195.166.16.130, using a hide rule in our firewall NAT rule base.

When the Telnet session is initiated, the host 192.168.1.200 sends out an ARP request for 192.168.1.130, which is the default gateway on the network 192.168.1.0. The address in the ARP response will be the VRRP MAC address for the VR on that network. The member that has the VR in master status will always send the ARP response. In our example, the MAC address returned is 0:0:5e:0:1:4. Our host on 192.168.1.200 then sends a SYN TCP packet, high source port, destination is to 195.166.16.129, destination MAC is 0:0:5e:0:1:4 (the default gateway MAC address).

Only one member of the cluster will do anything with the packet—the one with the VR in master state. This will pass the packet up through the IP stack to Check Point FireWall-1 for the incoming interface. The TCP SYN packet will pass through the rule base of the firewall and, providing that everything is fine, it will then send the packet out of its external interface, with the source IP address of 195.166.16.130 (the external cluster IP address), with the source MAC address of the member that has routed the packet (in our example, the source MAC address is 0:c0:95:e0:15:dc , which corresponds with member fw1 external interface eth-s1p1c0), and the destination IP address will be 195.166.16.129.

If the Telnet daemon is listening when the packet reaches the ISP router on 195.166.16.129, it will produce a response. The ISP router will issue an ARP request for IP address 195.166.16.130, which is the VIP of the cluster. The member with the external VR in master state will respond to the ARP request, sending the VRRP MAC address as the MAC address associated with IP 195.166.16.130. Host 195.166.16.129 will then send a SYN,ACK TCP packet, source IP will be 195.166.16.129, source port will be 23, and destination MAC will be the VRRP MAC address of the VR master for 195.166.16.130. The reply packet arrives at all members in the cluster and is processed by the member with the VR in master state.

The packet then leaves the internal interface of member fw1 in our example, source IP is the 195.166.16.129 (IP address of the ISP router), source MAC address is the internal interface MAC of fw1, and destination IP is now 192.168.1.200 (it has been address translated by FireWall-1).

Special Considerations for Nokia VRRP Clusters

We have talked a little about how the VRRP solution works. Now we look at issues that should be taken into account when setting up our cluster and the rule base we are likely to use.

Network Address Translation

As with all clusters, the way you decide to implement your NAT rules needs to be taken into account. With VRRP, you cannot use Check Point's own Automatic ARP setting in the Policy | Global Properties | NAT – Network Address Translation | Automatic Rules for Automatic ARP Configuration.

The reason for this is that each member will proxy ARP for the real MAC address of the member in the cluster as opposed to proxy ARPing the VRRP MAC address of the relevant cluster VR. For this reason, you cannot use Automatic ARP Configuration.

You can enter proxy ARP entries into Voyager for NATed IP addresses using the VRRP MAC address of the cluster VR. Alternatively, you could add static host routes on the ISP router to route traffic for the NATed IP address to the external VRIP address. Note: It is not recommended to add the NATed IP address as a VRIP address, because doing so could cause problems with FireWall-1 antispoofing configurations.

Connections Originating from a Single Member in the Cluster

When defining the CP cluster object for the IPSO cluster, the cluster topology could be defined using the VIPs. This results in the same behavior as ClusterXL on connections from members out of the external if they implicitly hide NAT behind cluster VIPs. As with ClusterXL, once FP3 Hotfix 1(or a more recent hotfix that includes Hotfix 1 features) is applied, packets routed back to the wrong member should be routed onward via the sync link, so this configuration will work—to a degree. However, in practice, there seems to be problems with this configuration in non-ClusterXL solutions that result in packet loss, and as such we recommend that the cluster topology not be defined when you're using a VRRP solution.

Third-Party Clustering Solutions

A range of solutions are available that provide HA and load-sharing functionality for FireWall-1. Some integrate with FireWall-1 on the cluster members themselves, while others are located adjacent to the cluster and allocate traffic between members from there. The most widely used third-party solutions are probably Stonesoft StoneBeat and Rainfinity Rainwall; both have HA and load-balancing variants. For information on other OPSEC partner HA solutions, and indeed more about OPSEC, refer to the OPSEC Web site. It is wise to check the OPSEC site to match product version with supported FireWall-1 version for any third-party solution:

  • Stonesoft www.stonesoft.com

  • Rainfinity www.rainfinity.com

  • Other OPSEC partners www.opsec.com




The Best Damn Firewall Book Period
The Best Damn Firewall Book Period
ISBN: 1931836906
EAN: 2147483647
Year: 2003
Pages: 240

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net