Route-Based VPN between Cisco Router and Fortigate Firewall using OSPF

Earlier, I wrote an article showing how to do a VTI (Virtual Tunnel Interface) from a Cisco ASA to a Fortigate Firewall. Today, I will cover a route-based VPN with a Cisco Router instead of a Cisco ASA using VTIs.  Where as the ASA only supports BGP with its VTI implementation, the router is a bit more flexible and allows for OSPF.

Initially, this post was born from a customer that required some VPN connectivity via VTI on the ASA which later turned into a VTI on a Cisco Router.  This was great because it gave me an opportunity to write about it.  While on-site, we were testing with FortiTester and reviewing the Fortigate features.  This took up some time of course, but when we tested the router-based VTI, we ran out of time.  I asked the customer if I could work on the config and get back to him, they were gracious enough to allow me to do so; Thank You Mr. Customer.  Here is what I did.

My Configuration

Below, we can see that I have one interface that is acting as the Internet (192.168.200.0/30) and a tunnel interface tied to both WAN ports (obviously using different methods; Cisco and Fortinet respectively). The plan is to establish an encrypted channel using the 192.168.200.0/30 network, then establishing the tunnel interface between the 192.168.170.88/30 subnet and be able to use dynamic routing (OSPF).

 

Cisco Router Configuration

Using a Cisco 2921 in my lab, I configured the VPN using the config I was using on-site at the customer.  Here is the config:

 

I will break each section down below:

crypto keyring KEY_RING 
pre-shared-key address 192.168.200.2 key fortigate

This is the configuration that will allow you to define the pre-shared key with the particular remote peers.  In my case, it is the FortiGate’s IP address of 192.168.200.2 and the pre-shared key is fortigate

Next we will define the Phase I crypto profiles

crypto isakmp policy 11
encr aes 256
hash sha256
authentication pre-share
group 2

In my example above, I am telling the router that I will present and accept Phase I connections that meet the following proposal.  In my example, I require that you use AES 256 as the encryption type and SHA 256 as the hashing algorithm.  Additionally, I am expecting pre-shared key as the authentication instead of a certificate.  Lastly, I want to use DH group 2 (Diffie Helman).

Next we will configure the Phase II proposals

crypto ipsec transform-set ROUTER-IPSEC esp-aes 256 esp-sha512-hmac 
mode tunnel

Here we are expecting and will be exchanging AES 256 with a hashing of SHA 512.

Next we will configure a profile that will reference the transform-set created previously and will be assigned to a tunnel interface.

crypto ipsec profile FORTINET
set transform-set ROUTER-IPSEC

Now we will create the VTI or Virtual Tunnel Interface

interface Tunnel1
description !!! To FortiGate !!!
ip address 192.168.170.90 255.255.255.252
load-interval 30
tunnel source 192.168.200.1
tunnel mode ipsec ipv4
tunnel destination 192.168.200.2
tunnel protection ipsec profile FORTINET

As we can see in the config snippet above, we are calling the ipsec profile we defined in the previous step as well as the IP address 192.168.170.90/30 and we are defining where the tunnel initiates from (the tunnel source of 192.168.200.1) and the destination of the tunnel (192.168.200.2).

Finally, we will configure a few test connection items such as loopback interfaces and OSPF.

interface Loopback1
ip address 5.5.5.5 255.255.255.255

This is a simple loopback interface that I will use to advertise over the VPN.

router ospf 1
redistribute connected subnets
network 192.168.170.88 0.0.0.3 area 0

Above we can see a basic OSPF configuration

Fortigate Configuration

Things are much easier on this side of the house IMHO.

Here we are defining the IP address of the remote peer (Cisco Router) and we are telling the VPN that we are NOT using NAT Traversal.  If you are not familiar with NAT T, here is a blog site that discusses it.

Next we have our Phase I proposal.  This is equivalent to the crypto isakmp policy 11 from the Cisco Configuration portion.  Additionally, we are defining what DH groups I want to use as well as the Key Lifetime.  Even if the Key Lifetime do not match, the tunnel WILL come up, you will just have strange re-keying issues throughout the tunnel’s lifetime.

Then we have our Phase II configuration.  Here we are defining the Phase II proposal.  As you can see, I have multiple proposals one of which matches ROUTER-IPSEC transform-set from the Cisco Configuration portion.

BEWARE OF PFS:  I tend to use it. But a majority of Phase II issues I run into, is because either the proposals do not match or PFS is either enabled or disabled when it should or should not be.

When you have finished creating the VPN, the Fortigate will automatically create a tunnel interface for you, however it will have 0.0.0.0/0 assigned to it.  We will need to modify the IP address.  In our case, we used the 192.168.170.88/30 network.  This directly ties into the Cisco interface Tunnel1 section.  We can see that much like the Cisco config, we are defining the remote IP of the tunnel.

We will create some policies that permit or deny traffic as needed.

Since I am using Central NAT, I will create an entry telling the Fortigate NOT to NAT traffic over the VPN tunnel interface.

As you can see, the NAT is disabled.

Now for my OSPF configuration

Results

Her we can see the routes learned via OSPF from the Cisco side

And here we can see the routes learned via OSPF from the Fortigate side.

Side Note

When I was on-site and I was troubleshooting the problem, I did not see the error I was having, however when I got home and decided to reconfigure the Cisco side piece-by-piece, I noticed that I was missing a line on the tunnel interface configuration.

Here is the debug I was seeing

SecPrimate-02 # ike 0: comes 192.168.200.1:500->192.168.200.2:500,ifindex=8....
ike 0: IKEv1 exchange=Quick id=a991d2b5389a2b44/68405b5aebda269a:93badca4 len=188
ike 0: in A991D2B5389A2B4468405B5AEBDA269A0810200193BADCA4000000BC18AB6CB2C9C6A0072203B28A63AB8BF743A3F03CF3ECCB2FE545746114FA5F1B8B11B295179B68A2A7910B0114D309AE5DB3524624F157AA6F2A120637A4B1A6D85569B7E3FFF57951536274525BA6589825E08667BCF1DE5915BC1D89B72EA4B3562C8F4E571F80092E977A8190C43AE71BE56AD1E31934F4294A35F5F410202BC00702EC6E5AD76F804D345BD12EC544F351FD7D790523814D892570BC1FEA
ike 0:VPN-CISCO-RTR:1743:13896: responder received first quick-mode message
ike 0:VPN-CISCO-RTR:1743: dec A991D2B5389A2B4468405B5AEBDA269A0810200193BADCA4000000BC0100002490B66083747BAC343F43818F1775E94BCC00FDC395D8A2C9B2BA205C986EE3150A000040000000010000000100000034010304018F9D8BA600000028010C0000800400018001000180020E10800100020002000400465000800500028006010005000018118D3EF7C54A7F74C4D51D011170F1D9FE66E19D0500000C012F0000C0A8C8010000000C012F0000C0A8C802000000000000000000000000
ike 0:VPN-CISCO-RTR:1743:13896: peer proposal is: peer:47:192.168.200.1-192.168.200.1:0, me:47:192.168.200.2-192.168.200.2:0
ike 0:VPN-CISCO-RTR:1743:VPN-CISCO-RTR:13896: trying
ike 0:VPN-CISCO-RTR:1743:13896: specified selectors mismatch
ike 0:VPN-CISCO-RTR:1743:13896: peer: type=7/7, local=47:192.168.200.2-192.168.200.2:0, remote=47:192.168.200.1-192.168.200.1:0
ike 0:VPN-CISCO-RTR:1743:13896: mine: type=7/7, local=0:0.0.0.0-255.255.255.255:0, remote=0:0.0.0.0-255.255.255.255:0
ike 0:VPN-CISCO-RTR:1743:13896: no matching phase2 found
ike 0:VPN-CISCO-RTR:1743:13896: failed to get responder proposal
ike 0:VPN-CISCO-RTR:1743: error processing quick-mode message from 192.168.200.1 as responder
ike 0: comes 192.168.200.1:500->192.168.200.2:500,ifindex=8....
ike 0: IKEv1 exchange=Quick id=a991d2b5389a2b44/68405b5aebda269a:3184366b len=188
ike 0: in A991D2B5389A2B4468405B5AEBDA269A081020013184366B000000BC482FF6FDC9878BE877509A48AFC2E1E0FEBE236B50D6F2F427C884E49B1E4E7DA5B450DF3CD27B030A41EBD416260DD0A2D7059A370A2AF2FA8F887AE2C24642B76E228AF9D7BD36EE4C1F43C6087B7001F2A944EF14698CDA86E6EB5347BE355D73DB8B2C830990EB53E1F6CB5F0A6166FDDE78B5F55C0ACE422B4F0A1F0D74FF205F796D08087A1C37BDB9F24EE0FA6440D42AD924522F70A07800FF2627DF
ike 0:VPN-CISCO-RTR:1743:13897: responder received first quick-mode message
ike 0:VPN-CISCO-RTR:1743: dec A991D2B5389A2B4468405B5AEBDA269A081020013184366B000000BC01000024C401CF57724E465D9AA7250958A87C9987A2B14F4684E9DE454CF66D5D326D6E0A0000400000000100000001000000340103040141A86F7C00000028010C0000800400018001000180020E108001000200020004004650008005000280060100050000185200BDEA9C13B67924141BD7F3BDE6FCE19E94580500000C012F0000C0A8C8010000000C012F0000C0A8C802000000000000000000000000
ike 0:VPN-CISCO-RTR:1743:13897: peer proposal is: peer:47:192.168.200.1-192.168.200.1:0, me:47:192.168.200.2-192.168.200.2:0
ike 0:VPN-CISCO-RTR:1743:VPN-CISCO-RTR:13897: trying
ike 0:VPN-CISCO-RTR:1743:13897: specified selectors mismatch
ike 0:VPN-CISCO-RTR:1743:13897: peer: type=7/7, local=47:192.168.200.2-192.168.200.2:0, remote=47:192.168.200.1-192.168.200.1:0
ike 0:VPN-CISCO-RTR:1743:13897: mine: type=7/7, local=0:0.0.0.0-255.255.255.255:0, remote=0:0.0.0.0-255.255.255.255:0
ike 0:VPN-CISCO-RTR:1743:13897: no matching phase2 found
ike 0:VPN-CISCO-RTR:1743:13897: failed to get responder proposal
ike 0:VPN-CISCO-RTR:1743: error processing quick-mode message from 192.168.200.1 as responder
ike 0: comes 192.168.200.1:500->192.168.200.2:500,ifindex=8....
ike 0: IKEv1 exchange=Quick id=a991d2b5389a2b44/68405b5aebda269a:93badca4 len=188
ike 0: in A991D2B5389A2B4468405B5AEBDA269A0810200193BADCA4000000BC18AB6CB2C9C6A0072203B28A63AB8BF743A3F03CF3ECCB2FE545746114FA5F1B8B11B295179B68A2A7910B0114D309AE5DB3524624F157AA6F2A120637A4B1A6D85569B7E3FFF57951536274525BA6589825E08667BCF1DE5915BC1D89B72EA4B3562C8F4E571F80092E977A8190C43AE71BE56AD1E31934F4294A35F5F410202BC00702EC6E5AD76F804D345BD12EC544F351FD7D790523814D892570BC1FEA
ike 0:VPN-CISCO-RTR:1743:13898: responder received first quick-mode message
ike 0:VPN-CISCO-RTR:1743: dec A991D2B5389A2B4468405B5AEBDA269A0810200193BADCA4000000BC0100002490B66083747BAC343F43818F1775E94BCC00FDC395D8A2C9B2BA205C986EE3150A000040000000010000000100000034010304018F9D8BA600000028010C0000800400018001000180020E10800100020002000400465000800500028006010005000018118D3EF7C54A7F74C4D51D011170F1D9FE66E19D0500000C012F0000C0A8C8010000000C012F0000C0A8C802000000000000000000000000
ike 0:VPN-CISCO-RTR:1743:13898: peer proposal is: peer:47:192.168.200.1-192.168.200.1:0, me:47:192.168.200.2-192.168.200.2:0
ike 0:VPN-CISCO-RTR:1743:VPN-CISCO-RTR:13898: trying

I was getting Phase I up between the router and the Fortigate but then it would drop.  I tried all kinds of things, the piece I was missing on the Cisco side was:

tunnel mode ipsec ipv4

Once I added that, everything was right as rain.

Hope this helps.

IKEv2 Update

20191111 UPDATE:  Since the customer was running IKEv2 and my example was IKEv1. Here is the update for IKEv2.  I recommend IKEv2 for obvious reasons, but here you have both.

On the Cisco Router

Phase I

crypto ikev2 proposal ASS-256 
encryption aes-cbc-256
integrity sha1
group 5

Here you can see we are calling for the ikev2 proposal instead of the crypto isakmp one we had in the IKEv1 version of the config.

Keyring

crypto ikev2 keyring KEYRING
peer Fortinet
address 192.168.200.2
pre-shared-key fortigate
!

Again, here we have the specific ikev2 keyring to be used.

IPsec Profile

crypto ikev2 profile Fortinetv2
match identity remote address 192.168.200.2 255.255.255.255 
identity local address 192.168.200.1
authentication remote pre-share
authentication local pre-share
keyring local KEYRING

Once again, we are differentiating between IKEv1 and IKEv2 on the profile and calling the correct KEYRING

crypto ipsec profile Fortinetv2
set transform-set ROUTER-IPSEC 
set ikev2-profile Fortinetv2
!

Here we are calling out the same transform set we used earlier in IKEv1

Interface

interface Tunnel1
tunnel protection ipsec profile Fortinetv2
!

Finally, we need to reference the correct profile on the tunnel interface.  This will force the Tunnel1 interface to use IKEv2.

On the Fortigate

Inside the VPN configuration, under Authentication change the IKE Version from 1 to 2.

VPN Validation

lab-rtr-01#sh cry ikev2 sa 
IPv4 Crypto IKEv2 SA

Tunnel-id Local Remote fvrf/ivrf Status 
2 192.168.200.1/500 192.168.200.2/500 none/none READY 
Encr: AES-CBC, keysize: 128, PRF: SHA256, Hash: SHA256, DH Grp:2, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/179 sec

IPv6 Crypto IKEv2 SA

lab-rtr-01#sh cry ips sa

Here we can see the Phase I up or ready

interface: Tunnel1
Crypto map tag: Tunnel1-head-0, local addr 192.168.200.1

protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 192.168.200.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26
#pkts decaps: 24, #pkts decrypt: 24, #pkts verify: 24
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 192.168.200.1, remote crypto endpt.: 192.168.200.2
plaintext mtu 1422, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0
current outbound spi: 0xBD2826D(198345325)
PFS (Y/N): N, DH group: none

inbound esp sas:
spi: 0xDED1CA8F(3738290831)
transform: esp-256-aes esp-sha512-hmac ,
in use settings ={Tunnel, }
conn id: 2063, flow_id: Onboard VPN:63, sibling_flags 80000040, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4295465/3479)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xBD2826D(198345325)
transform: esp-256-aes esp-sha512-hmac ,
in use settings ={Tunnel, }
conn id: 2064, flow_id: Onboard VPN:64, sibling_flags 80000040, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4295464/3479)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)

outbound ah sas:

outbound pcp sas:
lab-rtr-01#

We can see the quad 0’s up for Phase II