IPSec Tunnel vs GRE Tunnel?

When working with VTI, what's the difference between tunnel mode ipsec ipv4 and tunnel mode gre ip? I've been wanting to do a packet capture to see if there's any difference in the packet but haven't had the time.

Find more posts tagged with

Comments

Bl8ckr0uter

I think ip will allow both ip and ipv6 and ipv4 will only allow ipv4. I asked the question to my senior engineer (we use a lot of tunnels) and that's what he told me.

cisco_trooper

GRE and Ipsec are different encapsulations. GRE is IP Protocol 47. IPSec is comprised of a number of different protocols each used depending on the IPSec configuration. IPSec has an authentication header available and an encapsulating security payload available. Authentication Header (AH) used IP protocol 51, and Encapsulating Security Payload (ESP) uses IP protocol 50.

pham0329

Bl8ckr0uter wrote: »

I think ip will allow both ip and ipv6 and ipv4 will only allow ipv4. I asked the question to my senior engineer (we use a lot of tunnels) and that's what he told me.

Really, that's it?!

cisco_trooper wrote: »

GRE and Ipsec are different encapsulations. GRE is IP Protocol 47. IPSec is comprised of a number of different protocols each used depending on the IPSec configuration. IPSec has an authentication header available and an encapsulating security payload available. Authentication Header (AH) used IP protocol 51, and Encapsulating Security Payload (ESP) uses IP protocol 50.

Right..but what's the difference between tunnel mode gre ip and tunnel mode ipsec ipv4 if you're going to apply a crypto profile to the tunnel? Why would you use one over the other?

cisco_trooper

Sorry, you mentioned doing a packet capture to see if there was any difference in the packet. :P

Bl8ckr0uter

pham0329 wrote: »

Really, that's it?!

I think so. I am going to have to do some more research to verify that but it does make sense (at least to me).

lrb

The tunnel mode gre ip command (which is the default under a tunnel interface) specifies that traffic being routed over this interface should be encapsulated in a GRE header to and from the hosts specified in the tunnel source and tunnel destination commands. This is plain old vanilla IP GRE where you incur the 4 byte penalty for the header and GRE by itself provides no crypto services. When you the tunnel config also has a crypto map applied, you have GRE/IPsec configuration. The crypto map specifies the traffic which you want to encrypt between the endpoints (e.g. all IP traffic between 10.10.0.0/24 <--> 10.20.0.0/24). Traffic which is routed over the tunnel interface and matches the crypto map is encrypted; other traffic is not.

The tunnel mode ipsec ipv4 command when used with the tunnel protection ipsec profile command is IPv4 IPsec VTI which doesn't have the 4 byte loss you get with GRE and there are no crypto maps. You have the transform set to define you preference for crypto (encryption and hash) which is linked to a VTI profile, which is in turn linked to the tunnel interface. Any traffic routed over the interface is encrypted using the settings in the transform set from the VTI profile.

Also I haven't done much with IPv6 at work but my guess is that tunnel mode gre ip will only encaps IPv4 traffic and tunnel mode gre ipv6 will only encaps IPv6 traffic in the same way that the tunnel mode ipsec ipv4 and tunnel mode ipsec ipv6 only work with the referenced IP version.

Bl8ckr0uter

Very good information. I'll have to pass this information to my senior here. +Rep.

pham0329

I dont believe we use crypto maps with our GRE vti interfaces. We define a transform set, link it to a profile, and apply it to the interface. So in essence, all configuration are the same, except the tunnel mode.

lrb

Correct, VTI doesn't use crypto maps, but there are some more differences other than just the tunnel mode command.

1. Both GRE/IPsec and VTI will have their ISAKMP policy defined using the crypto isakmp policy config
2. GRE/IPsec requires the crypto map configuration, which defines the crypto peer, links the transform set, links the interesting traffic ACL, and other settings like QoS pre-classify
3. VTI requires only the crypto ipsec profile configuration, which links the transform set. The crypto peer is implicitly defined as the tunnel destination, and the interesting traffic is implicitly defined as anything routed over the tunnel interface. Other settings like QoS pre-classify are also defined under the tunnel configuration with VTI, not a crypto map.
4. If the interesting ACLs don't match on either end you will run into problems with GRE/IPsec. With VTI, both endpoints just assume that anything going out the interface needs to be encrypted and anything coming into the interface needs to be decrypted.