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
