09-06-2021 01:28 PM
Hi @nitesharbale ,
- Your local proxy ID is wrong. You need to use the local NAT range for local proxy ID as well as remote NAT for remote proxy-id.
- However it is strange that phase1 is down (proxy-id should affect phase1 only phase2). So I am wondering if there was any traffic (with no traffic trying to pass the tunnel, both firewalls will not trigger negotiation).
- Palo Alto firewalls have great CLI command that will trigger tunnel negotiation, that way you can isolate the IPsec config and see if it work, and if it is you can focus on nat, rules and routes.
- Run the following command (use the auto-complete to fill the tunnel). I would suggest you to test all proxy-ids in the tunnel.
> test vpn ipsec-sa tunnel <name-of-tunnel>:<name-of-proxy-id1>
> test vpn ipsec-sa tunnel <name-of-tunnel>:<name-of-proxy-id2>
Above will test phase2 which automatically will try to bring phase1. I prefer to use this one, as you can test both phases with single command. Note the test commands will not generate any output, they will simply initiate tunnel negotiation. After that you can check the GUI if any of the phases is green or they are still down.
- If any of the phases is still down after the test command, I would suggest you to try negotiate the tunnel from the Checkpoint side. The reason is that when peers are failing to negotiate the settings, always the responder will have more detailed logs for the reason why it is failing. If you trigger traffic behind the Checkpoint that will trigger tunnel negotiation you can check Palo Alto logs to see what is the reason. The easiest way is to check System logs under the GUI, but if that is not enough you can check this article to see more detailed logs under CLI - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClivCAC
- I haven't work with Checkpoint in a while, but I remember there was something stupid like - you need to put the original and natted local network (behind CP) in the local encryption domain.
