Hello everybody!

First: Thanks for you great blog scretch, it took me a while to find this awsome website, but now I will check the news and articles every day. :)

I'm writing on a student research project in my university. The topic is (in short): "VPNs with IPsec".

My primary resource is "IPsec Virtual Private Network Fundamentals" (2006) from ciscopress.com and "CCNA Security Lab Manual" (2009).

Until your blog entry (http://www.packetlife.net/blog/2008/jul/14/ipsec-quick-and-dirty/) I never read something about this VTI implementation.

You wrote that the crypto map method is "old" in your article but the CCNA Security book is brand-new, they used the crypto map method in an Site-to-Site VPN implementation.

So I have a few question to you, scretch or to anyone who could really answer my questions.

Why is it old? What is better with the virtual tunnel interface, what are the differences? Do I have to "own" the virtual tunnel ip addresses if I build a tunnel over the internet (I think I have to, but I'm not sure)?

I hope to get some answers here.

Thank you! :)

the VTIs are more flexible, enabling interface configurable configurations such as qos, zone based policy firewall configurations and yes multicast and more flexible routing permitting static routes and/or routing protocols to run over it.

and taking your question literally you can configure VTIs vs crypto maps. but that would take a crypto map with an access-list with a single permit any any statement. since vtis are basicly crypto maps permitting any traffic, basing the decision of which packets to encapsulate encrypt and route on static routing or dynamic routing with routing protocols, since the VTIs support multicast traffic as of IOS version 12.4T something and ofc the newer 15.0.

an example of a pure IPSEC VTI would be:

interface Tunnel2
 description OES GRE Tunnel
 ip address 10.89.0.1 255.255.255.254
 zone-member security oes
 tunnel source Dialer1
 tunnel mode ipsec ipv4
 tunnel destination 194.144.244.202
 tunnel protection ipsec profile VTIs
 !
end

this would need a crypto ipsec profile statement and crypto isakmp policy, if the crypto isakmp policy is using pre-shared keys as authentication you ofc need a crypto isakmp key statement as well.

crypto ipsec profile VTIs
 set transform-set aes-sha1 

with an accompanying

crypto ipsec transform-set aes-sha1 esp-aes esp-sha-hmac 

statement should complete the pure ipsec vti configuration.

an excellent article on the various VPN configurations is available from nil data communications in a 6 part series here:
http://www.nil.com/ipcorner/IPsecVPN/
http://www.nil.com/ipcorner/IPsecVPN2/
http://www.nil.com/ipcorner/IPsecVPN3/ ** here the configuration of IPSEC VTIs is covered
http://www.nil.com/ipcorner/IPsecVPN4/
http://www.nil.com/ipcorner/IPsecVPN5/

6 isn't out yet as far as i can see..

• edit made the post barely readable

Wow, thank you for your description.

Are there some official Cisco documents about this topic to which I am able to "refer to"?

Great post, thank you Gunni!

Hi.

I'm disgruntled. I registered an account just so I can vent.

I'm shocked that cisco requires a single SA of permit ANY ANY for IPSec VTI's.

Hello? Am I seeing things? Or does the documentation really say that?

I'm embarrassed for cisco.

What if... you find yourself in a situation not so unlike mine, in which you are required to bring various partners into your corporate network via IPsec connectivity.

Partners, which are other companies, have their own (usually crazy) addressing schemes and standards for VPN connections, and I like to protect my network from such chaos.

So, I prefer to do quite a bit of NAT'ing, as I suspect would be the case for most people in this scenario, on the router in which I terminate these VPN sessions on.

Having a virtual interface (in this case, an IPSec VTI), would afford for much flexibility for complex NAT'ing configurations where you may have to not only nat for yourself, but also for your partner because they're not capable of figuring it out on their end (or, maybe they just dont want to). [Double NAT]

Maybe you also have partners who require a rudimentary SA list, because they're using some sort of GUI-based VPN appliance that can be managed by Joe Blow Windows server guy... right?

Ok, well you're outta luck. No VTI for you unless you can talk them into doing a permit any/any for the SA.

C'mon cisco.

Time to decommission my cisco VPN routers and replace them with Linux boxes running openswan.

NETFILTER > IOS

Love,

George

That works great, if you admin both sides of the tunnel.

What if the other side of the tunnel is a different company.. And their VPN policy requires a more strict SA list?

I understand the freedom that being able to simply route whatever you want to the tunnel interface without having to renegotiate SA's... That's great..

But doesn't work in all scenarios, such as mine.

My complaint is that cisco is the KING of providing options and various ways to configure things, EXCEPT in this case, where they don't give you an option to make a more specific SA so that you can comply with the other side.

Instead, I get to use crypto maps and TWO devices to deal with my complex NAT'ing environment.. when it could easily all be done in one device if I could JUST have match the peer's SA list.

-G

no k00laid, it is possible to use gre tunneling with ipsec protection but you can also configure pure ipsec VTIs with no gre tunneling+overhead involved. the difference is displayed in the following configurations:

interface Tunnel10
 no ip address
 tunnel mode gre ip
 tunnel protection ipsec profile VTIs
end
Tunnel10 is up, line protocol is down
  Encapsulation TUNNEL, loopback not set
  Tunnel protocol/transport GRE/IP
  Tunnel protection via IPSec (profile "VTIs")

interface Tunnel11
 no ip address
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTIs
end
Tunnel11 is up, line protocol is down
  Encapsulation TUNNEL, loopback not set
  Tunnel protocol/transport IPSEC/IP
  Tunnel protection via IPSec (profile "VTIs")

Also, if you decide to use gre tunneling with ipsec protection for some reasons, f.x. older IOS where ipsec doesn't support multicast packets, you could minimize the overhead by applying ipsec in transport mode, i.e. no ip headers only ESP/AH header

In which way do GET VPNs fit into this topic?

Is GET VPNs a synonym for RAVPNs?

Edit: Sorry, educated myself a little bit (http://www.cisco.com/en/US/products/ps7180/index.html).

In simple words: Site-to-Site implementation with a central key server for authentication while maintaining QoS and multicast techniques.

Is this correct? I think so.

Edit2: Second question, is a Site-to-Site implementation with VTIs able to NAT?

I too am curious about timmi's last question : how do one NAT site2site VTI's ?

Anyone ?

Firstly you would identify the traffic flow direction, where traffic destined out the VTI arrives ingress, define the ingress position as ip nat inside and the VTI as ip nat outside.

now ofc if you are already doing NAT you will have to modify your existing access-lists so that the traffic destined out the VTI is not subject to NAT rules defined for WAN destined traffic. And the same will apply to the new NAT rules you are about to create, that is you will want to write the access-lists in a way to make sure that traffic destined to the WAN is not subject to LAN->VPN NAT translations.

Following is an example for a typical branch office using a ppp WAN connection, vlan 1 LAN connection and tunnel 0 for VPN. the LAN is natted only when accessing the WAN, the server is natted in both cases, possibly because of an address overlap on the other end in the VPNs case. This would require a static route on the other end of the VPN for the address being translated to, 10.0.1.10 that is.

test#s ip route
---- bla bla ----
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
C 192.168.1.0/24 is directly connected, Vlan1
D 172.21.21.0/24 [90/12837124901740] via 172.21.21.254, 00:00:01, Tunnel0
S* 0.0.0.0/0 is directly connected, Dialer1

object-group network RFC1918
 10.0.0.0 /8
 172.16.0.0 /12
 192.168.0.0 /16
int vlan 1
 ip address 192.168.1.254 255.255.255.0
 ip nat inside
int tu 0
 ip unn vl 1
 ip nat outside
int di 1
 ip nat outside
 ip address negotiated
router eigrp 1
 passive-interface Dialer 1
 network 10.0.0.0
 network 172.16.0.0 0.15.255.255
 network 192.168.0.0 0.0.255.255
ip nat inside source list ADSL int di 1 overload
ip nat inside source static 192.168.1.10 10.0.1.10 route-map server-VPN-NAT
ip nat inside source static 192.168.1.10 193.193.193.193 route-map server-WAN-NAT
ip access-l e ADSL
 deny ip host 192.168.1.10 any
 deny ip 192.168.1.0 0.0.0.255 object-group RFC1918
 permit ip 192.168.1.0 0.0.0.255 any
ip access-l e server-VPN-NAT-acl
 permit ip host 192.168.1.10 172.21.21.0 0.0.0.255
ip access-l e server-WAN-NAT-acl
 deny ip host 192.168.1.10 object-group RFC1918
 permit ip host 192.168.1.10 any
route-map server-VPN-NAT permit 10
 match ip address server-VPN-NAT-acl
route-map server-WAN-NAT permit 10
 match ip address server-WAN-NAT-acl

If that all becomes to complicated cisco has a feature called NAT Virtual Interface which is intended for such circumstances: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtnatvi.html personally i'm not familiar with it but i do realise that it's suited for this purpose.

hf!