Troubleshooting Tip: Matching IKEv1 Phase 1 and Phase 2 Proposals

[AnthonyH]

Description	This article describes the method used to understand the incoming and outgoing proposals through the IKE debugs and discover where the mismatch is occurring.
Scope	FortiGate.
Solution	When establishing an IPsec tunnel between two sites, phase 1 and phase 2 must have matching proposals on both sides. Observe the status of the tunnel through FortiGate's dashboard: Dashboard -> Network -> Select 'IPsec'. In the configuration settings below, the proposals that are mismatching will be underlined for easier findings. Fortigate_A  Phase 1 and Phase 2 configuration. Fortigate_A Phase1: config vpn ipsec phase1-interface     edit "ipsec"         set interface "port1"         set peertype any         set net-device disable         set proposal aes128-sha256         set comments "VPN: ipsec (Created by VPN wizard)"         set dhgrp 14         set remote-gw X.X.X.X         set psksecret ENC v+YyXtHgEQffwKAvfQiIKkUkGxC1kmkE9BdDeqvUx9VS7SlYYRkO9vebhvtCGZYoYX7/l0Lo3/MGJwlojSXF4XkWcYg4Wmu8yrm98TgJMpTdliGtqTpKWZ66DUFxCVs3vLMN7eyU9vJ6h+8ZFNDo5+hBTauZO2stiflqUFnauMSgD49dC5W3gxRkFiuSYDO3e8u1mQ==     next end Fortigate_A Phase 2: config vpn ipsec phase2-interface     edit "ipsec"         set phase1name "ipsec"         set proposal aes128-sha256         set dhgrp 19         set comments "VPN: ipsec (Created by VPN wizard)"         set src-addr-type name         set dst-addr-type name         set src-name "ipsec_local"         set dst-name "ipsec_remote"     next end Fortigate_B Phase 1 and Phase 2 Proposals. Fortigate_B Phase1: config vpn ipsec phase1-interface     edit "ipsec"         set interface "port1"         set peertype any         set net-device disable         set proposal aes256-sha256         set comments "VPN: ipsec (Created by VPN wizard)"         set dhgrp 14         set remote-gw Y.Y.Y.Y         set psksecret ENC 39LQ1wbmkTvS/gsz6pambWtLZAQ4PC6JaYPfukd3TrVovGRXzfS34yrCXka/n1M9cSKGr/0VvQdGGD4ggtwfrQBl2VWsiXPHighQftLcWKLrcbte2Xzc0aREWU4mtLoavedNDFKSga8GY9wWmMaB8FrB4jyweBNbE67S94UjudIRxcQIEeiJA5Nxok52IW9KkTi4aw==     next     end Fortigate_B Phase2: config vpn ipsec phase2-interface     edit "ipsec"         set phase1name "ipsec"         set proposal aes256-sha256         set dhgrp 20         set comments "VPN: ipsec <----- Created by VPN wizard.         set src-addr-type name         set dst-addr-type name         set src-name "ipsec_local"         set dst-name "ipsec_remote"     next end In the CLI run ike debug commands to see why there is a negotiation failure in Phase 1: diagnose debug application ike -1 diagnose debug enable ike 0:d6d9c13fc16ecf9d/0000000000000000:304: incoming proposal: ike 0:d6d9c13fc16ecf9d/0000000000000000:304: proposal id = 0: ike 0:d6d9c13fc16ecf9d/0000000000000000:304:   protocol id = ISAKMP: ike 0:d6d9c13fc16ecf9d/0000000000000000:304:      trans_id = KEY_IKE. ike 0:d6d9c13fc16ecf9d/0000000000000000:304:      encapsulation = IKE/none ike 0:d6d9c13fc16ecf9d/0000000000000000:304:         type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=256 <----- The incoming proposal is using AES256 for encryption. ike 0:d6d9c13fc16ecf9d/0000000000000000:304:         type=OAKLEY_HASH_ALG, val=SHA2_256. <----- The incoming proposal is using SHA256 as the hash/authentication. ike 0:d6d9c13fc16ecf9d/0000000000000000:304:         type=AUTH_METHOD, val=PRESHARED_KEY. ike 0:d6d9c13fc16ecf9d/0000000000000000:304:         type=OAKLEY_GROUP, val=MODP2048. . <----- The incoming proposal is MODP2048, which refers to the DH group 14. ike 0:d6d9c13fc16ecf9d/0000000000000000:304: ISAKMP SA lifetime=86400 . <----- The incoming proposal key lifetime is using 86400 seconds. ike 0:d6d9c13fc16ecf9d/0000000000000000:304: my proposal, gw ipsec: <----- The proposals our device is sending. ike 0:d6d9c13fc16ecf9d/0000000000000000:304: proposal id = 1: ike 0:d6d9c13fc16ecf9d/0000000000000000:304:   protocol id = ISAKMP: ike 0:d6d9c13fc16ecf9d/0000000000000000:304:      trans_id = KEY_IKE. ike 0:d6d9c13fc16ecf9d/0000000000000000:304:      encapsulation = IKE/none ike 0:d6d9c13fc16ecf9d/0000000000000000:304:         type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=128  . <----- The outgoing proposal is using AES128 for encryption. ike 0:d6d9c13fc16ecf9d/0000000000000000:304:         type=OAKLEY_HASH_ALG, val=SHA2_256. <----- The outgoing proposal is using SHA254 as the hash/authentication. ike 0:d6d9c13fc16ecf9d/0000000000000000:304:         type=AUTH_METHOD, val=PRESHARED_KEY. ike 0:d6d9c13fc16ecf9d/0000000000000000:304:         type=OAKLEY_GROUP, val=MODP2048. . <----- The outgoing proposal is MODP2048, which refers to DH group 14. ike 0:d6d9c13fc16ecf9d/0000000000000000:304: ISAKMP SA lifetime=86400 . <----- The outgoing proposal key life time is using 86400 seconds. ike 0:d6d9c13fc16ecf9d/0000000000000000:304: negotiation failure ike Negotiate ISAKMP SA Error: ike 0:d6d9c13fc16ecf9d/0000000000000000:304: no SA proposal chosen A mismatch that was found in Phase 1: The mismatch in phase 1 was the AES Encryption method. After changing the outgoing proposal's AES encryption to 256 to match the other side, our Phase 1 is now matching. The device that is the initiator will receive the proposals for phase 2. Using diagnose vpn ike gateway list, the direction value will tell if it is the initiator or the responder. vd: root/0 name: ipsec version: 1 interface: port1 3 addr: created: 414860s ago IKE SA: created 1/5  established 1/5  time 0/1806/9030 ms IPsec SA: created 0/252212   id/spi: 556 6d36bdb41afc24f9/ed984187bc723580   direction: initiator   status: established 70451-70451s ago = 0ms   proposal: aes256-sha256   key: 6d9ed8f776f63ca2-204b5254e582e3f9-0f4931ce967c9943-14d16c26e8ba753c   lifetime/rekey: 86400/15648   DPD sent/recv: 00000000/00000000 Using the ike debugs, it is possible tp review the proposals for phase 2 on the initiator’s side: diagnose debug application ike -1 diagnose debug enable ike 0:ipsec:556:504137: peer proposal is: peer:0:0.0.0.0-255.255.255.255:0, me:0:0.0.0.0-255.255.255.255:0 ike 0:ipsec:556:ipsec:504137: trying ike 0:ipsec:556:ipsec:504137: matched phase2 ike 0:ipsec:556:ipsec:504137: autokey ike 0:ipsec:556:ipsec:504137: my proposal: <----- The proposals our device is sending. ike 0:ipsec:556:ipsec:504137: proposal id = 1: ike 0:ipsec:556:ipsec:504137:   protocol id = IPSEC_ESP: ike 0:ipsec:556:ipsec:504137:   PFS DH group = 20 . <----- The outgoing proposal for the DH group is 20. ike 0:ipsec:556:ipsec:504137:      trans_id = ESP_AES_CBC (key_len = 256) <----- The outgoing proposal for our Encryption is using AES256. ike 0:ipsec:556:ipsec:504137:      encapsulation = ENCAPSULATION_MODE_TUNNEL ike 0:ipsec:556:ipsec:504137:         type = AUTH_ALG, val=SHA2_256 <----- The outgoing proposal for our Authentication is using SHA256. ike 0:ipsec:556:ipsec:504137: incoming proposal: <----- The incoming proposal receiving. ike 0:ipsec:556:ipsec:504137: proposal id = 1: ike 0:ipsec:556:ipsec:504137:   protocol id = IPSEC_ESP: ike 0:ipsec:556:ipsec:504137:   PFS DH group = 19 <----- The incoming proposal for the DH Group 19. ike 0:ipsec:556:ipsec:504137:      trans_id = ESP_AES_CBC (key_len = 128) <----- The incoming proposal for their Encryption is AES128. ike 0:ipsec:556:ipsec:504137:      encapsulation = ENCAPSULATION_MODE_TUNNEL ike 0:ipsec:556:ipsec:504137:         type = AUTH_ALG, val=SHA2_256 ) <-----The incoming proposal for their Authentication is SHA265. ike 0:ipsec:556:ipsec:504137: negotiation failure ike Negotiate IPsec SA Error: ike 0:ipsec:556:504137: no SA proposal chosen A mismatch that was found in Phase 2: After reviewing the debugs, the mismatch occurring in phase 2 is the DH group and AES Encryption. By changing the AES encryption to 128 and the DH group to 19 to match the incoming proposal, phase 2 is now matching.