>From what I recall from setting up VPNs from us to sites which used
Checkpoint VPNs in a load balanced environment, the problem is that
Checkpoint runs VPNs slightly differently.
VPNs are between 2 IP addresses. As I recall, in a Checkpoint load-balanced
cluster, the end of the VPN is on the inside interfaces which have different
IP addresses on different firewalls. When the VPN traffic floats between the
firewalls, the end-point IP address changes and the non-Checkpoint end fails
because the IP address is no longer the one it established the VPN with.
People who have read the standard have indicated that breaking the VPN is
the proper action.
The only way that we could get our VPN to work was to fix the end-point of
the VPN to one interface on one of the Checkpoint firewalls. I believe, but
am not sure, that this was an IP address on an outside interface. Again, I
don't work with Checkpoint firewalls so I am not positive on this. The
firewall person at the Checkpoint site was rather upset since this
essentially removed the redundancy that he had intended by purchasing
Checkpoint but apparently neither he nor Checkpoint support could find
another alternative.
I've heard that a VPN between Checkpoint clusters works which implies that,
if true, they've modified the standard to add functionality and (I can say
since proprietary-izing a standard by adding non-standard [and, in
Microsoft's Kerberos case, non-shared] functionality to exclude competitors
has been practiced for decades) to add or lock-in market share).
To summarize, the basic issue is that the VPN protocol is designed to
operate between 2 specific IP addresses. If either of the IP addresses
change, the VPN protocol correctly assumes that the VPN is being attacked.
Checkpoint's cluster/load balancing environment results in a changing IP
address which breaks the VPN.
Note: I believe that end-point can be on a system inside your firewalls; I
think that Checkpoint will allow the VPN setup to pass through your
firewalls if you configure them properly- although you might not want to
open the UDP/TCP ports.
Liolis mail below seems to indicate that you might be able to configure the
connection state mechanism to work. Checkpoint may have a fix for the
problem described above by now and Liolis may be referring to that fix. If
so, I haven't heard about it.
> -----Original Message-----
> From: LIOLIS,SPIROS (HP-Greece,ex1) [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, June 07, 2001 1:10 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: Problems with VPN's with CheckPoint and StoneBeat
>
> It seems to me that the cluster is not set up right. The VPN is dependent
> on
> Stateful connection and apparently the cluster is not configured right.
>
> Could you please tell me a bit more on the cluster configuration?
>
> Regards,
>
> Spiros
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, June 06, 2001 4:51 PM
> > To: [EMAIL PROTECTED]
> > Subject: Problems with VPN's with CheckPoint and StoneBeat
> >
> >
> > Hi all,
> >
> > Has anyone encountered problems with setting up VPN's with a
> > CheckPoint
> > FireWall-1 clustered/loadbalanced with StoneBeat? We have
> > been testing this
> > for a while and cannot get it to work. We installed the
> > latest ServicePack
> > (SP3). The fail-over does not work and the continuity of the
> > VPN is not
> > stable. Connections get lost when system fails over or when the system
> > resumes in the cluster, also connections get lost after some time.
> >
> > Thanks in advance.
> >
> > Natascha Caris
> > -
> > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > "unsubscribe firewalls" in the body of the message.]
> >
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
