Fortigate - Cisco router IKEv2 VPN - route-base

[Toshi_Esumi]

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.

[Toshi_Esumi]

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]

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]

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.

[emnoc]

I've used   IKEv2 in  various vendors platforms for many  years now. ( openswan,cisco ( ASA IOS IOS-XE  IOS_XR ),juniper,fortigate,forcepoint,pfsense,etc......)

So widely  supported I would say yes.

Widely used depends on business needs and  remote-capabilites of the peer ;) .

I saw in your  config your defining local and remote PSKs.

Here's a  IKEv2  and cisco/fgt  and juniper and cisco ASA

http://socpuppet.blogspot.com/2014/05/howto-asr-ios-xe-to-fortigate-ikev2.html

http://socpuppet.blogspot.com/2013/09/vpn-ikev2-juniper-to-fortigate-routevpn.html

http://socpuppet.blogspot.com/2012/10/cisco-asa-ikev2-setup.html

[Toshi_Esumi]

At your IOS-XE config, you're using crypto-map, which is policy-based IPSec. We verified if we configured cisco side with crypto-map, it doesn't send any IP address requests w/ CFG_REQUEST because I don't have any interface. The problem happens when we use Tunnel0 static-VTI config on Cisco side and route traffic toward the interface.

[emnoc]

Can you post your   IOS  cfg again ?

Ken

[Toshi_Esumi]

Below is Cisco 1941 config:

crypto ikev2 proposal ikev2prop-1  encryption aes-cbc-256  integrity sha256  group 19 ! crypto ikev2 policy ikev2pol  proposal ikev2prop-1 ! crypto ikev2 keyring ikev2keyring  peer xxx-fg   address PEER-GW-IP   pre-shared-key toshi-test  ! crypto ikev2 profile ikev2prof  description xxx-fg at vdom xxxxxx  match identity remote address PEER-GW-IP 255.255.255.255  identity local address LOCAN-NAT-OUTSIDE-IP  authentication local pre-share  authentication remote pre-share  keyring local ikev2keyring  dpd 15 5 periodic  nat keepalive 180 ! crypto ipsec transform-set trans esp-aes 256 esp-sha256-hmac  mode tunnel ! crypto ipsec profile ipsecprof  set transform-set trans  set ikev2-profile ikev2prof ! interface Tunnel0  ip address TUNNEL-IF-IP 255.255.255.252  tunnel source OUTGOIN-IF-IP  tunnel mode ipsec ipv4  tunnel destination PEER-GW-IP  tunnel protection ipsec profile ipsecprof

[Toshi_Esumi · Accepted solution]

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.

[emnoc]

Good thanks for the update.

Ken