New Member

Solved

Ipsec rekey debug

Forum|Forum|3 years ago
October 7, 2022
4 replies
5348 views

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

FortiGate

Best answer by ezhupa

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.

E

ezhupaAnswer

Staff

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.

marypoppinsAuthor

New Member

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

E

ezhupa

Staff

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)

marypoppinsAuthor

New Member

thank you for your help

Sign up

Login with SSO

Login to the community

Login with SSO