Q: Why can't I get BGP routes on my cluster interface?

A:

I have a BGP peering between the cluster interface and my Cisco router. According to both the Nokia cluster management interface and the Cisco IOS, the peering is "established". Yet there are no routes being learned by the Nokia. An identical configuration with a non-clustered Nokia does learn the routes. According to Nokia, this feature (and other clutering-related features) are not working correctly in IPSO 3.8 and an upgrade to IPSO 4.0 is warranted before any further troubleshooting is done.

Q: Why can't users behind a departmental Checkpoint talk with devices behind the Checkpoint cluster when both fwalls are on the same backbone segment?

A:

Just as a Checkpoint cluster cannot communicate with Cisco routers, it also cannot communicate with other Checkpoint firewalls by default! The other firewall will not accept a multicast address as an ARP reply. The solution is to go into Voyager on the other firewall and, in the ARP configuration page, turn on "Accept multicast ARP replies". This must have been a problem for a long time; I found the following on a Nokia KB article from 2000:

By default, IPSO will not communicate with broadcast or mulitcast MAC address via either a dynamic ARP entry or a static ARP entry. When it sees a multicast or broadcast ethernet address being deseminated via arp, IPSO responds with the error: arp: ether address is broadcast or multicast --snip-- To enable IPSO to use received multicast MAC addresses, go to the ARP configuration page in Voyager. Select on for the option Accept multicast ARP replies. This option appears to be available in IPSO 3.2 and later.

This is similar to the communications problem between the Cluster and Cisco routers noted earlier here.

Q: How do I change the default view that comes up when I first start SmartView Tracker?

A:

SmartView tracker is the Windows application which is used to watch the firewall logs. When it first starts up, a default view is loaded. This default view has "resolve names" turned on, so I immediately have to go in and turn it off each time I start Tracker, but by then Tracker has already tried to look up a few names (including, perhaps, names of attackers that have been dropped by firewall rules, thus alerting them if they are watching their DNS logs). I have not found a way to edit the default view, so that name resolution is turned off. If you know a way, please leave a comment, and I'll incorporate it in this FAQ. TIA Update: a comment pointed me to Checkpoint SecureKnowledge article sk30141. Based on that article, I here's how to do it: Your queries are stored in your program PC's program files directory (C:\Program Files\CheckPoint\SmartConsole\R55\PROGRAM or whatever). Each query is a file named #.vd. Query 0.vd is the default one you see when you start Tracker. So to make your favorite search the default, go into Tracker and modify it slightly, save it, then exit Tracker. Sort the programs directory by date and look for the #.vd you just modified; rename it 0.vd. Next time you start tracker, it will be the default.

Q: How do I get the Checkpoint cluster to redistribute certain interface routes into OSPF?

A:

I was surprised to note that in Voyager for IPSO 3.8.1 there is no option to redistribute cluster interface routes into OSPF. That means I cannot get the firewalls to tell OSPF that it has a route to the DMZ segments. There is an option to redistribute static routes into OSPF, but Voyager will not even let me enter a route to one of the interface networks as a static route, because it already has it as an interface route. So there is no possibility of a workaround this way. I ended up entering a static route to each of the DMZ networks via the firewall on the router just inside the firewall, and injecting those routes into OSPF there. Last year, someone noted that originally routers tried to be firewalls. They didn't do this very well, so separate firewalls became the norm. Now, firewalls are trying to be routers, and it seems in this case not doing a very good job of it at all. UPDATE: according to Nokia, this and other cluster-related features are not working in IPSO 3.8.1. An upgrade to IPSO 4.0 is warranted before any further troubleshooting .

Q: How do I get my Cisco router to communicate with the IP of my Checkpoint active/active cluster?

A:

A Cisco router will not be able to communicate with a Checkpoint cluster at the cluster IP address without special help. This is because on the Checkpoint the cluster IP is bound to a multicast MAC address, and either the Checkpoint cluster by default fails to answer ARP broadcasts looking for that cluster IP, or the Cisco router refuses to accept or recognize the ARP replies. One way around this is to figure out the MAC address associated with that multicast address, and put a static ARP entry on the Cisco device associating that multicast MAC with the cluster IP (which is not a multicast IP). Here's how:

1. Find out the multicast IP address associated with the cluster IP with which you need to communicate. The multicast IP can be found by logging into Voyager as cluster admin, and going to the same "cluster configuration" where you assigned the IP addresses. The multicast address is shown in the right column of the IP address assignment form.
2. As you know, any multicast IP address can be directly converted to a multicast MAC address by masking off the leftmost 5 bits of the IP, taking the remaining 23 bits of the IP, and ORing them with 0x01001e7f0000. See here for a quick explanation of this.
3. At the Cisco device, put in a static ARP entry using the command arp {unicast cluster IP} {multicast cluster MAC}.

You have to put in a static ARP entry for every IP address that the Checkpoint is supposed to be listening on. This means if the Checkpoint is doing NAT for a whole bunch of addresses, you'll have to be very careful to add a static ARP entry on the Cisco for each of them. They will all be at that same multicast MAC address you calculated. [Update] Nokia/Checkpoint clusters do not even communicate with other Nokia/Checkpoint firewalls by default! I've logged this as a separate FAQ: here.