Virtual interface config (VRRP) in Check Point object

[Dominik Zanolari]

While looking at several cluster configurations done with Check Point NGX (R60, R62, R65) on Crossbeam, I see the following two variations:

General setup, on both variations identical:
- VRRP configured according Crossbeam's config guide
- Cluster properties configured according Check Point's guide, 3rd party OPSEC
- Check Point cluster configured as Other OPSEC, high availability and use state sync
- two ticks on "Hide Cluster members outgoing traffic behind..." and "forward cluster members traffic..."

Now the difference in the topology config:

Setup A:
- "cluster" as network type on all interfaces participating in VRRP
- virtual addresses defined
- one sync link in place

Setup B:
- "private" as network type on all interfaces participating in VRRP
- virtual addresses not definied
- one sync link in place

To my surprise, both configs work for basic operation (i.e. TCP state sync) upon failover. Looking at it closer revealed that Hide NAT fails i.e. state seems not to get synced on Setup B upon failover.

Personally I always configured as in setup A, as I never read or heard otherwise and I will go forward and correct the other configs. Yet I'm interested in getting your opinion. What do you see "out there" and might there be a scenario where configuring the virtual IPs within Check Point creates a problem? Check Point's documentation leaves this open and refers to each vendor's documentation while Crossbeam doesn't cover this at all, at least not in their KB and available documentation.

PS: I consider myself "fluent" on Nokia and, to some extent Crossbeam, and that's what I encounter most at customers. Don't know how things look with e.g. 3rd party solutions on SPLAT or Solaris, as I know these platforms for management purposes (SmartCenter/MDS etc.) only.

[dfwboiler]

I've setup Crossbeams C series as option B.

We did have an issue with VPN when using option B, but I cannot remember what the exact issue was with this option.
When we added in the cluster addresses in the topology it resolved the issue.