Dear All,
I had a problem with rekeying phase2 tunnels, the dhgroup numbers were different. After a vpn reset the phase2 works until the first rekey occurs. The solved by recheck the two side parameters, but what is frustrating is I can not get this exact info via debug.
with:
diagnose debug application ike -1
diagnose debug enable
I can get only this info:
ike 0:ahvpn:ahvpn: IPsec SA connect 17 x.x.x.x->y.y.y.y
ike 0:ahvpn:ahvpn: using existing connection
ike 0:ahvpn:ahvpn: config found
ike 0:ahvpn: request is on the queue
with flow debug only this:
id=20085 trace_id=2256 func=ipsec_common_output4 line=878 msg="SA is not ready yet, drop"
Is there any method that can debug a rekeying process or that can go a little deeper in debug level where the dhgroup mismatch possibly shown?
thank you
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.
Hello,
you could try the below commands
diagnose vpn ike log-filter dst-addr4 <Remote_Peer_IP>
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug enable
try to active the tunnel (phase2) from GUI and ping the remote side (bring it down then up)
to stop the debug:
diagnose debug disable
diag debug reset
you might see more information.
Hello,
you could try the below commands
diagnose vpn ike log-filter dst-addr4 <Remote_Peer_IP>
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug enable
try to active the tunnel (phase2) from GUI and ping the remote side (bring it down then up)
to stop the debug:
diagnose debug disable
diag debug reset
you might see more information.
Thank you! I tried it and it seems work, when the rekeying in progress (in case of a working tunnel)..
However there is no usefull information about dhgrp mismatch, when the tunnel is down and tried to send packet over. In that situation the only debug info is the following, which is not unhide the real problem (dhgrp mismatch):
ike 0: comes x.x.x.x:500->y.y.y.y:500,ifindex=17....
ike 0: IKEv2 exchange=INFORMATIONAL id=<..some data.> len=80
ike 0: in <..some data.>
ike 0:myvpn:7: dec <..some data.>
ike 0:myvpn:7: received informational request
ike 0:myvpn:7: enc <..some data.>
ike 0:myvpn:7: out <..some data.>
ike 0:myvpn:7: sent IKE msg (INFORMATIONAL_RESPONSE): x.x.x.x:500->y.y.y.y:500, len=80, id=...
ike 0:myvpn:myvpn: IPsec SA connect 17 x.x.x.x->y.y.y.y:0
ike 0:myvpn:myvpn: using existing connection
ike 0:myvpn:myvpn: config found
ike 0:myvpn: request is on the queue
Maybe a vpn restart is required to get a full ike handshake debug...
thank you
Hi,
Yes, you have to flush the tunnel so the renegotiation starts and you will get the full debug.
If you have no interest in the payloads you can run the debug with ike 127 and not -1 to see only the negotiation and not the payload.
Note that the dhgrp might be translated in bits in the debug so you won't actually see the number, for eg dh 14 is 2048 bit, dh 5 should be 1536. (for phase1)
thank you for your help
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 |
---|---|
1712 | |
1093 | |
752 | |
447 | |
231 |
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.