Ikev2 VPNs ASA and Azure

[Dieselboy]

I eventually got IOS to ASA ikev2 VPN / vti working.
I then had a requirement to set up ikev2 to Azure. Azure is great because you set up the stuff in Azure and then you have the option to download the config for your device. It's 90% correct.

I have this phase 1 config:

Code Select Expand

crypto ikev2 proposal Azure-Prop-IKEv2
encryption aes-cbc-256 aes-cbc-128
integrity sha1 sha256
group 2
crypto ikev2 proposal CV-IKEv2-PROP
encryption aes-cbc-256
integrity sha256
group 19

The proposal called "CV-IKEv2-PROP" is in use for the VPN to the ASA.  Azure wanted DH group 2 and the other options.

For about an hour I could not bring up phase 1 to Azure. Debugs showed "no proposal chosen" and when examining the info, it was stating that DH group 19 was being used and I could not see any detail about the DH group 2.

Code Select Expand

120451: Feb 14 10:54:09.162 IST: IKEv2:(SESSION ID = 508,SA ID = 1):: Receiv                                                                                   ed no proposal chosen notify
120452: Feb 14 10:54:09.166 IST: IKEv2:(SESSION ID = 508,SA ID = 1):Initial                                                                                    exchange failed: Initial exchange failed
120453: Feb 14 10:54:39.022 IST: IKEv2:(SESSION ID = 508,SA ID = 1):Next pay                                                                                   load: SA, version: 2.0 Exchange type: IKE_SA_INIT, flags: INITIATOR Message                                                                                    id: 0, length: 272
Payload contents:
SA  Next payload: KE, reserved: 0x0, length: 48
  last proposal: 0x0, reserved: 0x0, length: 44
  Proposal: 1, Protocol id: IKE, SPI size: 0, #trans: 4    last transform: 0                                                                                   x3, reserved: 0x0: length: 12
    type: 1, reserved: 0x0, id: AES-CBC
    last transform: 0x3, reserved: 0x0: length: 8
    type: 2, reserved: 0x0, id: SHA256
    last transform: 0x3, reserved: 0x0: length: 8
    type: 3, reserved: 0x0, id: SHA256
    last transform: 0x0, reserved: 0x0: length: 8
    type: 4, reserved: 0x0, id: DH_GROUP_256_ECP/Group 19
KE  Next payload: N, reserved: 0x0, length: 72
    DH group: 19, Reserved: 0x0
N  Next payload: VID, reserved: 0x0, length: 24
VID  Next payload: VID, reserved: 0x0, length: 23
VID  Next payload: NOTIFY, reserved: 0x0, length: 21
NOTIFY(NAT_DETECTION_SOURCE_IP)  Next payload: NOTIFY, reserved: 0x0, lengt                                                                                   h: 28
    Security protocol id: IKE, spi size: 0, type: NAT_DETECTION_SOURCE_IP
NOTIFY(NAT_DETECTION_DESTINATION_IP)  Next payload: NONE, reserved: 0x0, le                                                                                   ngth: 28
    Security protocol id: IKE, spi size: 0, type: NAT_DETECTION_DESTINATION_                                                                                   IP

120454: Feb 14 10:54:39.166 IST: IKEv2:(SESSION ID = 508,SA ID = 1):Next pay                                                                                   load: NOTIFY, version: 2.0 Exchange type: IKE_SA_INIT, flags: RESPONDER MSG-                                                                                   RESPONSE Message id: 0, length: 36
Payload contents:
NOTIFY(NO_PROPOSAL_CHOSEN)  Next payload: NONE, reserved: 0x0, length: 8
    Security protocol id: Unknown - 0, spi size: 0, type: NO_PROPOSAL_CHOSEN



Eventually I decided to delete the proposal with DH group 19 so that it could not be used. VPN came up immediately. I then pasted back in the proposal I just deleted.

I thought both proposals would be tried. I am a bit confused at this.

[icecream-guy]

it's  a negotiation process, are the proposals in the same order on both endpoints?

if A were
group 2
group 19

if B were
group 19
group 2

if A was negotiating to B, it should be group 2
if B was negotiating to A, it should be group 19.
at least I would think so.

[Dieselboy]

Thanks Ristau, I understand what you're saying, but I thought it would try them sequentially like it did with ikev1? But in the debug logs it looked like it was not trying the 2nd one which was the new one (DH group 2).

Now in my case, lets say A is the site where this problem was. B is Microsoft Azure and C is the main site that I control.

A is the initiator in both cases. So A initiates to site B (no control) and sends DH group 2 (as a basic example). What happens when A initiates to site C?

Still wondering if this is a bug. There has been no issue with the VPN coming up between A and C like I worried there may be over night. It's been up for almost 2.5 hours, so does not look like any problem.

[icecream-guy]

in theory, of course this is all theory...

given all 3 have a list of proposals,
if A negotiates with B,  it starts with offering it's first  proposal, if  A & B cannot agree on first proposal, A moves to second proposal, and so on until the two agree,in no agreement, tunnel not formed
if A negotiates with C, it too starts with offering is first proposal, A & C cannot agree on first proposal, A moves to second proposal, and so on until the two agree.

there is a list of things that have to match in a proposal, maybe something in that list is not matching causing issues.

here's a Cisco tech note that may help (it's for ASA 5500's tho').
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113574-tg-asa-ipsec-ike-debugs-main-00.html

[deanwebb]

Did you clear all the default stuff in the Cisco side? I've seen not clearing defaults result in lots of wasted negotiations as it tries all the other stuff before it gets to the code you actually want to use.

[Dieselboy]

Thanks guys for your help here.

Yep everything is cleared and I only have the two phase 1 configs for the internal vpn and the azure vpn.