blog
    VRF and IPSec integration ...
    12 October 09

    VRF and IPSec integration with a twist of Transparent IOS. Bob pushes the envelope, one more time...

    Posted byINE
    facebooktwitterlinkedin
    news-featured

    Bob turned up the volume on his MP3 player. It was difficult to hear his music over the whirring of the humidifiers.  He sat down in one of the small chairs in front of a computer with SecureCRT.  It was freezing in the data center, and a short sleeved Bob was hoping for a quick and working solution.   It all happened like this:

    After his huge success implementing DMVPN and GET VPN overlay, (with a lot of help from his INE Blog Buddies), Bob was on a roll.   He decided to attempt VRF and IPSec integration as his next challenge.

    Bob was especially excited when he found some configuration examples for the transparent mode IOS, (the IRB documents were next to his PC Jr and Atari manuals).  Bob was eager to learn Integrated Routing and Bridging (IRB), again, because he had a sneaking suspicion he would use this knowledge later when configuring a Transparent Zone Based Firewall.   (Transparent ZBF will be in a future blog post if you want it).

    Bob made his plan using the following diagram:

    Bob's VRF / IPSec / Transparent Diagram (or as Bob calls it, the "VITD"

    Bobs plans included R2 as a transparent mode router, using a VRF, with a Bridged Virtual Interface (BVI) on the 10.0.0.0 network.  All interfaces on R2 belonging to the VRF named vrf1.   R4 and R2 will be IPSec peers, with interesting traffic being IP between 1.1.1.1 and 4.4.4.4 bidirectionally.

    Doing the best he could with this new technology, Bob put together a proposed configuration based on examples he had seen.  The VLAN configuration on the switch was correct, and for this blog post, we will accept that the switch configuration is 100% perfect.  (I know, I know...  A real CCIE doesn't assume anything is working correctly unless he/she verifies it.   So for this task, I personally verified that all VLANs were correctly assigned, and that any trunking that may be required for inter-switch communications was also set up correctly).

    Bob pasted in the configs, and hoped for the best.  Bob discovered that he could not even PING from R2 to any other device on the network.   "Could PING be broken by VRFs?" Bob thought to himself.   He had only read about VRFs and this was his first exposure to them.

    Bob has officially sounded the call, once more, for you to help  him with his broken configuration.

    Here is what Bob pasted in:

    R1
    enable
    conf t
    hostname R1
    ip cef
    no ip domain lookup
    ip tcp synwait-time 5
    interface Loopback0
    ip address 1.1.1.1 255.255.255.0
    interface FastEthernet0/0
    ip address 10.0.0.1 255.255.255.0
    no shut
    router ospf 1
    network 10.0.0.1 0.0.0.0 area 0
    line con 0
    exec-timeout 0 0
    privilege level 15
    logging synchronous
    line aux 0
    line vty 0 4
    privilege level 15
    no login
    end
    R2
    enable
    conf t
    hostname R2
    memory-size iomem 30
    ip cef
    ip vrf vrf1
    crypto keyring vpn vrf vrf1
    pre-shared-key address 20.0.0.4 key CISCO
    crypto isakmp policy 10
    authentication pre-share
    crypto isakmp profile isa-prof
    keyring vpn
    match identity address 20.0.0.4 255.255.255.255 vrf1
    exit
    crypto ipsec transform-set AES_256_SHA esp-des esp-md5-hmac
    exit
    crypto map VPN isakmp-profile isa-prof
    crypto map VPN 10 ipsec-isakmp
    set peer 4.4.4.4
    set transform-set AES_256_SHA
    set isakmp-profile isa-prof
    match address CRYPTO-ACL
    exit
    bridge irb
    interface Loopback0
    ip vrf forwarding vrf1
    ip address 2.2.2.2 255.255.255.0
    interface FastEthernet0/0
    ip vrf forwarding vrf1
    no shut
    interface FastEthernet0/1
    ip vrf forwarding vrf1
    no ip address
    no shut
    !
    interface BVI1
    ip vrf forwarding vrf1
    ip address 10.0.0.2 255.255.255.0
    crypto map VPN
    !
    router ospf 1 vrf vrf1
    log-adjacency-changes
    network 2.2.2.2 0.0.0.0 area 0
    network 10.0.0.2 0.0.0.0 area 0
    ip access-list extended CRYPTO-ACL
    permit ip host 1.1.1.1 host 4.4.4.4
    exit
    bridge 1 protocol ieee
    bridge 1 route ip
    !
    line con 0
    exec-timeout 0 0
    privilege level 15
    logging synchronous
    end
    R3
    enable
    conf t
    hostname R3
    ip cef
    no ip domain lookup
    interface Loopback0
    ip address 3.3.3.3 255.255.255.0
    !
    interface FastEthernet0/0
    ip address 10.0.0.3 255.255.0.0
    no shut
    !
    interface FastEthernet0/1
    ip address 20.0.0.3 255.255.0.0
    no shut
    !
    router ospf 1
    network 3.3.3.3 0.0.0.0 area 0
    network 10.0.0.3 0.0.0.0 area 0
    network 20.0.0.3 0.0.0.0 area 0
    line con 0
    exec-timeout 0 0
    privilege level 15
    logging synchronous
    line aux 0
    end
    R4
    enable
    conf t
    hostname R4
    ip cef
    no ip domain lookup
    crypto keyring vpn
    pre-shared-key address 10.0.0.2 key cisco
    !
    crypto isakmp policy 10
    authentication pre-share
    crypto isakmp profile isa-prof
    keyring vpn
    match identity address 10.0.0.2 255.255.255.255
    exit
    !
    crypto ipsec transform-set AES_256_SHA esp-des esp-md5-hmac
    exit
    !
    crypto map VPN isakmp-profile isa-prof
    crypto map VPN 10 ipsec-isakmp
    set peer 10.0.0.2
    set transform-set AES_256_SHA
    set isakmp-profile isa-prof
    match address CRYPTO-ACL
    exit
    interface Loopback0
    ip address 4.4.4.4 255.255.255.0
    !
    interface FastEthernet0/1
    ip address 20.0.0.4 255.255.255.0
    no shut
    crypto map VPN
    !
    !
    router ospf 1
    log-adjacency-changes
    network 4.4.4.4 0.0.0.0 area 0
    network 20.0.0.4 0.0.0.0 area 0
    exit
    IP access-list extended CRYPTO-ACL
    permit icmp host 4.4.4.4 host 1.1.1.1
    exit
    line con 0
    exec-timeout 0 0
    privilege level 15
    logging synchronous
    end

    There is more than one possible solution.    Using the framework of what is provided, including the diagram, there are nine (9), corrections that are required for this configuration to work.   The goal is to have an IPSec tunnel, between R2 BVI1 and R4 20.0.0.4   A ping sourced from 1.1.1.1 destined to 4.4.4.4 should be encrypted over the tunnel.

    Will you help Bob?    Comment on the issues you see.

    By the end of the week, I will post a full working configuration, based on your input here.   You may then take the full configuration and put in on live gear,  GNS3, or in your sweet library of .txt files that you are assembling.  (PS if you do not have a central location for assembling your notes, config ideas, etc. now would be a great time to start).

    A special "thank you" goes out to Barooq for recommending this topic as a blog post.   To all, please let me know what topics you would like to see in the Blog posts here at INE!

    Thanks.

    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo