| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| Hello, We have two Nokia IP330s running IPSO 3.8 and Check Point NG R55. The two firewalls are configured for HA and had been running fine for over a year. This past week we pushed a new policy and after the policy was pushed both firewalls reported their status as Master for all 7 interfaces we have clustered. I rebooted one of the firewalls and as it was booting the following was logged: Information: cluster_info: (3rd Party Cluster) State change of member 2 (x.x.x.x) from active to down was canceled, since all other members are down. Member remains active. After this message was logged both firewalls again reported as Master for all clustered interfaces. I have checked the topology and everything looks good, the only thing I noticed was that I can not ping the other side of the sync network I have setup. I am not sure if this is normal, but its just something I noticed while troubleshooting. I have not been able to do much troubleshooting due to the connectivity problems that are caused when both firewalls are up. Any ideas? |
| |||
| I have the same problem ever since I changed the inside ip addresses on my Nokia VRRP pair of IP530's. I also haven't been able to troubleshoot well since it takes down the network to have both firewalls plugged in. The policy is blocking the VRRP advertisements. If I cpstop on the machine that's supposed to be backup, the interfaces go to backup. So, the policy on that machine is blocking the advertisements from the "true" master. When I cpstart, the backup goes master, while the other stays master. I also can't find anything wrong with the policy or topology. |
| |||
| Can you try to take a look from the log. See whether the traffic between 2 interfaces (cluster) are able to communicate with MCAST packet? check the anti-spoofing and the firewall policy should help. |
| |||
| Nokia says in an info to IPSO 3.6 (R55 already has a "vrrp" service): Double Check to make sure the Firewall is allowing VRRP packets out of its interfaces: Create a workstation object with the name VRRP-MCAST-NET for address 224.0.0.18 Create the VRRP service in FW-1 as follows: Open the Services Manager Select New -> Other Type vrrp in the Name field Enter ip_p = 0x70 in the Match field |
| |||
| Changing IP addresses on your VRRP interfaces will cause trouble. You have to remove the interface from your VRRP config first before changing addresses. In some cases you have to remove the VRID and setup VRRP config again for all interfaces to get it work. If only changes to rulebase is made just make sure before applying you can use database revision control to revert to your working policy. |
| |||
| I had this problem a couple of times the only quick solution was to recreate the VRRP table (Simplified mode). In my case I had been changing the VIP and was getting unstable FW state. Hope that helps |
![]() |
| Thread Tools | |
| Display Modes | |
| |