IPSEC PHASE2 not coming up

[Nick_Shah]

I have built a IPSEC tunnel between PA and CP. When i initiate traffic from PC sitting behind CP, phase 1 comes up on both FW. But phase 2 fails, i tried every possible modification in phase 2 settings(same on both end), changed intresting traffic (subnet) coming to CP as well. But i couldn't succeed. 

CA has10.168.1.0/24

PA has 200.1.1.0/24

Below logs i captured.

PHASE1:

PHASE1

PHASE2:

PHASE2 FAILED LOG

PA PHASE 1 shows UP

TCPDUMPtcpdump

I reset the tunnel and initiated traffic from PA and i am able to ping. If there was config mismatch i shouldn't be able to reach from PA as well.

Router#ping 10.168.1.1 rep 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.168.1.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 24/31/44 ms

Thanks

[PhoneBoy]

It’s a configuration issue if you can initiate a VPN connection in one direction but not the other.
A full set of debugs will be helpful: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
Many common issues with third party VPNs are listed here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Timothy_Hall]

Need to see the two ID fields decoded in  QM packet 1 when the Check Point is the initiator.  Whatever is there does not match the Palo Alto which uses a universal tunnel (double 0.0.0.0/0's) by default, but the Palo can be configured to mimic a domain-based VPN via the configuration of Proxy-IDs.  Did you configure that on the Palo side?  If so they must EXACTLY match what the Check Point is proposing in Phase 2, a subset will not work.  But a subset will be accepted by the Check Point if the Palo is proposing which is why it works in that direction.

If the Palo receives a Phase 2 proposal that doesn't match its configuration the Palo will just discard it and not answer (which is what the tcpdump shows), same as Juniper.  Funny I seem to recall a lawsuit awhile back about these coincidental similarities... 

[Nick_Shah]

@Timothy_Hall Thanks for responding. Yes in PA i removed the subnet and defined /32 host IP and on CP i did few changes in database tools (snaps attached). This worked.

Thanks,

Nick