Firewall upgrade issues

[FireGromit]

So want to upgrade from a Checkpoint 4200 to a Checkpoint 6200.

I got a copy of the configuration off the 4200 via CLI, applied it to the 6200, added the new firewall to smart console and pushed the policy, but the devices do not work on the new firewall. Looking at the logs I see traffic getting dropped. I’ve tried to set the policy to any, any, set the interfaces to external, Disabled anti-spoofing on the interfaces, but it still drops the traffic before any of my settings are applied. So the question is what causes this? The vendor says the deep packet inspection must be disabled, is there a way to verify if this is on or off? If I swap the device connections back to the 4200, everything works fine.   Both interfaces are external networks, only my Management interface in internal to the network. The basic topology is the phones use the corporate network to make calls, if the local network goes down for some reason, it fails over to satellite and the phone work via the satellite. 

set interface eth1 comments "phones"

set interface eth1 link-speed 100M/full

set interface eth1 state on

set interface eth1 ipv4-address 192.168.210.1 mask-length 28

set interface eth2 comments "Satellite"

set interface eth2 state on

set interface eth2 auto-negotiation on

set interface eth2 mtu 1500

set interface eth2 ipv4-address 10.212.35.70 mask-length 28

Another question I have, If I make changes on the interfaces via smart console, are the changes applied immediately, or do I have to install policy before any changes take affect?

[_Val_]

I am not sure the interface names are the same in 4k and 6k series. After replacing the FW, did you pull interfaces with topology? The log says "antispoofing", meaning the topology is not okay. 

[Bob_Zimmerman · Accepted solution]

I'll answer your last question first, since it's easy and it helps point to where the issue is.

Check Point firewalls have OS-level configuration and application-level configuration. The OS-level configuration is done through the command line. All your 'set interface' stuff is OS-level. The firewall application isn't aware of any of that directly. Application-level configuration is done through SmartConsole. Changes to OS-level configuration are immediate. Changes to application-level configuration take a policy push to apply.

The drop message says the traffic is dropped due to address spoofing. That means one of two things: either your OS-level routing isn't set up correctly, or your application-level antispoofing topology isn't set up correctly. You should check the routing to make sure some CLI command didn't get dropped when you brought over your config, but the problem is likely to be the antispoofing config.

In SmartConsole, look at each firewall's topology table. My bet is the old firewall has some antispoofing groups and the new one doesn't.

[FireGromit]

> In SmartConsole, look at each firewall's topology table. My bet is the old firewall has some antispoofing groups and the new one doesn't.

Since the old firewall and new firewall share the same IP address, I replaced one with the other in smart console, so I no longer have access to the exact setting that were in smart console. I guess i could add it back on, replacing the new one, but I doubt smart console would remember what those settings were. 

The answer to the second part helps. looking at another similar firewall, performing the same functions, there is one interface set as an internal and the other external, I copied that configuration, but didn't do an install. So all the changes I did to the interfaces via smart console to troubleshoot the issue didn't apply in the first.   

[PhoneBoy]

Anytime you make a change in SmartConsole, for it to take effect on the gateways, the session must be published and the policy must be installed to the gateway.

[Bob_Zimmerman]

Deleting the old object before the new firewall is functional is a really bad idea. You shouldn't do that in the future. You generally shouldn't even make a new firewall object. Just use the same object, reset SIC, establish it with the replacement firewall, and push policy.

You can view old management database states. Manage & Settings > Sessions > Revisions > pick a revision, then hit View.

[the_rock]

Not according to TAC and I agree with them, sorry. I think its actually better to delete the old object, because it makes database cleaner.

[Bob_Zimmerman]

Who suggested that? It's a waste of time, and leads to issues like this when some config from the old object isn't brought over. The whole point of firewall objects in a management database is to give the management server a standardized view of the hardware so it doesn't need to care about the implementation details like what server it's on.

When a cluster member fails, do you build a whole new object for the replacement one?

[the_rock]

Who told me that? At least 5 TAC engineers and I agree with all of them. I had been doing it that way for ages and never had a single problem. Thats your opinion its waste of time, to each their own : - )

[TechGromit]

I agree, by not wiping all the settings, I was able to utilize the old firewall while the new firewall was getting set up, so there was no user outage. I had the rack space and power to run both, so why not run both. After I had issues, I was able to troubleshoot using the management interface on the new firewall and leave the interfaces on the old firewall, only occasional moving them over to test.

[TechGromit]

Ok the good news is this worked, Setting the one interface external and the other interface internal, and installing the settings, everything worked fine, even with anti-spoofing enabled again.  But I really don't understand why. I had previously had both interfaces set for external and anti-spoofing disabled, (and Installed) but was still getting packets dropped due to spoofing.  I read somewhere that disabling anti-spoofing can only be applied globally, if this is true, then what is the point of having the option on interfaces to disable anti-spoofing if it does nothing. If anti-spoofing can be disabled on the interfaces, then no packets should have been dropped. While I understand that disabling anti-spoofing isn't exact the correct way to set up a firewall, I was just trying to get it to work and narrow down the the problem was from there.

[the_rock]

I agree with both @_Val_ and @Bob_Zimmerman