Default policy loaded after indefinite power off

[Xavier_Koenig]

Hello Checkmates, was hoping someone could shed some knowledge on my issue. We have been doing a multi-site deployment including high availability pairs of 3200's and 5100/5400's, and it seems that if a device stays powered off for longer than a week a default policy is loaded on each device and must be unloaded before finishing the configuration. My current process is to IP the devices, load a local license, set static routes, then ship them to their destination. Once on site I establish SIC and push policy from our management server. This wouldn't be much of an issue, but we are shipping these devices across the US and I am forced to rely on various local techs to connect to them through a putty session to accomplish this. 

My question is this: could my issue be a known bug or feature, and if so, are there any commands that exist to disable the auto-policy? Thanks in advance!

[PhoneBoy]

I've never heard of this being either a bug or a "feature."

Console messages from the first boot after an extended period of time would be helpful to understand what is going on.

[Xavier_Koenig]

Managed to get console boot logs last night from our deployment; seems both clustered firewalls needed to have the local policy unloaded before I was able to establish access via SSH/HTTPS. Almost the instant my local contact ran the command, my TCPing on 443 came up and I had restored access. I'd really enjoy it if this was just something simple I overlooked when I do the initial config on these gateways.

[PhoneBoy]

Your boot messages shows:

FireWall-1: starting external VPN module -- OK
Note: This machine is not defined as a part of any Cluster.
It is possible that the IP of this machine as it appears in your hosts
file differs from the general IP of this machine in the Management server.
Alternatively, Check your Cluster configuration in the Management server.
If this machine is no longer part of a Cluster, please disable Check Point ClusterXL
or State Synchronization on it.

Which suggests Maarten Sjouw‌ is on-track with his suggestions.

[Xavier_Koenig]

Sure thing, let me see if I can replicate the issue next time it happens. We have another site to turn up tomorrow so I'll have my local contact get me some information when we turn them on.

[Maarten_Sjouw]

As soon as you run the first time wizard the initial policy is loaded. As an MSP we ship out many device all over the world and there have been some issues that we have ran into and solved them. Here are some of the possibilities:

• the interface you use to connect, needs to be set as the management interface.
  • we use eth1 so the command is: set management interface eth1
  • what it does, it will set the interface open for ssh once hooked up, and it sets the host name in the /etc/hosts file.
• Use a different interface to stage the devices with a staging IP that you can reach from management
  • make sure to set all your interfaces with their eventual IP's and routing
  • establish SIC and collect the interface info from the device and double check and correct if needed
  • push policy and attach your central license
  • remove the staging interface IP via console and remove routing for that interface.
  • DON'T forget to save config
• Ship to site
• Install in rack connect cable and power on
• You're up and running.

Been using the staging method for more than 10 years now and only had some issues when we forgot to set the management interface. 

[Xavier_Koenig]

On the appliances we are deploying, they all have a factory-specified management port(port 6 on the 3000, port , so I leave that option alone. For staging, I have a separate NIC on my computer with a static IP that connects to the management's default 192.168.1.1/24. I configure it all the way to setting my routes, changing the mgmt IP, then double check my work(and save config) from my console session. It's just odd because it seems the longer these devices sit powered off, the higher the chance of this locked down default policy existing happens. I'll investigate the full scope of it during our deployment tomorrow, but previously I've been unable to access them via multiple pre-configured interfaces over SSH and TCP/443.

[Maarten_Sjouw]

Xavier,

That the port has the Name Mgmt nor that it has a label on the box that says Mgmt does not mean that this is the ONLY port you can use for that! It is just a name and a label nothing else, the port is exactly the same as the other 5 (on 3200).

Again as soon as you run the First Time Wizard, the Initial Policy is loaded every time you start the box up.

When you change the IP of the port that is assigned as management port, it will NOT always correctly update the host setting. Be aware to run set management interface AFTER you changed the IP on the port that you will be using to access the unit after you have it installed.

[Xavier_Koenig]

Correct, I get that you can set/change the mgmt port but that's interesting that it might not update the host setting post IP change. I've got a stack of 3200's sitting behind me waiting to get configured, so I'll try explicitly setting the management interface after configuring the IPv4 address and see if the issue goes away. Thanks!

[Maarten_Sjouw]

After you changed the IP just do a

   show host names

and see if the IP has changed for the hostname to the new IP 

[Xavier_Koenig]

Alright, running the command "show host names" on a 3200 I'm configuring right now has reflected the correct(new) management IP address. Here's hoping for no issues come deployment time!

[Maarten_Sjouw]

Before you ship the next one do the following:

save config after you mad all your changes

reboot

change the IP on your PC and see if you can connect to the new IP

double check static and default routes, host names and management interface.

Make sure there is only 1 default route, that the interface you SSH into is set as the management interface!