One of my favorite commands on SPLAT is webui. It allows you to set WEbUI on a custom port, if you like. For example, to set it on port 4434 you just need to run the following: webui enable 4434
But be careful, with R75 and up the behavior has been changed. Even if you set it up on a custom port as described above, it will get back to default 443 after reboot.
This is quite annoying, especially if you have Mobile Access Blade with SSL portal running on your GW. But no worries, there is another place, rather unusual, where you can set it up right.
For your R75 and R75.X objects, go to SmartDashboard, then double click to the managed object and choose SecurePlatform tab.
In the "Main URL" field add your port, as shown on the picture above. Push policy, now it is all good.
This is a professional blog of Check Point Certified Master Architect (CCMA). It does not represent position of my current employer.
Tuesday, March 20, 2012
Tuesday, March 13, 2012
ClusterXL flapping troubleshooting - short HOWTO
ClusterXL is one of the most interesting and yet not easy to handle parts of the Check Point products. This post is to summarize some basic troubleshooting steps when dealing with cluster instability.
Symptops: FW SPLAT based cluster is "flapping". Members periodically change status from Active/Standby to Down. In SmartView Tracker logs you can see entries about "member 1 is down" members 2 changes state to active" as well as messages of connectivity problems with cluster interfaces:
cluster_info: (ClusterXL) member 2 (192.168.0.6) is down (Interface Active Check on member 2 (192.168.0.6) detected a problem (14 interfaces required, only 13 up).)
cluster_info: (ClusterXL) interface Mgmt of member 2 (192.168.0.6) is down (receive up, transmit down)
------------------------------------------------------------
There are some basic steps for fixing it quickly.
1. Check if there is any other Check Point cluster connected to the same IP network. If there is, change so-called "magic MAC" numbers, as described in SK25977. Aplly the solution, reboot the cluster. Check if the issue is now fixed. If not, go to the step 2.
2. Check your cluster is runnign in multicast mode. To do that, run
# cphaprob -a if
You should have something to the following output:
------------------------
High Availability interfaces (cphaprob -a if)
------------------------
Required interfaces: 4
Required secured interfaces: 1
eth0 UP non sync(non secured), multicast
eth1 UP sync(secured), multicast
eth2 UP non sync(non secured), multicast
eth3 UP non sync(non secured), multicast
If you have broadcast for interfaces instead of multicast, there is something wrong with physical interfaces, cabling and switching. Otherwise to to the step 3.
3. Be sure IGMP snooping is disabled on the adjacent switch. ClusterXL uses CCP in multicast mode by default, so IGMP registration won't work on the switch side. You have to have IGMP snooping disabled globally on the switch or at least for the specific NIC ports connected to the cluster.
Once IGMP snooping is disabled, this should stop flapping. Reasons are mentioned in ClusterXL R75.20 Administration Guide on the page 31.
In case you cannot disable IGMP snooping on the switch, the last option is to switch CCP from multicast to broadcast.
To do that, run
cphaconf set_ccp broadcast
You will have to reboot the cluster again. As mentioned in the comments, reboot is not required to activate the feature.
All, if you have something to add to this, please be my guest and comment at will.
Symptops: FW SPLAT based cluster is "flapping". Members periodically change status from Active/Standby to Down. In SmartView Tracker logs you can see entries about "member 1 is down" members 2 changes state to active" as well as messages of connectivity problems with cluster interfaces:
cluster_info: (ClusterXL) member 2 (192.168.0.6) is down (Interface Active Check on member 2 (192.168.0.6) detected a problem (14 interfaces required, only 13 up).)
cluster_info: (ClusterXL) interface Mgmt of member 2 (192.168.0.6) is down (receive up, transmit down)
------------------------------------------------------------
There are some basic steps for fixing it quickly.
1. Check if there is any other Check Point cluster connected to the same IP network. If there is, change so-called "magic MAC" numbers, as described in SK25977. Aplly the solution, reboot the cluster. Check if the issue is now fixed. If not, go to the step 2.
2. Check your cluster is runnign in multicast mode. To do that, run
# cphaprob -a if
You should have something to the following output:
------------------------
High Availability interfaces (cphaprob -a if)
------------------------
Required interfaces: 4
Required secured interfaces: 1
eth0 UP non sync(non secured), multicast
eth1 UP sync(secured), multicast
eth2 UP non sync(non secured), multicast
eth3 UP non sync(non secured), multicast
If you have broadcast for interfaces instead of multicast, there is something wrong with physical interfaces, cabling and switching. Otherwise to to the step 3.
3. Be sure IGMP snooping is disabled on the adjacent switch. ClusterXL uses CCP in multicast mode by default, so IGMP registration won't work on the switch side. You have to have IGMP snooping disabled globally on the switch or at least for the specific NIC ports connected to the cluster.
Once IGMP snooping is disabled, this should stop flapping. Reasons are mentioned in ClusterXL R75.20 Administration Guide on the page 31.
In case you cannot disable IGMP snooping on the switch, the last option is to switch CCP from multicast to broadcast.
To do that, run
cphaconf set_ccp broadcast
All, if you have something to add to this, please be my guest and comment at will.
Monday, March 5, 2012
The qurious case of CCMA certification
Last year I have mentioned CCMA certification twice: in January and in May.
The first post was about CCMSE to be a new per-requisite for CCMA certification. Later that year I had to make a second post about CCMSE being just a recommendation and not a requirement for CCMA.
It would be unwise to think the story has ended there. Behold,
CCMSE is back. You have to certify both MDM and VSX to be able to continue to CCMA path.
Dear Check Point. Please make up your mind and stick to it.
Sincerely yours,..
----
P.S. Just after I posted this I have found a great post from Danny Jung: CCMA's diary. That's a great one, take a look.
The first post was about CCMSE to be a new per-requisite for CCMA certification. Later that year I had to make a second post about CCMSE being just a recommendation and not a requirement for CCMA.
It would be unwise to think the story has ended there. Behold,
CCMSE is back. You have to certify both MDM and VSX to be able to continue to CCMA path.
Dear Check Point. Please make up your mind and stick to it.
Sincerely yours,..
----
P.S. Just after I posted this I have found a great post from Danny Jung: CCMA's diary. That's a great one, take a look.
Thursday, March 1, 2012
Check Point Price List is no longer public
I was (not exactly pleasantly) surprised this morning to find out Check Point Price list access now requires valid User Center account.
Japanese part is still in public zone, but not the regular price list. Not anymore.
I do know it takes only 2 minutes to set up a new account to access price list. In my personal case I use partner quote tools for years.
But what about any new and/or potential customers, Check Point? Why should you have to limit access to the major reference tool?
What's the point?
Japanese part is still in public zone, but not the regular price list. Not anymore.
I do know it takes only 2 minutes to set up a new account to access price list. In my personal case I use partner quote tools for years.
But what about any new and/or potential customers, Check Point? Why should you have to limit access to the major reference tool?
What's the point?
Subscribe to:
Posts (Atom)