09-30-2017 01:39 PM - edited 03-05-2019 09:13 AM
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
10-02-2017 08:34 AM
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
04-18-2019 02:55 AM
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
04-18-2019 07:28 AM
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.
04-19-2019 01:49 AM
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
04-19-2019 05:41 AM
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
04-25-2019 12:25 AM
04-25-2019 07:30 AM
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.
04-25-2019 11:18 AM
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
04-30-2019 04:43 AM
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
04-30-2019 06:24 AM
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
04-30-2019 12:08 PM
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
04-30-2019 12:20 PM
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
05-01-2019 06:39 AM
@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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide