Topic Thread

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

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

     
    Posted 11-20-2019 01:10

    By Manny Fernandez

    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).

     

    Diagram2.jpg

    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:

     

    full config 2.png

    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.

    2019-11-10_07-00-08.png

    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.

    2019-11-10_07-00-29.png

    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.

    2019-11-10_07-00-48.png

    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.

    2019-11-10_07-01-51.png

    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.

    2019-11-10_07-02-36.png

    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.

    2019-11-10_07-02-58.png

    As you can see, the NAT is disabled.

    2019-11-10_07-03-31.png

    Now for my OSPF configuration

    Results

    2019-11-10_07-03-55.png

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

    2019-11-10_06-58-38.png

    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

    ikev2.png

    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