 |
Rainwall High Availability for Checkpoint VPN-1/Firewall-1 |
FREQUENTLY ASK QUESTIONS
What is RainWall?
Do I need a separate Check Point license for every machine in the
cluster?
What are the key features of RainWall?
How is RainWall different from other high availability solutions?
What's new in version 1.6?
What's new in the previous version, 1.5 SP3?
What do you mean by high availability?
How does RainWall provide high availability?
How quickly does RainWall recover from failures?
Does RainWall compromise the security of FireWall-1?
Is RainWall OPSEC certified?
What is dynamic load balancing? How is it different from load
sharing?
How many networks and nodes does RainWall support?
Does RainWall require any additional hardware?
What are the system requirements for RainWall?
Which NICs are compatible with RainWall?
RainWall Technology
What is CGSS?
Does RainWall require a dedicated heartbeat network?
Can RainWall migrate MAC addresses between systems?
Why does RAIN clustering use VIPs instead of a single-MAC
approach?
When using RainWall in a multiple-VIP configuration, how do other
devices in the network know where to send their packets?
Does RainWall work with NAT (Network Address Translation)?
Are there any switches or routers that are incompatible with
RainWall?
How does RainWall perform load balancing?
Is asymmetric routing a problem? How does RainWall address it?
Does RainWall require Check Point's state synchronization?
How does RainWall enhance Check Point's state synchronization?
Does RainWall allow transparent failover and load balancing for
VPN?
How does RainWall monitor FireWall-1?
Is RainWall itself resilient (i.e., what if the RainWall daemon
fails)?
Can RainWall protect from a failure of the router or ISP
connection?
Can I split a cluster across multiple locations?
Can RainWall be run on a mixed cluster (i.e. heterogeneous
servers)?
Does RainWall work with FloodGate-1?
Does RainWall work with SecureClient?
RainWall
Installation/Configuration
Administration
and Monitoring
Troubleshooting
What is RainWall?
RainWall is firewall server clustering software designed to provide
high-availability (HA) and load balancing (LB) for Check Point FireWall-1 and
VPN-1. RainWall improves the reliability of a VPN-1/FireWall-1 enforcement point
by linking two or more firewall servers together into a single redundant system.
RainWall also dramatically improves performance by harnessing the combined
processing power of all machines in the cluster. RainWall is based on our
patented, award-winning RAIN technology.
(top of page)
Do I need a separate Check Point license
for every machine in the cluster?
Yes. Check Point requires a separate license for every machine that runs
FireWall-1 or VPN-1 software. Check Point offers high availability bundles that
include secondary FireWall-1 or VPN-1 gateways at reduced costs by submitting a
HA user declaration. For more information, contact your local Check Point sales
representative.
(top of page)
(top of page)
How is RainWall different from other high availability
solutions?
(top of page)
What's new in version 1.6?
RainWall 1.6 for Check Point was released on November 20, 2001 for Solaris,
NT, and Linux and on January 9, 2002 for Windows 2000. This new release provides
the latest updates to RainWall, including NG support and new features that
simplify configuration of clustered nodes.
(top of page)
What's new in the previous version, 1.5 SP3?
RainWall 1.5 SP3 for Check Point was released on July 23, 2001 for Solaris,
NT, and Linux. This service pack for 1.5 provided maintenance fixes to known
issues and new configuration options that improves usability.
(top of page)
What do you mean by high availability?
RainWall keeps the firewall system up and running as long as at least one
firewall node in the cluster remains fully functional. RainWall allows you to
design a firewall system that has multiple layers of backup and no single point
of failure. Because RainWall is based on a peer-to-peer relationship, rather
than a master/slave relationship, it is not necessary to add nodes in pairs.
Each node added to the cluster adds yet another layer of redundancy. All nodes
are active at all times, so the viability of the backup system is never in
doubt.
(top of page)
How does RainWall provide high
availability?
RainWall makes sure that even if a physical machine goes down, its IP
address will remain active. For example, if firewall A goes down, its IP
addresses will move to firewall B. If firewall B also fails, the IPs of both A
and B will move to firewall C. This is accomplished by the use of virtual IP
addresses (VIPs) that can float transparently from one machine to another.
(top of page)
How quickly does RainWall recover
from failures?
For most traffic, recovery is so fast that users will not even know that a
failure has occurred. TCP sessions are maintained during fail over, and do not
need to be restarted. For example, a file transfer via FTP or HTTP will continue
without loss of data. This is known as transparent failover. Even encrypted VPN
sessions can be maintained without the need to re-establish the tunnel or
re-authenticate a user. Once the problem is corrected, failed nodes
automatically rejoin the cluster within seconds.
(top of page)
Does RainWall compromise the security
of VPN-1/FireWall-1?
No. RainWall requires no trust relationship with the firewall and does not
allow packets to circumvent the FireWall-1 inspect engine.
(top of page)
Is RainWall OPSEC certified?
Yes. RainWall 1.5 on Solaris and Linux has been OPSEC certified for Check Point
2000. RainWall 1.6 on Solaris and Linux has been OPSEC certified for Check Point
NG. RainWall 1.6 on Windows 2000 is currently undergoing certification.
(top of page)
What is dynamic load balancing? How
is it different from load sharing?
Some vendors use these terms interchangeably, which can be misleading. Load
sharing is simply dividing traffic among multiple machines. It usually involves
a static split or random allocation of traffic. True dynamic load balancing uses
intelligence to optimize performance in real-time by shifting traffic from
heavily loaded nodes to less-loaded nodes in response to changing traffic
conditions. RainWall offers true dynamic load balancing on either a per-VIP or
per-connection basis.
(top of page)
How many networks and nodes does
RainWall support?
RainWall supports up to 16 firewall nodes per cluster, up to 17 subnets/NICs
per machine, and up to 8 Virtual IP addresses per subnet. This translates to
ample capacity for even the most demanding applications.
(top of page)
Does RainWall require any additional
hardware?
RainWall is a software-only solution that runs directly on the firewall
itself with no extra hardware components. It does not require dedicated
"heartbeat" LANs to carry a cluster sync signal. Individual nodes can
share cluster state information with each other in-band using our low-overhead
CGSS protocol (Consistent Global State Sharing). Older HA solutions require
additional dedicated NICs and hubs to carry their sync signal. Those
"heartbeat" LANs add cost and complexity, and can become another
single point of failure.
(top of page)
What are the system requirements for
RainWall?
RainWall 1.6 supports Check Point VPN-1/FireWall-1 NG hotfix-2 and 4.1 SP5.
Platform requirements are Solaris 7 or 8, Windows NT 4.0 SP6, and Red Hat Linux
6.2 or 7.0 (kernel version 2.2.19).
RainWall 1.5 SP3 supports Check Point VPN-1/FireWall-1 4.1 SP3 and SP4. Platform
requirements are Solaris 7 and 8, Windows NT 4.0 SP6, and Red Hat Linux 6.2
(kernel version 2.2.16).
(top of page)
Which NICs are compatible with
RainWall?
The following NICs have been tested for interoperability with RainWall. We
have tested RainWall with these NICs to ensure installation, health monitoring,
and traffic management functions are operational. Most leading 10/10/1000
Ethernet NICs should be compatible, but they have not been tested by Rainfinity.
We cannot test every card on the market or guarantee that all combinations of
hardware and driver software will operate correctly with RainWall.
RainWall Technology
What is CGSS?
CGSS is Consistent Global State Sharing, a unique communications protocol
used by nodes in a RAIN cluster to communicate cluster state information with
each other. It allows efficient, cooperative decision-making about how to
reroute traffic in the event of a failure, or to achieve load balancing. It can
be run in-band over the internal LAN or on a dedicated LAN.
(top of page)
Does RainWall require a dedicated
heartbeat network?
No. RainWall can use the low-overhead CGSS protocol to communicate cluster
state information in-band on the internal production network. Older high
availability products require a dedicated heartbeat LAN, which requires that
additional NICs be installed in each firewall machine and connected to a
separate hub just to support a cluster sync signal. Such heartbeat LANs add cost
and complexity, and can be a single point of failure. Use of a dedicated
heartbeat LAN with RainWall is entirely optional.
(top of page)
Can RainWall migrate MAC addresses
between systems?
No. RainWall does not move MAC addresses between systems because it achieves
redundancy at Layer 3, not Layer 2. Rather, it moves IP addresses between
systems.
(top of page)
Why does RAIN clustering use VIPs
instead of a single-MAC approach?
Early in the development of our clustering technology, both approaches were
considered. Some of the developers were initially in favor of using single-MAC
clustering, because it had been used before and would therefore reduce
development time. However, the single-MAC approach was ultimately rejected
because it is not linearly scalable. The developers chose to spend the extra
time to develop a more sophisticated, next-generation clustering approach that
could scale without limit. The new, infinitely scalable clustering method was
called RAIN (Reliable Array of Independent Nodes), and was awarded US Patent No.
6,088,330. Specifically, we rejected the single-MAC approach for the following
reasons:
(top of page)
When using RainWall in a multiple-VIP configuration, how do
other devices in the network know where to send their packets?
Other devices in the network are pointed to one or more of the VIPs as their
default gateway. In a single-IP configuration, other devices simply point to the
one cluster IP. In a multiple-VIP configuration, devices select one of the VIPs,
or round-robin their traffic to all the VIPs. Also see the question "How
does RainWall perform load balancing?" for more information about
configuration of default gateways in a multiple-VIP design.
(top of page)
Does RainWall work with NAT (Network
Address Translation)?
Yes. VIPs on the external subnet can be used with static or dynamic NAT to
"hide" subnets of internal hosts.
(top of page)
Are there any switches or routers
that are incompatible with RainWall?
All standards-compliant 10/100/1000baseT switches should be compatible with
RainWall. Certain advanced Layer 2 features like VLANs may or may not work with
RainWall, depending on how they are being used and how the switch vendor has
implemented them. Most routers and Layer 3 switches are compatible with
RainWall, however those that have a proprietary route-caching mechanism enabled
by default may need to have this feature turned off or adjusted to allow
transparent failover capability with RainWall. So far, the only devices we've
encountered that do not allow such adjustment are certain Nortel/Bay Accelar
model Layer 3 switches.
(top of page)
How does RainWall perform load
balancing?
RainWall offers two types of load balancing: per-VIP and per-connection:
The two types of load balancing can be used concurrently. For information on
configuring RainWall for load balancing, please refer to the User Guide and the
solution brief entitled Modes of Operation.
(top of page)
Is asymmetric routing a problem? How
does RainWall address it?
Asymmetric routing is avoided entirely in RainWall's symmetric mode, in
which RainWall automatically enforces symmetric routing for all traffic.
Asymmetric routing of traffic is allowed in RainWall's asymmetric mode. It
asymmetric mode, it improves load balancing, since return traffic can traverse a
different node than the one it entered through. However, asymmetric routing can
also cause undesirable behavior under certain circumstances.
Check Point FireWall-1 synchronizes state among all the nodes in a clustered firewall every 50 to 100 milliseconds. This latency can cause perceivable delays in establishing new connections if a connection request comes in through one firewall and the acknowledgement goes out another (asymmetric routing), and the firewall policy is strict. For example, if the firewall is configured to block ACK packets when it hasn't seen the original SYN packet, the initial TCP connection handshake may fail if the ACK packet hits the second firewall before synchronization has occurred. TCP will re-attempt the handshake, and by the time the retry hits the cluster, state has usually been synchronized and traffic will flow normally. However, this TCP retry may cause noticeable delay in establishing the initial connection. Such delays only occur for asymmetrically routed connection requests, so the problem may affect some users and not others. Depending on the application, this delay may go unnoticed by the user, or may cause significant annoyance. Non-TCP applications may also be affected by this delay, depending on the firewall policy.
To address this, RainWall accelerates firewall synchronization so the delay inherent in the FireWall-1 sync process does not become a problem. As a result, new TCP connections are not delayed even under asymmetric routing conditions. This ability to route traffic asymmetrically without delaying connections provides performance benefits unique to RainWall.
VPN and non-TCP traffic may have problems with asymmetric routing, even with
RainWall's enhanced state sync enabled. For such applications, RainWall should
be configured to guarantee symmetric routing, either manually via sticky VIPs
with preference, or by simply enabling the automatic symmetric routing
enforcement feature. For more detail, please refer to the User Guide and the
application brief entitled Modes of Operation.
(top of page)
Does RainWall require Check Point's
state synchronization?
By itself, RainWall does not require Check Point state synchronization.
However, RainWall features that leverage the state synchronization, such as
transparent fail-over and VIP-based load balancing, will not function without
it. If you turn off the state synchronization, automatic fail-over will occur
but existing connections will be broken. Without the state synchronization, you
can still dynamically load balance using the per-connection method. Rainfinity
recommends enabling state synchronization. NG no longer supports the old
(user-mode TCP) state synchronization. RainWall works with the new (kernel-mode
UDP) state synchronization on NG.
(top of page)
How does RainWall enhance Check
Point's state synchronization?
RainWall accelerates firewall synchronization for TCP traffic by proactively
informing all nodes of new TCP connection requests, so the state tables are
"pre-synchronized". As a result, all nodes are aware of all TCP
connections at all times, but only one node actually processes the connection
traffic, thereby minimizing LAN and system overhead. This feature is called
enhanced FW sync. It does not require a trust relationship with the firewall.
(top of page)
Does RainWall allow transparent
failover and load balancing for VPN?
Yes. RainWall works with Check Point VPN-1, and allows transparent failover
of VPN connections. In addition, RainWall can provide dynamic load balancing of
SecuRemote traffic on a per-tunnel basis.
(top of page)
How does RainWall monitor FireWall-1?
RainWall can monitor the health of VPN-1/FireWall-1 in three ways:
(top of page)
Is RainWall itself resilient (i.e., what if the RainWall
daemon fails)?
Yes. If the RainWall daemon fails on one gateway, the rest of the cluster
will react by redirecting all connections around the failed gateway.
(top of page)
Can RainWall protect from a failure
of the router or ISP connection?
Yes. A handy side-benefit of RAIN technology is that you can configure
RainWall to automatically re-route traffic to a secondary router and ISP link in
the event the primary router or ISP link fails. It can also provide load
balancing of outbound connections (and inbound return traffic) between the
links. This eliminates the need to run BGP on the routers if you are primarily
interested in protecting outbound web browsing and email. It requires a special
configuration, which has a few limitations. Namely, failover in this
configuration is automatic, but not transparent. It requires the use of NAT on
the firewall, which may be incompatible with some applications. RainWall does
not provide failover or load sharing between links for inbound connections
(those initiated from an external host to a server located on the internal
network). That function can be accomplished with a dynamic DNS utility, but is
not provided by RainWall itself. Detection of router or ISP failure is made
possible by the RainWall Ping Monitor. See the User Guide for details on the use
and customization of the Ping Monitor. For more information, please refer to the
solution brief titled Multi-homing with RainWall.
(top of page)
Can I split a cluster across multiple
locations?
Yes. As long as all the nodes share a subnet for their CGSS communications,
it is possible to set up a RainWall cluster that contains nodes in different
locations. For example, a WAN circuit could be used to bridge together a LAN in
New York and a LAN in Boston. You could then place two nodes in New York and two
in Boston, yet still group them into a 4-node cluster. However, there may be
other factors to consider, such as the need for BGP or distributed DNS, before
actually building such a design. Also, latency introduced over the WAN will
impact Check Point's state synchronization. Whether or not a distance solution
using a split cluster design is a good idea depends on your reasons for
designing such a network, and your ability to address the larger routing issues
raised by multiple points of access into a single network.
(top of page)
Can RainWall be run on a mixed
cluster (i.e. heterogeneous servers)?
Yes and no. Different hardware configurations are generally not a problem
for RainWall. For example, you could run a 2-node cluster on one Ultra 10
machine and one E450 machine. In a worst case, this may lead to sub-optimal load
balancing, but you can compensate for this by adjusting the weighting of traffic
to favor the stronger node. However, running on different OS platforms (e.g.,
one NT node and one Solaris node) is not supported. While technically possible,
mixed-OS environments are inherently more difficult to manage, and the effect of
differences between patch levels of the RainWall code for each platform are
unknown. We recommend that all the nodes in the cluster be on the same version
of the same OS to simplify administration and troubleshooting.
(top of page)
Does RainWall work with FloodGate-1?
RainWall is supported with FloodGate-1 version 4.1 in a hot-standby
configuration, providing fail-over for FloodGate-1 gateways. However, Check
Point does not currently support active/active load balancing configurations of
FloodGate-1. This is because FloodGate-1 version 4.1 is not "cluster
aware". Clustered FloodGate-1 gateways do not share QoS state information
the same way FireWall-1/VPN-1 share connection state information, so QoS may not
be properly enforced if more than one node is performing the bandwidth
management. In other words, you can run FloodGate-1 without errors on an
active/active load balancing RainWall cluster, but may not get the results you
desire.
In an active/active setup, QoS enforcement for the cluster as a whole will not match the defined bandwidth management policy of a single node. Take, for example, a hypothetical case where both nodes in a 2-node cluster are configured to limit FTP traffic to 1Mbps. Rather than cooperating to ensure that FTP traffic never exceeds the defined limit, each node will allow up to 1Mbps of FTP traffic, and a total of 2Mbps of FTP traffic may be allowed to pass through the cluster. If this policy was designed to make sure FTP traffic never consumed all the bandwidth on a 1.5Mbps WAN link, the goal would not be achieved. You could compensate for this by setting the limit at ½ the desired limit on each node (500Kbps in this case), but if one of the nodes fails, FTP traffic would then be limited to a total of 500Kbps, instead of the 1Mbps specified.
Some customers may be willing to tolerate this behavior, but uncertainty runs
contrary to the stated aim of FloodGate-1, which is precise bandwidth management
and predictable QoS. For this reason, use of FloodGate-1 in an active/active
load balancing configuration is not recommended. Please consult your Check Point
sales representative for more information.
(top of page)
Does RainWall work with SecureClient?
RainWall is not supported with SecureClient version 4.1 or NG. Check Point
does not currently support SecureClient policy server installation and usage on
cluster objects and cluster members.
(top of page)
RainWall Installation/Configuration
© Copyright October 8 2001, Rainfinity, Inc., San Jose, CA, USA. All rights reserved.