Nokia IPSO VRRP Clusters
Test 4: FTPing Through a VRRP Cluster During Interface Failure
We can follow the same steps as suggested for IPSO clustering configurations to per- form 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 inter- faces are up or down, but it can tell you whether the state table synchronization is working or not.
Figure 6.85 The VRRP Monitor Interface Page
Figure 6.86 The VRRP Monitor Stats Page
How VRRP Works
The VRRP Monitored Circuits solution is considerably simpler in operation than the Check Point or Nokia cluster technology. VRRP makes no attempt to monitor the fire- wall software so 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. We will now take a detailed look at how VRRP Monitored Circuits work.
Each VRID is associated with a special unicast MAC address (although it can be con- figured to use any unicast or multicast MAC address, if so required).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 con- figurations, 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 communica- tion as such.There are reasonably straightforward rules governing when members switch a VR between Master and Backup state. However, VRRP was designed to handle single failures. More complicated configurations are possible, but usually when one interface fails on a router you want to fail over all the interfaces to the secondary, and if it looses an interface fail all over to the third and so on. Having a router with some VRIDs in backup and some master is prone to error and it is generally considered a misconfiguration.
■ 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 configured— 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 6.87.
■ If a member with a VR in master state sees an announcement with a lower 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 announcements for three times the configured announcement interval, 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 Figure 6.87 VRRP Announcements
fw1 fw2
Hub Hub
Hub Hub ISP Router
PDC
192.168.11.131 eth-s1p2c0
MAC=00:c0:95:e0:15:dd 192.168.11.132
eth-s2p2c0 195.166.16.131
eth-s1p1c0 MAC=00:c0:95:e0:15:dc
195.166.16.132 eth-s2p1c0 MAC=00:c0:95:e2:b1:40
195.166.12.131 eth-s1p3c0 MAC=00:c0:95:e0:15:de
192.168.12.132 eth-s2p3c0 MAC=00:c0:95:e2:b1:42
192.168.1.200 Default route = 192.168.1.130 Out to the Internet
195.166.16.129
State sync Network 192.168.11.0 /24 External Network
195.166.16.0/24 VIP = 195.166.16.130 VMAC=00:00:5e:0:1:01
VRID=1
DMZ Network 192.168.12.0/24 VIP = 192.168.12.130 VMAC=00:00:5e:00:01:03
VRID=3
Internal Network 192.168.1.0/24 VIP = 192.168.1.130 VMAC=00:00:5e:00:01:04
VRID=4 Domain = london.com
www
192.168.12.133 Default route = 192.168.12.130 Source IP = 195.166.16.131 Destination IP = 224.0.0.18
Source IP = 192.168.12.131 Destination IP = 224.0.0.18
Source IP = 192.168.1.131 Destination IP = 224.0.0.18
Master
Backup
MAC=00:c0:95:e2:b1:41 192.168.1.131
eth-s1p4c0
MAC=00:c0:95:e0:15:df 192.168.1.132
eth-s2p4c0 MAC=00:c0:95:e2:b1:43
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, desti- nation 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
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 notrecommended 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 connec- tions 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 seem to be problems with this configuration in non- ClusterXL solutions that result in packet loss, and as such we recommend that the cluster topology notbe 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, 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