Skip to main content
Toshi_Esumi
SuperUser
Toshi_Esumi
SuperUser
March 10, 2018
Solved

Fortigate - Cisco router IKEv2 VPN - route-base

  • March 10, 2018
  • 2 replies
  • 55307 views

Just FYI in case you might encounter this situation in the future and I didn't find any in the forum.

 

I've been testing IKEv2 IPSec VPN between FG1500D and Cisco 1941 but couldn't bring it up when 1941 was placed behind a NAT device (means Cisco is the initiator). In addition to NAT-T, the problem comes with Cisco's static-VTI/route-based IPSec (Tunnel0 interface). If I use crypto-map(policy-based) it comes up with FG's route/interface-based IPSec.

Today, I got both Cisco TAC and Fortinet TAC on a call w/ remote access to my PC then we concluded that Cisco sends out all Configuration Payload request options regardless they're relevant to the setup or not, and FG is trying to process them, like IP/DNS requests, although those are relevant only for "dial-up" vpn then drops the request because "mode-cfg" is not enabled (not needed for site-to-site static vpn). Based on the original RFC, the recipient is supposed to be returning an error reply if it's not relevant instead of drop the request.

 

In addition to crypto map solution above, another work around is to just enable mode-cfg on the FG side to reply to Cisco some info, which would be dropped by Cisco eventually because it's not expecting to receive any return values.

 

FTNT TAC said he would go back to RFCs and discuss the matter with developers. We tested only with 5.4.8 but I'm assuming 5.6.3 has the same behavior. I'll post update when he gets back to me.

    Best answer by Toshi_Esumi

    I know it's beyond this Forum but at least one person was interested in this situation. So I want to update how my pursuit ended up on Cisco side.

     

    Turned out that Cisco had thought this out much thoroughly and implemented various options how to negotiate IKEv2 with a peer. For my case, it just needed disabling Configuration Request by adding:

        no config-exchange reqest

    at the end of IKEv2 profile: ikev2prof above. It's enabled by default for both FlexVPN (dialup endpoint) and even static VTI tunnel.

    Now it works without "mode-cfg" enabled on the FG side.

     

    2 replies

    Toshi_Esumi
    SuperUser
    Toshi_EsumiAuthor
    SuperUser
    March 13, 2018

    We, me and FTNT TAC guy, concluded enabling "mode-cfg" is the only option to terminate IKEv2 IPSec VPN from Cisco router w/ static-VTI(SVTI). This would allow FortiGate to reply with "0.0.0.0" to those IP requests and the negotiation would succeed since Cisco would ignore that part. With this set up, the traffic selector is always the default one 0/0<->0/0. Then you need to take care of routing by static routes or one of routing protocols.

     

    I forwarded this case to our FTNT SE group. Also opened a new case at Cisco TAC to know why they do that at the first place. But it's beyond this forum's scope.

    emnoc
    emnoc
    New Member
    March 13, 2018

    Interesting since  IKEv2 has been  supported in  fortiOS for quite a few  years,  if not close to decade now.

     

    Is this a problem in  v5.4.x only ? Since numerous IKEv2  vpn has  been built to cisco,linux,juniper, devices or others using IKEv2.

     

    Ken

     

    Toshi_Esumi
    SuperUser
    Toshi_EsumiAuthor
    SuperUser
    March 13, 2018

    The TAC person tested 5.6 himself with his Cisco as well. I believe it's from the beginning on both Cisco and FortiGate sides for their own behaviors. I used 15.5.2 for Cisco IOS, which is relatively new. My guess is IKEv2 is not so popular in the field especially under mixed vendor environment. With my experiences, none of our customers and other service providers so far asked us to connect another vendor's routers/FWs to our FortiGate w/ IKEv2 specifically. Always IKEv1.

    sagipael
    sagipael
    New Member
    June 26, 2019

    Hi,

     

    im trying to setup IPsec tunnel with ike v2 between Fortigate to Cisco ASA.

     

    i set all the needed settings, static routes, policies etc..

    the tunnel is up in both,

    But traffic failed to back from FG to Cisco through the tunnel.

     

    the error i got:

     

    id=20085 trace_id=1265 func=print_pkt_detail line=5347 msg="vd-Global_Net received a packet(proto=1, 192.XXX.XXX.XXX:55068->10.200.YYY.YYY:2048) from MGNT. type=8, code=0, id=55068, seq=7." id=20085 trace_id=1265 func=resolve_ip_tuple_fast line=5422 msg="Find an existing session, id-22e14d58, original direction" id=20085 trace_id=1265 func=npu_handle_session44 line=1100 msg="Trying to offloading session from LAN_Interface to Tunnel_Interface, skb.npu_flag=00000400 ses.state=00010204 ses.npu_state=0x01000000" id=20085 trace_id=1265 func=ipsecdev_hard_start_xmit line=640 msg="enter IPsec interface-Tunnel_Interface" id=20085 trace_id=1265 func=esp_output4 line=694 msg="no route to 85.Z.Z.Z, drop"

     

    Any ides?

     

    Thanks

    Sagi

     

    Terms & ConditionsAccessibility statement