Re: IKEv1 and IKEv2 on same Router

David Lee · ‎09-30-2017

I use to have a IKEv1 Connection between a Cisco 891F router and a Fortigate 200B. I changed that to IKEv2 configuration with no issues. I am now trying to configure an IPSEC tunnel between the Cisco 891F router and an 1841 router that can only support IKEv1. The IKEv2 remains stable, but using the same configurations from IKEv1 the tunnel never comes up. Is it not possible on the 800 series routers or am I simply missing something simple? The 1841 Router is connected to the internet with DSL and the 891F is connected with Cable modem.

I hope its something simple I overlooked. The Tunnel never has come up.

Cisco 891F IPSec Config

crypto ikev2 proposal IKEv2_Corp
encryption aes-cbc-256
integrity sha256
group 21
!
crypto ikev2 policy IKEv2_Corporate
match fvrf any
proposal IKEv2_Corp
!
!
crypto ikev2 profile Goody_Corp
match address local interface GigabitEthernet8
match identity remote address 63.96.XXX.XXX 255.255.255.255
authentication remote pre-share key 6 YRSSNSMJaYREVQWJfDBY[PgDa]]O__EfLeddNKAOhB
authentication local pre-share key 6 ^DG_i]NeOD^hGI`gfEDTHXC\QH_bKbVLSaaKadca
lifetime 28800
!
!
!
!
!
crypto isakmp policy 1
encr aes
authentication pre-share
group 14
lifetime 14400
crypto isakmp key 6 HTAa_dFND]hfg\gbadagOaFZf]`dSJ address 76.254.XXX.XXX
crypto isakmp keepalive 30 5
!
!
crypto ipsec transform-set FG200B esp-aes 256 esp-sha256-hmac
mode tunnel
crypto ipsec transform-set C1841 esp-aes esp-sha-hmac
mode tunnel
!
crypto ipsec profile Goody_Corp
set security-association replay window-size 64
set transform-set FG200B
set pfs group21
set ikev2-profile Goody_Corp
!
crypto ipsec profile ciscotest
set security-association lifetime seconds 7220
set security-association replay window-size 64
set transform-set C1841
set pfs group14
!
!
!
!
!
!
!
!
interface Tunnel5
ip address 10.200.5.2 255.255.255.252
ip mtu 1438
ip inspect VPNOUT out
tunnel source GigabitEthernet8
tunnel mode ipsec ipv4
tunnel destination 76.254.XXX.XXX
tunnel protection ipsec profile ciscotest
!
interface Tunnel161
ip address 10.1.205.2 255.255.255.252
ip access-group 110 in
ip mtu 1438
ip inspect VPNOUT out
ip ospf mtu-ignore
tunnel source GigabitEthernet8
tunnel mode ipsec ipv4
tunnel destination 63.96.XXX.XXX
tunnel bandwidth transmit 10000
tunnel bandwidth receive 20000
tunnel protection ipsec profile Goody_Corp

Cisco 1841 IPSec Config

crypto isakmp policy 1
encr aes
authentication pre-share
group 14
lifetime 14400
crypto isakmp key XXXXXXX address 24.27.XXX.XXX
crypto isakmp keepalive 30 5
!
!
crypto ipsec transform-set C891 esp-aes esp-sha-hmac
!
crypto ipsec profile Cerebellum
set security-association lifetime seconds 7220
set security-association replay window-size 64
set transform-set C891
set pfs group14
!
interface Tunnel5
description IPSec Tunnel -> Cerebellum
bandwidth 2048
ip address 10.200.5.1 255.255.255.252
ip mtu 1438
tunnel source Dialer1
tunnel destination 24.27.XXX.XXX
tunnel mode ipsec ipv4
tunnel protection ipsec profile Cerebellum

Rich Uline · ‎10-02-2017

David,

The IKE policies look identical to me (as long as the obfuscated keys are the same), so it should work. The tunnel should use whichever policy/proposal matches on both sides, so the router should be able to support both IKEv1 and IKEv2 simultaneously.

Did you take a look at the debugging info?

debug crypto ipsec
debug crypto isakmp

TheAdvisors · ‎04-18-2019

Dear David,

I am having a problem connecting Cisco 800 series 15.1 IOS with Fortigate 5.6 device using GRE tunnel and IKEv2. Is it possible to guide me since you have already achieved that?

Thank you in advance,

Panos

David Lee · ‎04-18-2019

Hi Panos,

I actually haven't connected a Fortigate and Cisco Router using a GRE tunnel. I also don't recommend using just a GRE tunnel as all the information can be picked up by anyone in between the two routers and seen. By Default, Fortigates don't offer the ability to configure a GRE tunnel in the GUI interface and must be done from the command line.

I have configured and successfully connected a Cisco router to Fortigate using an IPSEC VPn Tunnel though and can help you with that. An IKEv2 IPSEC Tunnel is quite easy to setup, secure, and you can use Static routing or Dynamic.

TheAdvisors · ‎04-19-2019

Hi David,

Thank you for your reply.

I am trying to implement what I saw in your previous post. An IPsec Tunnel between (not just GRE) a cisco 886VA router and a fortigate running version FortiOS v6.0.4 build0231 (upgraded from 5.6 yesterday).

I have used from cisco's side the config you' ve posted with slight differences, and from Fortigate's side an implementation suggested by Fortinet with no luck. Any help would be much appreciated as I am struggling with the current problem for a month now.

Initially I would like to have static routing and then change it to OSPF.

Cisco

internal LAN 192.168.1.0/24

Real ip (fake) 1.1.1.1

Tunnel 10 ip address 10.11.15.1 255.255.255.252

Fortigate

10.11.14.0/24

real ip (fake) 2.2.2.2

Tunnel Cisco10 ip address 10.11.15.2 255.255.255.252

Thank you very much for giving a hand here!!!

regards,

Panos

David Lee · ‎04-19-2019

Can you post the actual configurations, but sanitized. Its really hard to figure out what the issue might be with the limited configuration information that you posted.

David

TheAdvisors · ‎04-25-2019

Hi David,

Please find the configuration from Cisco's side. The tunnels seems to be up and the IKEv2 has established connection from both sides but no traffic is passing through the Tunnel Interface. I have checked both Cisco and Fortigates Static routes and everything seems to be OK.

Version Cisco IOS Software, C880 Software (C880DATA-UNIVERSALK9-M), Version 15.1(4)M5, RELEASE SOFTWARE (fc1)

crypto pki token default removal timeout 0

crypto ikev2 proposal IKEv2_GHProposal
encryption aes-cbc-128
integrity sha1
group 19

crypto ikev2 policy IKEv2_GHPolicy
match fvrf any
proposal IKEv2_GHProposal

crypto ikev2 keyring ikev2keyring
peer GHCloudPeer
address 2.2.2.2
pre-shared-key MypresharedKey
!
crypto ikev2 profile GH_Cloud
match address local interface Dialer0
match identity remote address 2.2.2.2 255.255.255.255
authentication local pre-share
authentication remote pre-share
keyring ikev2keyring

crypto ipsec transform-set TS-GHCloud esp-aes esp-sha-hmac
crypto ipsec profile GH_Cloud
set security-association replay window-size 64
set transform-set TS-GHCloud
set pfs group19
set ikev2-profile GH_Cloud

interface Tunnel10
description *** IPSec GRE Tunnel to GHCloud ***
ip address 10.11.15.1 255.255.255.252
ip mtu 1438
tunnel source Dialer0
tunnel mode ipsec ipv4
tunnel destination 2.2.2.2
tunnel protection ipsec profile GH_Cloud

****Debuging****
jmkxh#sh crypto ikev2 stats
--------------------------------------------------------------------------------
Crypto IKEv2 SA Statistics
--------------------------------------------------------------------------------
System Resource Limit: 0 Max IKEv2 SAs: 0 Max in nego: 1000
Total IKEv2 SA Count: 1 active: 1 negotiating: 0
Incoming IKEv2 Requests: 19473 accepted: 19473 rejected: 0
Outgoing IKEv2 Requests: 2932 accepted: 2932 rejected: 0
Rejected IKEv2 Requests: 0 rsrc low: 0 SA limit: 0
IKEv2 packets dropped at dispatch: 0
Incoming IKEV2 Cookie Challenged Requests: 0
accepted: 0 rejected: 0 rejected no cookie: 0

jmkxh#sh crypto ikev2 session
IPv4 Crypto IKEv2 Session

Session-id:1, Status:UP-ACTIVE, IKE count:1, CHILD count:4

Tunnel-id Local Remote fvrf/ivrf Status
2 1.1.1.1/500 2.2.2.2/500 none/none READY
Encr: AES-CBC, keysize: 128, Hash: SHA96, DH Grp:19, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/66923 sec
Child sa: local selector 1.1.1.1/0 - 1.1.1.1/65535
remote selector 2.2.2.2/0 - 2.2.2.2/65535
ESP spi in/out: 0x7EA10520/0x62DBCC69
Child sa: local selector 1.1.1.1/0 - 1.1.1.1/65535
remote selector 2.2.2.2/0 - 2.2.2.2/65535
ESP spi in/out: 0x8B717D63/0x62DBCC68
Child sa: local selector 1.1.1.1/0 - 1.1.1.1/65535
remote selector 2.2.2.2/0 - 2.2.2.2/65535
ESP spi in/out: 0x99EDB654/0x62DBCC67
Child sa: local selector 1.1.1.1/0 - 1.1.1.1/65535
remote selector 2.2.2.2/0 - 2.2.2.2/65535
ESP spi in/out: 0xFE5BF7C2/0x62DBCC66

Any thoughts??

David Lee · ‎04-25-2019

For your transform set, change the mode to tunnel.

crypto ipsec transform-set FG200B esp-aes 256 esp-sha256-hmac
mode tunnel

On your dialer0 interface, do you have an inbound access list? If so, you need to also make sure to allow esp inbound from the source IP address or there will be no return traffic.

permit udp host 2.2.2.2 any eq isakmp
permit esp host 2.2.2.2 any

For the Tunnel, there is normally only one Child-SA for each tunnel. I'm not sure why there are 4 for yours. It could be that its not set for tunnel mode.

Richard Burts · ‎04-25-2019

If I am understanding the discussion correctly it sounds like the ISAKMP negotiation was successful, the tunnel seem to be up but is not passing any traffic. In that case it would be helpful to see the output of show crypto ipsec sa.

I have a couple of questions:

- can you verify that there is routing logic that will send traffic to the remote peer LAN through the VTI tunnel?

- is the router doing any address translation? If so can you verify that the traffic for the VTI tunnel is exempted from translation?

- if the router is not doing address translation is it possible that some other upstream device is doing address translation? If so is it possible impacting the VTI traffic?

HTH

Rick

HTH

Rick

TheAdvisors · ‎04-30-2019

Hi Richard,

I am trying to ping the ip address of the other side of the Tunnel, so I suppose no ip route is needed.

I have also trid to ping the LAN behind the other side with no luck.

I have no ip nat outside under the Tunnel10 interface

I have the following ip routes in my Cisco router

ip route 0.0.0.0 0.0.0.0 Dialer0
ip route 10.11.14.0 255.255.255.0 Tunnel10

I have the follwing

interface Tunnel10
ip address 10.11.15.1 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Dialer0
tunnel mode ipsec ipv4
tunnel destination 2.2.2.2
tunnel protection ipsec profile GH_Cloud

interface Vlan1
description INSIDE LAN
ip address 192.168.104.254 255.255.255.0
ip nat inside
ip virtual-reassembly in

interface Dialer0
description VDSL Internet Dial-Up Connection
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip virtual-reassembly in
encapsulation ppp
ip tcp adjust-mss 1452
dialer pool 1
dialer idle-timeout 0
dialer persistent
dialer-group 1
ppp authentication chap callin
ppp chap hostname NONE
ppp chap password NONE
ppp ipcp dns request
ppp ipcp mask request
no cdp enable
crypto map GH_VPN - I am also having another ipsec with a cisco router that works perfectly

ip nat inside source list 108 No_Nat interface Dialer0 overload

access-list 108 remark --- Internet Traffic ---
access-list 108 deny ip 192.168.104.0 0.0.0.255 172.27.22.0 0.0.0.255
access-list 108 deny ip 192.168.104.0 0.0.0.255 172.27.0.0 0.0.255.255
access-list 108 deny ip 192.168.104.0 0.0.0.255 171.17.0.0 0.0.255.255
access-list 108 deny ip 192.168.104.0 0.0.0.255 10.22.199.0 0.0.0.255
access-list 108 permit ip 192.168.104.0 0.0.0.255 any

thank you in advance

Panos

Richard Burts · ‎04-30-2019

Panos

Thank you for the additional information. If you are attempting to ping 10.11.15.2 then you are correct that no route statement is required. There might be several things to address but the first and most important has to do with address translation. I expected to see something like this in your config

access-list 108 deny ip 192.168.104.0 0.0.0.255 10.11.14.0 0.0.0.255

Without something like that statement then traffic going out the dialer would be translated. Please add this to your config (and make sure that it is placed before this line

access-list 108 permit ip 192.168.104.0 0.0.0.255 any

Make that change and let us know if the behavior changes.

HTH

Rick

HTH

Rick

David Lee · ‎04-30-2019

Hi Richard,

For this VPN he is not using a Crypto Map, he is using a tunnel interface so he shouldn't have to deny that specifically since the traffic will be going through the non-NAT interface of Tunnel10.

Here is my tunnel setup, and as you can see I have no deny clause in my NAT rule and it all works. Traffic to the internet is NAT'd and traffic over the VPN is not. Perhaps because I am not using Crypto-maps and using strictly tunnel to tunnel interfaces?

interface Tunnel161
description IPSec VPN Corp
bandwidth 50000
ip address 10.1.205.2 255.255.255.252
ip access-group 110 in
ip mtu 1438
ip inspect VPNOUT out
ip ospf mtu-ignore
keepalive 10 3
tunnel source GigabitEthernet8
tunnel mode ipsec ipv4
tunnel destination 1.1.1.1
tunnel protection ipsec profile Corp

!
interface GigabitEthernet8
description TWC Connection
ip address dhcp
ip access-group WAN_IN in
ip nat outside
ip inspect OUT out
ip virtual-reassembly in
duplex auto
speed auto
no cdp enable

!

ip nat inside source list 10 interface GigabitEthernet8 overload

!

access-list 10 permit 192.168.205.0 0.0.0.255
access-list 10 permit 172.17.205.0 0.0.0.255
access-list 10 permit 172.18.205.0 0.0.0.3

David Lee · ‎04-30-2019

Hi panos,

In your last update you have a mismatch in the static routes and the interface on the Tunnel. is that intended?

Also, you have to have an incoming and outgoing rule on the Fortigate for it to work properly.

A weird glitch that I have seen sometimes with Cisco and static routes over IPSec, is that sometimes if the tunnel goes down or the router is rebooted that the static tunnels will not automatically populate in the routing table. They have to be taken out, then put back in. That was the main reason I switched my configuration from static routing to OSPF. Since you are running 15.1, I thought I might mention it as that was the main version I was on when I saw it.

ip route 0.0.0.0 0.0.0.0 Dialer0
ip route 10.11.14.0 255.255.255.0 Tunnel10

I have the follwing

interface Tunnel10
ip address 10.11.15.1 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Dialer0
tunnel mode ipsec ipv4
tunnel destination 2.2.2.2
tunnel protection ipsec profile GH_Cloud

Richard Burts · ‎05-01-2019

@David Lee The route statement is not a mismatch. 10.11.14.0 is the subnet of the remote LAN reached through the tunnel. So the static route is correct. 10.11.15 is the tunnel addressing and 10.11.14 is the remote LAN addressing.

Thanks for your insight about whether there is need to exempt the tunnel traffic from address translation. The symptom here is that the tunnel seems to come up but that no traffic passes through the tunnel. I have experienced this symptom many times and frequently the cause of the problem is that the vpn traffic was being translated. So I made my suggestion about adding the statement to exempt the vpn traffic from translation. After posting my suggestion I thought about it some more and wondered if translation was really the cause of the issue. Your example of a working config that does not specifically exempt the vpn traffic shows that my suggestion is not necessary. I accept your suggestion that the original poster does not need my suggested change in address translation.

HTH

Rick

HTH

Rick