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
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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?
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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.
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
PCNSE
NSE
StrongSwan
yeah this one is clear to me ;)
It now matched proposals but refused to bring the tunnel up because there is no policy for the tunnel traffic on your FGT:
So create a policy (at least one) that affects tunnel traffic and it should come up.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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
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?
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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 ?
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.
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
PCNSE
NSE
StrongSwan
ede_pfau wrote:Hello,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.
How did you understand, that this is AES128? I see no any "128" there ? Is it AES256 in fact ?
type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=256my fault, sorry! AES256 is correct.
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]
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1531 | |
1028 | |
749 | |
443 | |
209 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.