GRE Tunnels vs IPSec VPN - Differences and More

GRE Tunnels are very common amongst VPN implementations thanks to their simplicity and ease of configuration. With broadcasting and multicasting support, as opposed to pure IPSec VPNs (Because VTIs can support multicast), they tend to be the number one engineers' choice, especially when routing protocols are used amongst sites but still are not preffered to use very frequently. Lets see why -

 

GRE creates a virtual tunnel interface, so any packet that would be routed out this interface will be completely wrapped into a new packet.  This packet would prepend a GRE header and a NEW IP header with the outermost destination of x.x.y.y and the source IP of whatever interface that it used to egress the router.  This interface handles multicast & broadcast as one would expect.

IPSec on the other hand is a suite of protocols that we put together to achieve a goal.  This goal is to enforce a policy.  IPSec does not really support multicast in and of itself.  Now there are ways around this.  For example, we might decide that we wish to encrypt the GRE packet that we created above.  In that case, we might add an ESP header in the above mix.  In that case, multicast would still work, but we are only encrypting a unicast packet from the perspective of IPSEC (or more specifically the ESP protocol).

Now, From the above discussion we can conlclude that GRE would also provide you a VPN tunnel but the data flowing through that tunnel would not be encrypted (So, The possibility of eavsdropping remains open) on the other hand IPSec uses a complete suite of protocols for Authentication & Encryption but when we compare the performance throughput for both these technologies there is a big difference GRE's process data much faster than IPSec (Obviously that has to be since it is not performing any encryption/decryption).

Now lets take an example for the use case of both the technologies - 

GRE - A GRE tunnel is used when IP packets need to be sent from one network to another, without being parsed or treated like IP packets by any intervening routers.

For example, in Mobile IP, a mobile node registers with a Home Agent. When the mobile node roams to a new network, it registers with a Foreign Agent there. Whenever IP packets addressed to the mobile node are received by the Home Agent, they can be relayed over a GRE tunnel to the Foreign Agent for delivery. It does not matter how the Home Agent and Foreign Agent communicate with each other -- hops in between just pass along the GRE packet. Only the GRE tunnel endpoints -- the two Agents -- actually route the encapsulated IP packet.

IPSec - IPsec ESP is used when IP packets need to be exchanged between two systems while being protected against eavesdropping or modification along the way.

For example, in a site-to-site VPN, a source host in network "A" transmits an IP packet. When that packet reaches the edge of network "A," it hits a VPN gateway. VPN gateway "A" encrypts the private IP packet and relays it over an ESP tunnel to a peer VPN gateway at the edge of network "B." VPN gateway "B" then decrypts the packet and delivers it to the destination host. Like GRE, it doesn't really matter how the two VPN gateways communicate with each other -- hops in between just pass along the ESP packet. But unlike GRE, someone at those hops could not possibly look at or change the encapsulated IP packet, even if they wanted to. That's because cryptographic algorithms have been applied to scramble the IP packet and detect any modification or replay.

In summary, use a GRE tunnel where IP tunneling without privacy is required -- it's simpler and thus faster. But use IPsec ESP where IP tunneling and data privacy are required -- it provides security features that are not even attempted by GRE.

So,

If somebody wish to enjoy performance of GRE and security of IPSec then GRE over IPSec is definitely an option for you