Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
marypoppins
New Contributor II

Ipsec rekey debug

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

1 Solution
ezhupa
Staff
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. 

View solution in original post

4 REPLIES 4
ezhupa
Staff
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. 

marypoppins
New Contributor II

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

ezhupa
Staff
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)

marypoppins
New Contributor II

thank you for your help

Labels
Top Kudoed Authors