Saturday, September 19, 2009

IPSEC with VTI: The best damn way to do it.

Back when I was finally sick of working for ISP's and wanted to make the switch to enterprise, I had the normal "I am ISP background working in enterprise" worries (more of these and tips for those making the switch in a future article) but one particular technology had always stumped me.

IPSEC

Few other technologies require you to configure so many damn things to get them going! The steps you had to remember, ISAKMP policies, transform sets, crypto maps, interesting traffic ACL's, nat-traversal, the list could just go on and on and the debugging was just horrific!

Luckily I got my head around IPSEC to the point where of all the topics on the CCIE security IPSEC is the one I feel most confident with.

BUT my dear reader, I want you to be able to _AVOID_ the problems with IPSEC completely! Let me show you: VTI Tunnels


Virtual Tunnel Interface is a Cisco technology that basically allows you to have IPSEC tunnels, I am not talking about the pseudo IPSEC tunnels that are encapsulated inside GRE or GRE tunnels encapsulated inside IPSEC.

What we have with VTI is a pure Virtual tunnel, no GRE MTU issues to worry about and no real drawbacks that I have been able to see so far (if you know of any drawbacks id love to hear from you please comment in the section below.)

So, without any further rantings lets get onto some configuration:


First of all, you must configure your ISAKMP policies as normal (Hey, I didn't say it got rid of ALL the steps :p)

crypto isakmp policy 100
encr 1des
authentication pre-share
group 1
!


Obviously you need to make sure this matches on both your routers!

Go ahead and configure the transform sets:


crypto ipsec transform-set STRONGSET esp-3des esp-md5-hmac


Now here is a new step you probably have not seen before (except those of you who have configured GRE tunnels with IPSEC protection.. you know who you are!)


crypto ipsec profile VTI
set transform-set STRONGSET
!



Okay, so we have our transform set, our crypto isakmp policy and something that you may not have run across yet called a "profile."

Lets configure our tunnel, you perform this just like you would a normal GRE tunnel but with a few important differences:

interface Tunnel0
ip address 192.168.10.2 255.255.255.0
tunnel source 203.56.14.17
tunnel destination 61.88.88.88
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI


The two lines that should look different to you are "tunnel mode ipsec ipv4"
and "tunnel protection ipsec profile VTI"

These enable the VTI tunnel for IPSEC (obviously) and define the transform set to use,

We just have one more step now, earlier when I configured my ISAKMP policy I missed out a crucial stage that some of you may have picked up on (Hint: What authentication method am I using?)

Thats right, Pre-share, which means i need a pre-shared KEY! Now the reason i missed out on this was because a question i had when i first looked at this was what should i specify as the peer address? Well the answer is easy, you specify the peer address as the actual destination of the tunnel, so in our example our peer key looks like this:

crypto isakmp key CcI3R4ntsIs4Gr43tBl0g address 61.88.88.88




Assuming you have obviously mirrored the configuration on the other side guess what... that's it!! No Crypto-maps to worry about, interesting ACL's to define, no-nat statements to write, the next step is to bring up the tunnel by pinging the other end of the tunnel (so in our case 192.168.10.1) which should bring up the tunnel, you can verify using your regular crypto commands (show crypto isakmp sa and show crypto ipsec sa respectively.)

You can now route traffic over this interface just like a regular tunnel, you can even use a dynamic routing protocol!

Enjoy!

7 comments:

  1. Nice post. I have had an issue with running EIGRP over the IPEC VTI. The IPSEC tunnel was flapping which was causing the EIGRP to flap as well. I noticed that the 'shared' keyword was used at the end ot the "tunnel protect ipsec profile VTI shared". I removed the shared keyword and everything stabalized.

    Now cisco says that the shared keyword is not required when the tunnel mode is configured to IPSEC, so my question here is what does the shared keyword do and when is this applicable? Any leads or hints would be highly appreciated. Thanks in advance

    ReplyDelete
  2. would be good for cisco to have virtual-template aggregated as interface sdvti X

    :)

    Nice post!

    Thank you

    ReplyDelete
  3. This works perfectly! But how do you get it through NAT using Tunnel mode? It'll work fine in transport mode.

    ReplyDelete
  4. I figured it out, you have to add "tunnel mode ipsec ipv4" to the VTI configs

    Thanks

    ReplyDelete
  5. VTI only support IP but GRE support multiple protocol

    ReplyDelete
  6. You may have all the accomplishments and awards that some college graduates only dream about, but the reality is you may still end up jobless in today's economy. Job hunts today are competitive and in this market only the strong-willed and determined with stand out and get hired. See more gre waiver request letter

    ReplyDelete
  7. Do you have a network topology of above ?

    ReplyDelete