Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Toshi_Esumi
SuperUser
SuperUser

Fortigate - Cisco router IKEv2 VPN - route-base

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.

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

 

View solution in original post

26 REPLIES 26
Toshi_Esumi

So Cisco side sees it up. How about FGT side in "get vpn ipsec tun sum"? It should show like below:

sea5601-fg1 # get vpn ipsec tun sum 'VPN_NAME' GW_IP:4500  selectors(total,up:( 1/1  rx(pkt,err): 596097  /0  tx(pkt,err): 1089563/2

Toshi_Esumi

If FGT side also shows it up, only thing I can think of is trusthosts are configured and Cisco's tunnel interface IP is not included in the trusthosts.

Also I noticed your Cisco's IOS is quite old since it doesn't show source IP in the ping option. We only tested with relatively new IOS, like 15.4, 15.7. If it's very old like 12.4 or even older, I would imagine some behaviors with IKEv2/VTI might be different or it might require different config.

ajimenez

Hi Toshi, 

 

This is the output of "get vpn ipsec tun sum":

 

CENTRAL-FG # get vpn ipsec tun sum

 

'VPNFortiGateNAT-T_0' W.X.Y.Z:4500 selectors(total,up): 1/1 rx(pkt,err): 175998/0 tx(pkt,err): 152436/0 'VPNCiscoNAT-T_0' W.X.Y.Z:64916 selectors(total,up): 1/1 rx(pkt,err): 0/0 tx(pkt,err): 7/1 'VPNCiscoNoNAT-T_01' W.X.Y.Z:0 selectors(total,up): 1/1 rx(pkt,err): 574039/0 tx(pkt,err): 479250/4 'VPNCiscoNoNAT-T_02' W.X.Y.Z:0 selectors(total,up): 1/1 rx(pkt,err): 86941/0 tx(pkt,err): 99429/0 'VPNCiscoNoNAT-T_03' W.X.Y.Z:0 selectors(total,up): 1/1 rx(pkt,err): 160555/0 tx(pkt,err): 171331/2 'VPNCiscoNoNAT-T_04' W.X.Y.Z:0 selectors(total,up): 1/1 rx(pkt,err): 112830/0 tx(pkt,err): 108451/0 'VPNCiscoNoNAT-T_05' W.X.Y.Z:0 selectors(total,up): 1/1 rx(pkt,err): 178400/0 tx(pkt,err): 132468/2 'VPNCiscoNoNAT-T_06' W.X.Y.Z:0 selectors(total,up): 1/1 rx(pkt,err): 429732/0 tx(pkt,err): 407938/2

 

In the first row you see a VPN between the central Fortigate and a remote Fortigate behind NAT, which works perfectly. The second row is that of the Cisco behind NAT, the one about this post. And the next six lines are VPNs to Central Fortigate  from remote Ciscos, but these are not behind NAT, they also work perfect. Just as a comment, I made the same configuration in another Fortigate that makes the role of the "hub", without any VPN configuration, and it is the same behavior as in this case; this to be sure that the rest of the tunnels are causing the problem.

 

Something that catches my attention is the port in the case of the Cisco-NAT-T Tunnel, 64916, it should be 4500, right?

 

I also told you that I started the configuration with a FortiGate as the router of the remote Cisco, however to discard that Fortigate's security was preventing communication, I put a "less secure" router in front of the Cisco behind NAT, and the behavior is also the same.

 

=(

ajimenez

About trusthost, there is nothing configuration neither in the Fortigate nor in the Cisco.

 

The Cisco has the following IOS: Cisco # sh ver Cisco IOS Software, C880 Software (C880DATA-UNIVERSALK9-M), Version 15.2 (4) M5, RELEASE SOFTWARE (fc2)

 

And the Fortigate has 6.0.5

 

This is an output of extended ping in the Cisco:

 

Cisco#ping Protocol [ip]: Target IP address: 172.16.0.25 Repeat count [5]: 10 Datagram size [100]: 36 Timeout in seconds [2]: 1 Extended commands : y Source address or interface: 172.16.0.26    ###Do you refer to this option? ### Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes : Type escape sequence to abort. Sending 10, 36-byte ICMP Echos to 172.16.0.25, timeout is 1 seconds: Packet sent with a source address of 172.16.0.26

..........

 

I think the IOs is not so old, let me upgrade to newer and try, I will post the results

 

Again, thanks a lot!

 

Best regards

 

Toshi_Esumi

Ah, it's 88x, which I couldn't make it work this IKEv2 tunnel with FGT. I tested 881, 891, 1941, and 4421(IOS XE). Only 881 never worked while the rest worked fine.

You probably need to open a Cisco TAC case like I did, or if that's not possible post your question at Cisco Community. Since we were trying to get rid of all 881s in the field, I declared "881 is not supported" for this Cisco-FGT IKEv2 setup inside our org.

p_kreouzis

ajimenez wrote:

About trusthost, there is nothing configuration neither in the Fortigate nor in the Cisco.

 

The Cisco has the following IOS: Cisco # sh ver Cisco IOS Software, C880 Software (C880DATA-UNIVERSALK9-M), Version 15.2 (4) M5, RELEASE SOFTWARE (fc2)

 

And the Fortigate has 6.0.5

 

This is an output of extended ping in the Cisco:

 

Cisco#ping Protocol [ip]: Target IP address: 172.16.0.25 Repeat count [5]: 10 Datagram size [100]: 36 Timeout in seconds [2]: 1 Extended commands : y Source address or interface: 172.16.0.26    ###Do you refer to this option? ### Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes : Type escape sequence to abort. Sending 10, 36-byte ICMP Echos to 172.16.0.25, timeout is 1 seconds: Packet sent with a source address of 172.16.0.26

..........

 

I think the IOs is not so old, let me upgrade to newer and try, I will post the results

 

Again, thanks a lot!

 

Best regards

 

Hi All,

I had the exact same problem, trying to create a IKEv2 GRE Tunnel between cisco 886VA with 15.2 something IOS and Fortigate version 6.0.x

The Tunnel was UP but no traffic passing through, after many days and redbulls, I changed Integrity in Phase one or Proposal (call it whatever you like) from sha256 to sha1 and BAM everything worked!!!

 

try the following config in cisco

 

crypto ikev2 proposal AES-256  encryption aes-cbc-256  integrity sha1 <- this made the difference  group 19 20 21

change Fortigate's side accorndingly

I am more than curious if it will work or not!

BR,

Panos

sagipael
New Contributor

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

 

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors