Phase 2 Site-to-site VPN error

[nastiakhon]

Hello
I have a Site-to-site VPN configured between checkpoint and cisco ASA.
When I check through SmartView Monitor, I see that my tunnel is up.

But when I start communication, the first phase goes well, but on the second phase I receive a message

Child SA exchange: Received notification from peer: No proposal chosen MyMethods Phase2: AES-256 + HMAC-SHA2-256, No IPComp, No ESN, Group 14

Please tell me what this means.
Because on my part exactly the same parameters are set.

Thank you!

[Tobias_Moritz]

The Log message and the screenshot you posted here both shows us the configuration on Check Point side.

You have to compare it with the configuration on Cisco side.

Either ask the Cisco admin on the other side what is configured there or better check it yourself by checking the debug logs.

If you can force the Cisco side to initiate the connection, the debug logs on Check Point side will show you what the ASA is trying to do:

1. Start debug on Expert Shell: # vpn debug trunc
2. Let's the Cisco side initiate the tunnel (verify in Check Point Log that they really did try it).
3. Stop debug on Expert Shell: # vpn debug off; vpn debug ikeoff
4. Look at $FWDIR/log/ikev2.xmll with IKEView

[Matlu]

Hello 

When you mention that reading “start the connection” once you have placed the debug commands, this way for the peer to start the connection, can it be through a VPN restart from your FW?

I assume so, or am I mistaken?

Or does starting a connection refer only to traffic from Phase 2 selectors?

In a VSX, where is the debug result hosted? Is it kept in the same path as a traditional FW?

Thank you

[RamGuy239]

Like @Tobias_Moritz has already mentioned. This points to the proposal on phase 2 to not be equal on the Check Point side as on the CISCO side.

We know from the logs that Check Point is proposing:
AES-256 + HMAC-SHA2-256, PFS Group 14.

We don't know what the CISCO firewall on the other end has configured for phase 2. There seems to be a mismatch here.

By doing the debug that @Tobias_Moritz suggested you will most likely see whatever the CISCO is trying to use for its phase 2 negotiating and you will most likely see that something is off and you will have to correct it so both sides are on terms when it comes to whatever settings are being used for phase 2.

If you are communicating with whoever is controlling the CISCO firewall you could always ask them for details on what they have configured for phase 2 / IP-sec encryption. Might it be that they are not using PFS? Might they be using different algorithms?

[RemoteUser]

I have the same issue, it's been solved? And if so how?
I know it's old post but i'm ensure the same issue

[CaseyB]

You should start a new thread with all of your details so we can provide better context. No proposal chosen is generally both sides are not agreeing on the same security ciphers.

[the_rock]

Hey bro, as @CaseyB , definitely better start a new thread, so we can assist you.

Andy

[_Val_]

No Proposal chosen means that both GWs cannot agree on the Phase 2 encryption algorithm and hence cannot set a symmetric key. It usually means that the Phase 2 settings list different algorithms. 

However, I agree with a suggestion to open a different thread for your specific issue, so we could dig into the root cause properly in an independent discussion.

[Daniel_Kavan]

I'm having a similar issue and it's Turning out the cisco is proposing several groups, 21, 20, and 14.  That being said JHF99 was handling that ok, JHF118 is not.

[the_rock]

Really? Never heard of that before...Cisco asa or something else?

[Daniel_Kavan]

3120, we are hobbling along though we just re-negotiate every 2 minutes.

[the_rock]

I know every time I dealt with Cisco TAC, they would always change those settings via ssh, never ASDM. Not sure if there is something in newer versions thats different, but when I dealt with Cisco VPNs 7-8 years ago, I never encountered that problem.

[Daniel_Kavan · Accepted solution]

The cisco engineer found the solution, an odd one.  TAC is reviewing this but unchecking this specific config to sent VTI ip address to the peers fixed it.

https://community.cisco.com/t5/vpn/route-based-ikev2-vpn-issue-between-cisco-ftd-and-checkpoint/td-p...

[the_rock]

Great!