cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Who rated this post

Hey @nitesharbale ,

 

I belive this could be caused by the supernetting that I mentioned

- When Palo Alto initiate the tunnel, for phase2 negotiation it will use the network as you have configured them in the proxy-id and Checkpoint will accept that

- But when Checkpoint is initiating the tunnel it is possible that it will try to use a supernet, which is different from what Palo is expecting and it will not accept the proposal.

 

First you should confirm this by looking at the system logs on the Palo - as it is reponder you should see some explanation why it is failing. If Monitor -> System Logs are not providing such information you can try run a vpn debug on the Palo

 

- Here you can see how to enable debug for single VPN peer (which you should always to in real life) - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClcKCAS

- And here you can see some other commands that can use to troubleshoot vpn. From here you should check where the debug output is located and how to read it. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClivCAC

 

The debug output can be overhelming, but you should be able to see somewhere between the lines what is sent by the Checkpoint.

If my assumtion is correct and you see different range for local or remote encryption you may need to look at how to override this supnetting

View solution in original post

Who rated this post