R80.20 Publish failed - Validation errors but empty Validation Pane

[Michael_Adjei]

Hello Team CM,

Wondering if anyone has come across an interesting issue in R80.20 where publishing changes fails due to validation errors. After fixing the issues that caused Valdiation errors resulting in an empty validation pane, still unable to publish changes in Smartconsole R80.20.

Migrated from R77.30 standalone to R80.20 Management only.

Additional actions taken:

• Restart Check Point Services
• Reboot Management Server
• Install Hotfix Take 33 over R80.20

[Daniel_Taney]

Do you have a lot of unpublished changes? I'm wondering if its just some weird bug and would resolve itself if you discarded the changes in your sessions and tried again? 

[Michael_Adjei]

Hello  Daniel,

Thank you for your response but in this case, the changes are actually the fix for the original validation errors.

[Ron_Izraeli]

Hi Michael,

This issue might be caused due to a validation incident created during the publish procedure.

It is safe to say that this kind of user experience require our attention.

However, it is possible that you issue is already solved. If you SSH to your security management server and review the CPM log file ($MDS_FWDIR/log/cpm.elg) and scroll to its bottom right after getting the error message, you'd be able to see the incident details. At that point you could look it up in Check Point User Center and learn if this issue was already addressed.

You are welcome to contact me in private if you need additional guidance/assistant.

[Michael_Adjei]

Hello Ron,

I have tried again and then looked at the cpm.elg file as suggested:

PublishException- OuterException=
 com.checkpoint.management.coresvc.PublishException
    at com.checkpoint.management.dleserver.coresvc.internal.FwmSvcImpl$1.doPublish(FwmSvcImpl.java:6)
    at com.checkpoint.management.dleserver.coresvc.internal.operation.OperationSvcImpl.doPublish(OperationSvcImpl.java:462)
    at com.checkpoint.management.dleserver.coresvc.internal.operation.OperationSvcImpl.publish(OperationSvcImpl.java:786)
    at com.checkpoint.management.dleserver.coresvc.internal.WorkSessionMgmtSvcImpl.doPublishAuditLogs(WorkSessionMgmtSvcImpl.java:1603)
    at com.checkpoint.management.dleserver.coresvc.internal.WorkSessionMgmtSvcImpl.doPublishAuditLogs(WorkSessionMgmtSvcImpl.java:1548)
    at com.checkpoint.management.dleserver.coresvc.internal.WorkSessionMgmtSvcImpl.publishAuditLogs_aroundBody94(WorkSessionMgmtSvcImpl.java:1327)
    at com.checkpoint.management.dleserver.coresvc.internal.WorkSessionMgmtSvcImpl$AjcClosure95.run(WorkSessionMgmtSvcImpl.java:1)
    at org.aspectj.runtime.reflect.JoinPointImpl.proceed(JoinPointImpl.java:149)

   ........

Then gain if you scroll to further down to the end of the cpm.elg log file:

at com.checkpoint.management.dle.aspects.LockAspect.ajc$inlineAccessMethod$com_checkpoint_management_dle_aspects_LockAspect$com_checkpoint_management_dle_aspects_LockAspect$handleLock(LockAspect.java:3)
    at com.checkpoint.management.dle.aspects.LockAspect.aroundLock(LockAspect.java:56)
    at com.checkpoint.management.dleserver.coresvc.internal.WorkSessionMgmtSvcImpl.publish(WorkSessionMgmtSvcImpl.java:1453)
    at com.checkpoint.management.dleserver.coresvc.internal.WorkSessionMgmtSvcImpl.publishSessionOfSingleDomainInternal(WorkSessionMgmtSvcImpl.java:640)
    at com.checkpoint.management.dleserver.coresvc.internal.WorkSessionMgmtSvcImpl.publish(WorkSessionMgmtSvcImpl.java:2870)
    at com.checkpoint.management.web_services.dleserver.internal.WorkSessionMgmtSvcRemoteImpl$2.run(WorkSessionMgmtSvcRemoteImpl.java:1)
    at com.checkpoint.management.dleserver.coresvc.internal.AsyncOperationSvcImpl$1.run(AsyncOperationSvcImpl.java:17)
    at com.checkpoint.management.coresvc.CPRunnable.run(CPRunnable.java:5)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.lang.Thread.run(Thread.java:785)

25/02/19 11:02:54,287  WARN INACTIVE_TRANSACTIONS [taskExecutor-16]: Transaction is ended with no actual database access. see /opt/CPsuite-R80.20/fw1/log/inactive-tx.elg for details
25/02/19 11:03:21,899  INFO cpm.commands.Server [main]: <<== Memory Report: Total Memory - 762 MB; Used - 715 MB, Free - 47 MB, Heap - 715 MB, Non Heap - 151 MB, Percent Used - 93 %==>>
25/02/19 11:03:21,900  INFO cpm.commands.Server [main]: <<== Threads Report: number of threads - 108 ==>>
25/02/19 11:03:24,521  WARN INACTIVE_TRANSACTIONS [taskExecutor-10]: Transaction is ended with no actual database access. see /opt/CPsuite-R80.20/fw1/log/inactive-tx.elg for details

[Ron_Izraeli]

Unfortunately, i didn't find an existing case. Please continue and open a TAC case.

[Michael_Adjei]

Hello Ron,

I managed to find the root cause. I basically discarded all changes and published once per change the error appeared again.

The culprit change seemed to be after trying to change the name of the old Management server object to a new one. It seems that the ICA was either corrupted before or after the change for some reason and also was complaining about VPN certificates being used when the old standalone object was not used for VPN.

I decided to revert back to R77.30 and make all the changes there instead including creating a new ICA even though "Where used and Replace" feature is much smarter and easier in R80.xx.

I also used sk108966 - Unable to renew VPN certificate during the fwm sic_reset step trying to recreate the ICA.

Thanks Dan and Ron for your responses.

[Ilmo_Anttonen]

Hi,

I ran into a similar issue and followed the steps recommended in this thread. I was replacing old UTM-1 Edge gateway objects with Interop-devices after disconnecting them from smart-center. Suddenly I wasn't allowed to publish and nothing in validations pane. Only 14 changes so not much.

Tailed the cpm.elg:

11/07/19 12:52:19,566 INFO coresvc.internal.WorkSessionMgmtSvcImpl [taskExecutor-59]: sending async publish in progress 10 notification for liveId e199f45c-27d0-40b3-8f0e-802d27e3ea94.
11/07/19 12:52:19,566 INFO coresvc.ngm_api.AsyncPublish [taskExecutor-59]: publish progress liveId(e199f45c-27d0-40b3-8f0e-802d27e3ea94) progress(10) message()
11/07/19 12:52:19,566 INFO coresvc.internal.WorkSessionMgmtSvcImpl [taskExecutor-59]: publish: publishing domain 41e821a0-3720-11e3-aa6e-0800200c9fde session: bQZr0Ity9LAANh04nOwuPuFJo8VdeVliB9BK0bjc1Wo...
11/07/19 12:52:19,567 INFO coresvc.internal.WorkSessionMgmtSvcImpl [taskExecutor-59]: publish(startNewSession=true, asyncPublish=com.checkpoint.management.web_services.dleserver.internal.WorkSessionMgmtSvcRemoteImpl$2@b44b64df, force=false, lastSessionToPublish=true)
11/07/19 12:52:19,568 INFO coresvc.internal.WorkSessionMgmtSvcImpl [taskExecutor-59]: Test is domain a CP data domain: 41e821a0-3720-11e3-aa6e-0800200c9fde false
11/07/19 12:52:19,568 INFO coresvc.internal.WorkSessionMgmtSvcImpl [taskExecutor-59]: Session description enforcement is relevant for domain: 41e821a0-3720-11e3-aa6e-0800200c9fde
11/07/19 12:52:19,593 WARN INACTIVE_TRANSACTIONS [taskExecutor-59]: Transaction is ended with no actual database access. see /opt/CPsuite-R80.20/fw1/log/inactive-tx.elg for details

Checking /opt/CPsuite-R80.20/fw1/log/inactive-tx.elg gave nothing. Only older entries.

Then by publishing the changes one-by-one I got through withut errors. Continuing on to the next one.
When I added the interoperable device to the VPN community (in the interop object) and klicked OK I get the following two:

"Failed to save object <vpn-gw-name>.
A blocking validation error was found: You must select at least one gateway to set permanent tunnels with its peer gateways"

Click OK and the next one comes:

"The current changes to object <vpn-gw-name> parameters are invalid and therefore will be discarded"

In effect that removed the newly added interoperable device from the community. After I re-add it and publish no problems.
Here I rebooted the mgmt-server and went on with the next. Again same error. 

So I have a workaround where I just re-add the object, but I cannot figure out why it started. I've done about five conversions to interoperable devices prior to this happening only today.

Background reason to conversion: We have a legacy with a large pool of Edge boxes installed some five-six years ago and now the policy has grown too large for them to accept it. They just crash if you install it on them. So by converting them to non-managed we can exempt them from the current policy and get some breathing space until they are replaced.