Skip to main content
dimago
dimago
New Member
December 9, 2013
Question

IPsec Site-to-Site problem - request is on the queue

  • December 9, 2013
  • 8 replies
  • 43751 views
hello guys, I noticed a problem with my FG VPN with a Cisco Firewall.. Tunnel was down and it did not coming UP... In the debug i caught it: ike 0:VPN:VPN P2: IPsec SA connect 5 100.100.100.100->200.200.200.200:500 ike 0:VPN:VPN P2: using existing connection ike 0:VPN:VPN P2: config found ike 0:VPN: request is on the queue In the GUI, VPN, IPsec Monitor I saw the tunnel more than 44150 second UPs (uptime) I though it very weird... I changed the Peer of the VPN, and it " refreshed" ... I changed again to the correct peer, and it came up.. With seconds started... I think FG " locked" something... This is my version: v5.0,build0252 (GA Patch 5) Anyone has any idea? Thanks!

    8 replies

    dimago
    dimagoAuthor
    New Member
    December 10, 2013
    Anyone?
    Silver
    Silver
    New Member
    December 13, 2013
    Hello Dimago, i want to setting up a site to multisites vpn with fortigate at the head office and another 2 offices with cisco firewall. can you tell me what type of vpn policy you have been using for setting the vpn. have you use policy base or route base policy. thanks
    Silver
    Silver
    New Member
    December 13, 2013
    my firmware version 5 patch 5 i only see option to configure route base policy not policy base. on the gui also i only find option to enable vpn that' s it.
    dimago
    dimagoAuthor
    New Member
    December 14, 2013
    Silver, Well, I created phase 1 and Phase 2 by default, using the left menu VPN and after Auto Key (IKE). For sure, I did not see that option you said. If you give me a print maybe I can take a look. Diego
    Silver
    Silver
    New Member
    December 15, 2013
    okay have you select interface mode while create phase 1 or what. have you configure two policy for each direction with only accept or have you create 1 policy as ipsec tunnel
    emnoc
    emnoc
    New Member
    December 16, 2013
    Do you have a route in place ? Did you do any diag debug flow diag debug app ike ? Where is your fortigate configs? Where is your cisco configs & show cmd outputs ? You can use this link for some ideals on the proper steps in a fgt lan2lan vpn t-shooting steps; http://socpuppet.blogspot.com/2013/10/site-2-site-routed-vpn-trouble-shooting.html
    sohrab
    sohrab
    New Member
    June 10, 2015

    Hello Experts,

    i have the same problem. i mean during site to site vpn on 60 D. I configured in interface mode. all steps successfully configured, i mean, first phase 1, then phase 2 , then addresses i created for local lan and remote lan then 2 policies i created , one for local and one for remote, after that when i check in ipsec moniter. tunnel is not up. when i checked in log file of vpn. it says 'ipsec phase 1 negotiate success.' you can find the out puts in attachment. and in cli when i run the command "diag debug application ike 255.

    it shows me the following out put.

    ike 0:Fuj_FCA_VPN:FCA_IPSEC_VPN_P2.: using existing connection ike 0:Fuj_FCA_VPN:FCA_IPSEC_VPN_P2.: config found ike 0:Fuj_FCA_VPN:FCA_IPSEC_VPN_P2.: IPsec SA connect 6 213.97.223.228->213.82.83.89:500 negotiating ike 0:Fuj_FCA_VPN:5446:FCA_IPSEC_VPN_P2.:5443: ISAKMP SA still negotiating, queuing quick-mode request ike 0:Fuj_FCA_VPN:FCA_IPSEC_VPN_P2.: IPsec SA connect 6 213.97.223.228->213.82.83.89:500

     

     

    I need urgent help from experts please. this is my email address. sohrab.khaliq@gmail.com

    awaiting for your kind reply.

    Johan_Witters
    Johan_Witters
    New Member
    June 11, 2015

    Hello Sohrab,

     

    is it possible to post your configuration? or at least the vpn/policy/routing sections?

    B1202
    B1202
    New Member
    August 17, 2018

    Weird bug.. I had the same issue with the same error going to an AWS VPN connection.  I re-pointed the tunnel to a bad IP, saved, then pointed it back while watching the debug.  The connection dropped, the related policies were disabled, then when I pointed the tunnel back to the correct IP it reconnected and all policies enabled.  Since then everything is working great.  This tunnel has been up for about a month before this issue.  Another interesting thing is the "monitor" didn't fail over to the other redundant tunnel.  It's almost like this tunnel was locked up but the FW didn't know it failed to bring up the secondary.

    Terms & ConditionsAccessibility statement