 |
General 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
General Questions
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)
What are the key features of RainWall?
- Transparent fail-over of connections, including encrypted VPN
tunnels
- Maintenance without downtime by adding or removing nodes from
a running cluster
- Dynamic load balancing on a per-IP or per-connection basis
- Linear scalability in increasing performance
- OPSEC Certification for high availability and load balancing
- Cluster management with intuitive GUI or command line utilities
- Centralized and automated configuration of remote nodes
- Application-aware health monitoring
- Customizable failure notification
- True software-only solution, no additional hardware required
- Integrated solutions available from OPSEC appliance vendors
(top of page)
How is RainWall different from other high availability
solutions?
- Cost Effectiveness: RainWall is a software only solution that
directly installs on VPN-1/FireWall-1 servers, so it uses no additional
expansion slots or rack space and is immune to "forklift
upgrades" of proprietary hardware. For a fraction of the
cost of hardware-based layer-7 switches and server load balancers
required to create a "firewall sandwich", RainWall provides
true firewall and VPN load balancing, and ultra-reliability for
your mission-critical applications.
- Active-Active Clustering: RainWall offers much more than just
a hot standby. With RainWall, all nodes are active at all times,
so performance is increased and the viability of the backup system
is never in doubt. As a true peer-to-peer clustering solution,
a RainWall cluster has no idle nodes or a master node.
- Dynamic Load Balancing: More than just static load sharing,
RainWall's intelligent load balancing feature measures each VPN-1/FireWall-1
server's traffic load in real-time and dynamically rebalances
traffic flows to maximize total throughput.
- Linear Scalability: RainWall scales linearly, increasing firewall
and VPN capacity as nodes are added to the cluster, by taking
full performance advantage of LAN switching. Older HA solutions
have an upper performance limit because they use a single, shared
MAC address for all machines in the cluster. RainWall uses an
advanced layer-3 clustering architecture that uses bandwidth efficiently
and leverages switched network environment.
- Application-Aware Health Monitoring: RainWall monitors VPN-1/FireWall-1's
application health as well as physical connections. More than
hardware systems that test reply packets or content verification,
RainWall monitors the firewall process and checks for proper enforcement
of the security policy.
(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.
- NG Support. RainWall has been tested for interoperability with
Check Point Enterprise Suite NG using the test cases that are
required by OPSEC certification for the high availability with
load balancing category. RainWall also supports the latest service
pack for VPN-1/FireWall-1 4.1, SP5. RainWall 1.6 is currently
undergoing OPSEC certification.
- Web-Based Configuration Wizard. Management of clustered nodes
has been simplified by providing a web browser-based GUI from
which a user can centrally configure remote nodes rather than
having to repeat editing configuration files. When the configuration
wizard starts, the GUI guides the user through a series of steps
in gathering relevant configuration settings, creates a configuration
file, and automatically distributes the file to all nodes in the
cluster. When configuration settings are changed, the current
configuration file is backed up before updating it locally and
remotely. The configuration wizard synchronizes changes that are
made by editing files directly.
- Clustered Nodes Automatic Configuration Verification. The configuration
wizard automatically detects and reports configuration discrepancies
across different nodes in a cluster. This configuration verification
utility analyzes operating system as well as Check Point and Symantec
configuration settings that affect RainWall clustering.
- CGSS Fail-Over. RainWall provides an option to fail-over CGSS
traffic from one subnet to another if network problems prevented
reliable CGSS communications. A dedicated subnet must be set up
to transport CGSS traffic and fail-over to a shared subnet in
order to detect switch failures and recover from them using this
option.
- Gigabit NIC Support. RainWall has been tested for interoperability
with the leading Gigabit Ethernet NICs.
- Intrusion PDS Appliances Support. RainWall has been tested for
interoperaiblity with Intrusion.com's PDS 2315, 5115, 5315, and
5515 VPN/Firewall security appliances on PDS 2.2 operating system
and Check Point VPN-1/FireWall-1 4.1 SP4. RainWall does not support
PDS appliances with VPN-1/FireWall-1 SmallOffice. For information
about how to install RainWall on a PDS appliance without a CD-ROM
reader, refer to the RainWall 1.6 Release Guide.
- Multiple Linux Kernel Versions Support. RainWall supports more
than one Red Hat Linux kernel versions to support multiple security
appliances. The appropriate driver is installed at run-time by
querying the kernel version.
- Windows 2000 Support. RainWall for Check Point introduces Windows
2000 support. System requirements are Check Point NG FP1 and Windows
2000 Server SP2.
(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.
- Proxy ARP Services. The proxy ARP services allow you to deploy
RainWall without having to configure routers. RainWall can be
set up to respond to proxy ARP requests on behalf of other hosts,
which greatly reduces the effort in integrating clustered nodes
into an existing network environment. This new configuration option
for Solaris, NT, and Linux in the rainwall.cfg file gets around
the limitations of NT's ARP command and replaces the sample proxy
ARP script for Solaris and Linux.
- VPN II Accelerator Support. RainWall has been tested with Check
Point's (Broadcom's) VPN II accelerator card on Solaris, NT, and
Linux. The VPN II driver currently available from Check Point
is incompatible with the Hewlett-Packard ProLiant Security Server - Check Point Model's Linux version. Compaq
and Rainfinity have escalated this issue and requested Check Point
to provide an appropriate driver.
- Last Node Standing. The last node in the cluster will remain
operational by default unless the firewall is down. This new configuration
option for Solaris, NT, and Linux in the rainwall.cfg file causes
the last node to ignore NIC and PING failures.
- SNMP Trap. RainWall for NT can be configured to send SNMP traps,
notifying third-party management consoles whenever a node in the
cluster goes up or down. The new configuration option for NT in
the rainwall.cfg file is used to specify the trap event and destination.
- PING Interval. This configuration option for NT in the localmonitor.cfg
file allows changing the time interval between PINGs. The PING
feature is used to monitor the health of remote hosts and routers.
- Flapping Link Management. This configuration option for Linux
in the localmonitor.cfg file controls the amount of time that
must elapse after declaring a NIC is up or down. This option eliminates
excessive VIP movement due to flapping links that fluctuate too
often between up and down states over a short period of time.
- Hewlett-Packard ProLiant Security Server - Check Point Model Support. A menu-driven script for Linux has
been integrated with the Hewlett-Packard ProLiant Security Server - Check Point Model to offer a simple
setup for customers using the standard hardware configuration
with DL320-based, DL360-based, and DL380-based SolutionPaqs.
- Solaris 8 64-Bit Mode. RainWall operates in both 32-bit and
64-bit driver modes on Solaris 8. Note that Check Point 4.1 only
supports 32-bit driver mode.
(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.
- Solaris:
Sun FastEthernet (HME driver only)
Sun Quad FastEthernet (QFE driver only)
Sun GigabitEthernet PCI v2.0 (GE driver, 1000-SX)
- Windows NT and Windows 2000:
Intel PRO/100+ Server Adapter
3Com EtherLink Server 10/100 PCI Network Interface Card
Adaptec Quartet64 (ANA-62044)
Intel PRO/1000 F Server Adapter (1000-SX)
- Red Hat Linux:
Intel PRO/100+ Server Adapter
3Com EtherLink Server 10/100 PCI Network Interface Card
Intel PRO/1000 XT Server Adapter (10/100/1000-T)
Intel PRO/1000 F Server Adapter (1000-SX)
(top of page)
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:
- Hard limits on throughput: Total bandwidth from a given LAN
segment into a single-MAC cluster is capped at the wire speed
of a single port/NIC. For example, if the cluster machines are
using 100baseT NICs, it is not possible for a hub or LAN switch
to send more than 100Mbps of traffic into the cluster. This defeats
efforts to scale performance. RAIN clusters have no such upper
limit on throughput.
- Excess overhead: Because every machine in a single-MAC cluster
receives every packet sent to the MAC address of the cluster,
system overhead is higher, and this overhead increases as nodes
are added to the cluster. For example, in a 2-node cluster with
traffic load distributed evenly among nodes, at least 50% of the
traffic a given node receives is examined and then discarded because
it is intended for a different node. In a 10-node cluster, this
figure increases to 90%. RAIN clusters do not suffer from this
type of overhead.
- Potential incompatibility with other network devices: In the
standards for Layer 2 networking, MAC addresses are defined as
a globally unique ID. If more than one machine on the LAN has
the same MAC address, some network devices may become confused.
Machines in a RAIN cluster retain a unique, legal MAC address.
For more details on the RAIN technology and Multiple-VIP approach,
please refer to the RAIN technology white paper and RainWall white
paper.
(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:
- Per-VIP load balancing is coarse-grained, and achieves a rough
distribution of traffic load among nodes. Per-VIP load balancing
achieves the greatest possible scalability with the least amount
of overhead. It is achieved by dividing traffic among VIPs, and
then moving those VIPs around in the cluster to distribute load.
It is a standard feature of popular routers and servers to be
able to round-robin among multiple default routes, either on a
per-packet or per-connection basis. For example, with a Cisco
router, you would simply add a route statement for each VIP, creating
multiple equal-cost routes to the same subnet. Less-sophisticated
devices, such as Windows 98 PCs that are not capable of handling
multiple default gateways, can simply be pointed to one of the
VIPs. To achieve coarse-grained load balancing of traffic coming
from such PCs, they can be divided into groups, each of which
uses a different VIP for its default gateway. This division can
be configured statically on each PC, but is more commonly accomplished
through the use of a DHCP server, which assigns the default gateway
to clients along with their IP address. The DHCP server is configured
to group clients into several pools, and hand out different VIPs
to different clients based on group membership.
- Per-connection load balancing is fine-grained, allowing more
even distribution of traffic, albeit with more overhead than the
per-VIP method. It is achieved by redirecting individual connections
from heavily loaded nodes to less-loaded ones. This redirection
adds a negligible amount of latency (a fraction of a millisecond),
and a certain amount of LAN overhead. The performance impact of
the added LAN overhead should be minimal in a full-duplex switched
environment, but may be significant in a shared-hub environment.
For this reason, when connection-based load balancing is enabled,
we recommend the use of switches to achieve highest overall throughput.
Per-connection load balancing is enabled by default when automatic
symmetric routing enforcement is turned on. RainWall allows you
to choose which method of balancing you prefer, distributing traffic
either round-robin, randomly, or to the least-loaded nodes.
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:
- Rule Monitor: RainWall generates an invalid packet approximately
once per second, and attempts to send it through the firewall.
If it gets through, RainWall assumes the firewall is not properly
enforcing the rule base, and will disable the node. This monitor
is enabled by default.
- Process Monitor: RainWall continually checks to see if the VPN-1/FireWall-1
daemon is present as a process on the machine. If it is missing,
RainWall will disable the node. This monitor is enabled by default.
- Status Monitor: RainWall periodically sends a 'fw stat' command
to the firewall to request status. If the firewall does not return
the expected response, RainWall will disable the node. This monitor
is disabled by default to reduce overhead, since it is not really
necessary unless the Rule Monitor is disabled.
(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
Administration and Monitoring
Troubleshooting
© Copyright October 8 2001, Rainfinity, Inc., San Jose, CA,
USA. All rights reserved.
|
|
