When to use a GRE Tunnel?

[davidhuynh5]

I'm a little confused when to use a GRE tunnel and when to just use a simple VPN with IPSec tunnel.

For example, I have a development network (192.168.0.0/24) that I need to encrypt the traffic using IPSec, then tranport it over a 10.0.0.0/24 network.

The 10.0.0.0/24 network can not see the 192.168..0/24 in it's forwarding table. At the other end, the data gets unecrypted from 10.0.0.0 back to a 192.168.0.0/24. Is that just a simple VPN or GRE? The two confuses me. Thanks in advance.

[gatlin007]

This is from a fellow with roots in WAN routing; take it for what's it's worth.

I always use GRE when the equipment at both ends support it.

When utilizing a GRE tunnel you have routing at your finger tips.  The forwarding decision over the tunnel is based on a routing decision.  You can utilize all the dynamic routing protocols over the tunnel interface as if it were a physical interface.  The GRE tunnel can be encrypted and when it's sent out over public networks such as the internet it should be encrypted.  The encryption decision for a GRE tunnel is based on the source/destination addresses of the tunnel and not the traffic going through the tunnel.  This simplifies the encryption decision into a 1 line ACL.  It also decouples the forwarding decision from the encryption decision.

When utilizing a standard IPSEC tunnel the forwarding decision is based on an ACL.  In essence the forwarding decision is based on the encryption decision.  This decision is based on an ACL that is static and must be updated to increase or decrease functionality.  This critical ACL must be an exact match at both locations to ensure stability.

Since I'm a WAN routing fellow I'm always more comfortable having a forwarding decision that's based on routes/routing protocols versus static ACL's.

GRE has a bit more overhead (24 bytes), but it's well worth it for the functionality gained.

I highly recommend reading this white paper in regard to MTU and tunnels to realize an increased understanding of different tunnel technologies.

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml



Chris

[Anas Hazeen]

Why would you tunnel traffic using GRE? Here are some of the reasons:

• You need to encrypt multicast traffic. GRE tunnels can carry multicast packets—just like real network interfaces—as opposed to using IPSec by itself, which can't encrypt multicast traffic. Some examples of multicast traffic are OSPF, EIGRP, and RIPV2. Also, a number of video, VoIP, and streaming music applications use multicast.

• You have a protocol that isn't routable, such as NetBIOS or non-IP traffic over an IP network. For example, you could use GRE to tunnel IPX or AppleTalk through an IP network.

• You need to connect two similar networks connected by a different network with different IP addressing.

[Richard Burts]

David

I believe that the first point from Anas is the most important reason that you would need GRE tunnels. Support for multicast, especially multicast as used by routing protocols, is the most common reason for using GRE in my experience. His second point, about support for non-routed protocols, is valid but from my perspective is becoming less common and the transport of non-IP protocols is quite rare these days.

I would suggest that his third point about connecting two similar networks is frequently given as a reason to use GRE but is not an appropriate answer to your question. If you need to connect two similar networks over a different network GRE is certainly an option, but an IPSec tunnel is also a viable option to accomplish this.

I would suggest that there may be at least one more reason why you might choose to use GRE with IPSec. With GRE you get an interface, and if you configure tunnel keepalives the tunnel interface will go down if traffic is not going through the tunnel successfully. So it provides an easy way to monitor whether your encrypted traffic is working or not.

HTH

Rick

[akarun151]

One more most important advantage is there. - TTL.

When the actual packet is encapsulated inside the tunnel, its own ttl value will not be decreased until reaches the tunnel destination.

Thanks,

Arunkarthick