To minimize the complexity of configuration we can use IPsec profiles and associate them to Virtual Tunnel Interfaces. Its more like a Route Based VPN in Juniper NetScreen. There are other reasons why you would want to consider using VTIs to implement GRE over IPsec and they can be found here.
Jeremy Stretch has written a fantastic post on configuring GRE over IPsec using VTIs in the most simplest way possible – http://packetlife.net/blog/2008/jul/14/ipsec-quick-and-dirty/ so i won’t be bothering to include that all over again.
Just adding some notes below for my reference;
As GRE does not have its own mechanism to encrypt traffic it depends on IPsec for getting the encryption job done. As opposed to GRE over IPsec, which encrypts anything that is encapsulated by GRE, IPsec over GRE encrypts only the payload and not the routing protocols running over a GRE tunnel.
In IPsec over GRE, the GRE tunnel is established over the internet, neighborship is formed and routes are exchanged and all of this is in clear text. We are only concerned with encrypting the interesting traffic flowing between the two peers. When securing the routing updates and routes isn’t a requirement and the major concern is to encrypt the information/payload flowing between the peers we use IPsec over GRE.
IPsec over GRE eliminates the additional overhead of encrypting the GRE header.
As GRE does not have its own mechanism to encrypt traffic it depends on IPsec for getting the encryption job done. The whole point of GRE over IPsec is to encrypt what is encapsulated by GRE.
In GRE over IPsec, the entire GRE encapsulated packet is encrypted with an IPsec header. The interesting traffic defined for IPsec encryption is the ‘GRE’ traffic between the source and destination, so the underlying payload is also encrypted along with the routing updates.
The goal is to establish EIGRP neighborship between two Cisco IOS routers R1 and R2 using the tunnel interface, exchange routes (loopback IPs) and make sure the communication takes place between the loopback networks. But allowing communication isn’t our only motive, we want to encrypt all traffic flowing between R1 and R2. That includes the routing information (EIGRP updates) sent over the internet and also the communication between the loopback networks.
To be honest, there isn’t much of a change in the configuration of an IPsec Remote Access VPN in ASA 8.3/8.4. There is just a minor change in some of the ‘crypto’ statements wherein you need to specify it as either IKEv1 or IKEv2.
So if you are planning to use the legacy IPsec VPN client (the one with that yellow lock icon) then you need to configure your Remote Access VPN with IKEv1 option. And if you’re planning to move to the new AnyConnect VPN client, then you need to configure your Remote Access VPN for IKEv2. AnyConnect does support IPsec VPN, it’s just that it will only work when you have the respective remote access VPN configured for IKEv2.
Please note that the ASA can simultaneously be configured for both IKEv1 and IKEv2. Though they use the same UDP port they are not interoperable but they work independently without any conflicts.
The following post covers the basic configuration that will be required for running an IKEv1 Remote Access VPN in ASA 8.3/8.4. Continue reading