Troubleshoot pre-shared key mismatch

[qrz]

Hello.

I tried to debug non-working VPN tunnel and suspect there is PSK mismatch.

Fortigate doc says: "It is possible to identify a PSK mismatch using the following combination of CLI commands:

diag debug app ike filter name "phase1-name"

...

I got an error after this command, "command parse error before 'name'", why ? Are there any ways to do this ?

My Fortigate version is v5.6.4

[sw2090 · Accepted solution]

you have to replace phase1-name by the name of your tunnel. However this filter is still  broken in 5.6 (and it was before 5.6) and will not work even if you set it. This is very annoying if you have more vpns running.

I work around that by doing diag debug app ike -1. LEt it run for a while and then copy-paste the output into a text editor where I can search it.

[sw2090 · Accepted solution]

hm that looks more like non matching proposals in phase1 than a psk mismatch. Could you check that you have at least one pair of proposals identical on both sides?

[ede_pfau · Accepted solution]

Yes.

The incoming proposal is AES128/SHA256 with PFS group 5.

Usually (best practice) you would only configure one proposal on each side. Check NATT and DPD as well.

[emnoc · Accepted solution]

Agreed

PSK mis-match is not the issue and diag debug app ike -1 is your friend. Set a filter if you have tons or IKE gateways.

e.g 

   diag vpn ike  filter name <insert phase1 name> I'm doing that at this exact moment and with a FGT with 300 vpns ;) Ken Felix

[sw2090 · Accepted solution]

you have to replace phase1-name by the name of your tunnel. However this filter is still  broken in 5.6 (and it was before 5.6) and will not work even if you set it. This is very annoying if you have more vpns running.

I work around that by doing diag debug app ike -1. LEt it run for a while and then copy-paste the output into a text editor where I can search it.

[qrz]

Hello. Here is output I got, where it must be that PSK mismatch ?

responder: main mode get 1st message... ike 0:ad2b8a0d6ffa1154/0000000000000000:101588: VID RFC 3947 4A131C81070358455C5728F20E95452F ike 0:ad2b8a0d6ffa1154/0000000000000000:101588: VID draft-ietf-ipsec-nat-t-ike-03 ike 0:ad2b8a0d6ffa1154/0000000000000000:101588: VID draft-ietf-ipsec-nat-t-ike-02 ike 0:ad2b8a0d6ffa1154/0000000000000000:101588: VID draft-ietf-ipsec-nat-t-ike-02\n ike 0:ad2b8a0d6ffa1154/0000000000000000:101588: VID draft-ietf-ipsec-nat-t-ike-01 ike 0:ad2b8a0d6ffa1154/0000000000000000:101588: VID draft-ietf-ipsec-nat-t-ike-00 ike 0:ad2b8a0d6ffa1154/0000000000000000:101588: VID DPD AFCAD71368A1F1C96B8696FC77570100 ike 0:ad2b8a0d6ffa1154/0000000000000000:101588: VID FRAGMENTATION ike 0:ad2b8a0d6ffa1154/0000000000000000:101588: VID FRAGMENTATION ike 0:ad2b8a0d6ffa1154/0000000000000000:101588: VID FORTIGATE 8299031757A36082C6A621DE00000000 ike 0:ad2b8a0d6ffa1154/0000000000000000:101588: incoming proposal: ike 0:ad2b8a0d6ffa1154/0000000000000000:101588: proposal id = 0: ike 0:ad2b8a0d6ffa1154/0000000000000000:101588:   protocol id = ISAKMP: ike 0:ad2b8a0d6ffa1154/0000000000000000:101588:      trans_id = KEY_IKE. ike 0:ad2b8a0d6ffa1154/0000000000000000:101588:      encapsulation = IKE/none ike 0:ad2b8a0d6ffa1154/0000000000000000:101588:         type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=256 ike 0:ad2b8a0d6ffa1154/0000000000000000:101588:         type=OAKLEY_HASH_ALG, val=SHA2_256. ike 0:ad2b8a0d6ffa1154/0000000000000000:101588:         type=AUTH_METHOD, val=PRESHARED_KEY. ike 0:ad2b8a0d6ffa1154/0000000000000000:101588:         type=OAKLEY_GROUP, val=MODP1536. ike 0:ad2b8a0d6ffa1154/0000000000000000:101588: ISAKMP SA lifetime=28800 ike 0:ad2b8a0d6ffa1154/0000000000000000:101588: negotiation failure ike Negotiate ISAKMP SA Error: ike 0:ad2b8a0d6ffa1154/0000000000000000:101588: no SA proposal chosen

[sw2090 · Accepted solution]

hm that looks more like non matching proposals in phase1 than a psk mismatch. Could you check that you have at least one pair of proposals identical on both sides?

[qrz]

I checked and it seems Phase1 proposals are the same. If I change PSK on my side to something gibberish, there is still the same error "no SA proposal chosen". So, is it meaning, that proposals are wrong ?

[ede_pfau · Accepted solution]

Yes.

The incoming proposal is AES128/SHA256 with PFS group 5.

Usually (best practice) you would only configure one proposal on each side. Check NATT and DPD as well.

[emnoc · Accepted solution]

Agreed

PSK mis-match is not the issue and diag debug app ike -1 is your friend. Set a filter if you have tons or IKE gateways.

e.g 

   diag vpn ike  filter name <insert phase1 name> I'm doing that at this exact moment and with a FGT with 300 vpns ;) Ken Felix

[qrz]

ede_pfau wrote:

The incoming proposal is AES128/SHA256 with PFS group 5.

Usually (best practice) you would only configure one proposal on each side. Check NATT and DPD as well.

Hello,

How did you understand, that this is AES128? I see no any "128" there ? Is it AES256 in fact ?

[ede_pfau]

type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=256

my fault, sorry! AES256 is correct.

[qrz]

Well, I'm still stuck with this problem. I asked other side to change proposals to AES256/SHA1, now got slightly another error:

ike 0:73e4a87e733dbe4e/0000000000000000:127279: responder received SA_INIT msg ike 0:73e4a87e733dbe4e/0000000000000000:127279: received notify type NAT_DETECTION_SOURCE_IP ike 0:73e4a87e733dbe4e/0000000000000000:127279: received notify type NAT_DETECTION_DESTINATION_IP ike 0:73e4a87e733dbe4e/0000000000000000:127279: received notify type FRAGMENTATION_SUPPORTED ike 0:73e4a87e733dbe4e/0000000000000000:127279: incoming proposal: ike 0:73e4a87e733dbe4e/0000000000000000:127279: proposal id = 1: ike 0:73e4a87e733dbe4e/0000000000000000:127279:   protocol = IKEv2: ike 0:73e4a87e733dbe4e/0000000000000000:127279:      encapsulation = IKEv2/none ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=ENCR, val=AES_CBC (key_len = 128) ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128 ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=PRF, val=PRF_HMAC_SHA2_256 ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=DH_GROUP, val=MODP1536. ike 0:73e4a87e733dbe4e/0000000000000000:127279: proposal id = 2: ike 0:73e4a87e733dbe4e/0000000000000000:127279:   protocol = IKEv2: ike 0:73e4a87e733dbe4e/0000000000000000:127279:      encapsulation = IKEv2/none ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=ENCR, val=AES_CBC (key_len = 256) ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128 ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=PRF, val=PRF_HMAC_SHA2_256 ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=DH_GROUP, val=MODP1536. ike 0:73e4a87e733dbe4e/0000000000000000:127279: proposal id = 3: ike 0:73e4a87e733dbe4e/0000000000000000:127279:   protocol = IKEv2: ike 0:73e4a87e733dbe4e/0000000000000000:127279:      encapsulation = IKEv2/none ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=ENCR, val=20 ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=PRF, val=PRF_HMAC_SHA2_256 ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=DH_GROUP, val=MODP1536. ike 0:73e4a87e733dbe4e/0000000000000000:127279: proposal id = 4: ike 0:73e4a87e733dbe4e/0000000000000000:127279:   protocol = IKEv2: ike 0:73e4a87e733dbe4e/0000000000000000:127279:      encapsulation = IKEv2/none ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=ENCR, val=20 ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=PRF, val=PRF_HMAC_SHA2_384 ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=DH_GROUP, val=MODP1536. ike 0:73e4a87e733dbe4e/0000000000000000:127279: proposal id = 5: ike 0:73e4a87e733dbe4e/0000000000000000:127279:   protocol = IKEv2: ike 0:73e4a87e733dbe4e/0000000000000000:127279:      encapsulation = IKEv2/none ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=ENCR, val=28 ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=PRF, val=PRF_HMAC_SHA2_256 ike 0:73e4a87e733dbe4e/0000000000000000:127279:         type=DH_GROUP, val=MODP1536. ike 0:mytunnel: ignoring IKEv2 request, no policy configured ike 0:73e4a87e733dbe4e/0000000000000000:127279: negotiation failure ike Negotiate SA Error: ike ike  [9703]