PDA

View Full Version : Licensing issue



oharek
2014-10-24, 12:01
Hello,

I had two Checkpoint R65 boxes and one R65 manager to push the policys to both. I upgraded all three boxes to R77.20 Gaia. Both firewalls are fine and I can push the policy out to both via the Checkpoint Manager. However I have no logs on my checkpoint mgr. Everything seems to be setup ok and Sic status etc is fine.

It looks like a license issue. I had to get create new licences for all 3 via the usercentre account but maybe I have not got the correct license on the manager so I can get logs.

Would that be correct?

If so - what type of license do I need?

thanks
Kevin

ShadowPeak.com
2014-10-24, 12:30
Hello,

I had two Checkpoint R65 boxes and one R65 manager to push the policys to both. I upgraded all three boxes to R77.20 Gaia. Both firewalls are fine and I can push the policy out to both via the Checkpoint Manager. However I have no logs on my checkpoint mgr. Everything seems to be setup ok and Sic status etc is fine.

It looks like a license issue. I had to get create new licences for all 3 via the usercentre account but maybe I have not got the correct license on the manager so I can get logs.

Would that be correct?

If so - what type of license do I need?

thanks
Kevin

That doesn't sound like a licensing issue. What you need to determine in the following order is:

1) Is the gateway writing logs at all? On the gateway run "fw log -ft -n". Within a few seconds you should see logs streaming to your screen if the gateway is not able to successfully send logs to the Security Management Server (SMS). If there is nothing make sure the fwd process is running on the gateway. (ps -ef | grep fwd)

2) Is the gateway attempting to open a TCP connection on port 257 to the (SMS) and there is no response coming back from the SMS? On the gateway run "tcpdump -ni any port 257". You should see a connection attempt every 30 seconds or so. What IP address is it attempting the port 257 connection to? Is it correct?

If there is no response at all coming back, make sure there isn't something else blocking the port 257 connection attempt and that you didn't accidentally set up your SMS as a Security Gateway as well. Run "fw stat" on your SMS, make sure it says it is not a firewall module.

3) If the gateway is attempting the port 257 connection and the three-way handshake is completing but the connection is terminating shortly thereafter (or you are just getting back a TCP Reset), then that generally indicates a problem on the SMS. Does it have enough free disk space? (df -h) Try performing a Policy...Install Database (not Install Policy) from the SmartDashboard. Make sure the fwd process is up and running on the SMS. (ps -ef | grep fwd) If still not working you may need to reset SIC between the gateways and SMS which will cause an outage.

oharek
2014-10-27, 06:31
1) Gateway is logging ok. I did see streaming logs on the screen from firewall rules

2) [Expert@UTM-BRET:0]# tcpdump -ni any port 257
10:12:50.637428 IP 192.168.0.x.61234 > 192.168.1.x.set: S 1298399548:1298399548(0) win 5840 <mss 1460,sackOK,timestamp 2929637954 0,nop,wscale 7>
IP Addresses are correct for both the gateways and the manager
I didnít see port 257 though.

[Expert@UTM-MGR:0]# fw stat
HOST POLICY DATE
localhost InitialPolicy 23Sep2014 11:04:05 : [>eth0] [<eth0]

3) Disk space is fine as all three boxes are a new install. The Manager is built on a new server. SIC between gateways is fine
[Expert@UTM-BRET:0]# ps -ef | grep fwd
admin 12273 26868 1 Oct17 ? 02:44:31 fwd
admin 17836 5515 0 10:17 pts/3 00:00:00 grep fwd

ShadowPeak.com
2014-10-27, 09:24
1) Gateway is logging ok. I did see streaming logs on the screen from firewall rules

2) [Expert@UTM-BRET:0]# tcpdump -ni any port 257
10:12:50.637428 IP 192.168.0.x.61234 > 192.168.1.x.set: S 1298399548:1298399548(0) win 5840 <mss 1460,sackOK,timestamp 2929637954 0,nop,wscale 7>
IP Addresses are correct for both the gateways and the manager
I didn’t see port 257 though.

[Expert@UTM-MGR:0]# fw stat
HOST POLICY DATE
localhost InitialPolicy 23Sep2014 11:04:05 : [>eth0] [<eth0]

3) Disk space is fine as all three boxes are a new install. The Manager is built on a new server. SIC between gateways is fine
[Expert@UTM-BRET:0]# ps -ef | grep fwd
admin 12273 26868 1 Oct17 ? 02:44:31 fwd
admin 17836 5515 0 10:17 pts/3 00:00:00 grep fwd

Your Security Management Server was mistakenly set up both for Security Management (correct) and Security Gateway (incorrect) as I theorized earlier. Try running "fw unloadlocal" on UTM-MGR (be careful not to run this on the actual firewall(s) as it will cause an outage). Logs should start flowing almost immediately. Unfortunately the only safe way to fix this is to take a migrate export, copy it off the UTM-MGR box, completely reload UTM-MGR (this time making sure to only select "Security Management" and UNchecking "Security Gateway" during the post-install wizard), and then do a migrate import.

oharek
2014-10-27, 14:54
Your Security Management Server was mistakenly set up both for Security Management (correct) and Security Gateway (incorrect) as I theorized earlier. Try running "fw unloadlocal" on UTM-MGR (be careful not to run this on the actual firewall(s) as it will cause an outage). Logs should start flowing almost immediately. Unfortunately the only safe way to fix this is to take a migrate export, copy it off the UTM-MGR box, completely reload UTM-MGR (this time making sure to only select "Security Management" and UNchecking "Security Gateway" during the post-install wizard), and then do a migrate import.

Just curious but how can you tell I have the Security Management Server set up both for Security Management (correct) and Security Gateway (incorrect)?

I appreciate your help and I will give this a go.

Kevin

EricAnderson
2014-10-27, 15:43
Just curious but how can you tell I have the Security Management Server set up both for Security Management (correct) and Security Gateway (incorrect)?


Simple answer is that your "fw stat" responded with an indication of the policy that's running on the box. For a dedicated management box it should respond with "Local host is not a FireWall-1 module".

As ShadowPeak said, the only way to truly fix this is an export, rebuild, import. Until you're able to do this, the "fw unloadlocal" will work, but it won't survive a reboot as the module will continue to load the InitialPolicy (which is currently blocking the inbound logging). You could create and push a wide open single-rule policy (any-any-any-accept) to the management server's "firewall" module (in fact, even an any-any-any-drop rule would work as the implied rules will still allow fwd to deliver logs). Again, either of these should be considered temporary workarounds until you can do a rebuild.

-E

ShadowPeak.com
2014-10-27, 16:12
Simple answer is that your "fw stat" responded with an indication of the policy that's running on the box. For a dedicated management box it should respond with "Local host is not a FireWall-1 module".

As ShadowPeak said, the only way to truly fix this is an export, rebuild, import. Until you're able to do this, the "fw unloadlocal" will work, but it won't survive a reboot as the module will continue to load the InitialPolicy (which is currently blocking the inbound logging). You could create and push a wide open single-rule policy (any-any-any-accept) to the management server's "firewall" module (in fact, even an any-any-any-drop rule would work as the implied rules will still allow fwd to deliver logs). Again, either of these should be considered temporary workarounds until you can do a rebuild.

-E

Yup, what Eric said. However the OP may not even be able to push a policy on the SMS as he probably doesn't have an actual firewall license for it unless the 15-day Trial Period window is still active.