IPsec tunnel mode encrypt a whole IP packet and sends it as the payload of another IP packet. I have always used GRE as the encapsulation layer when doing IPsec encryption. However, how could I have the same behavior with a router that supports IPsec but does not implements GRE ?
IPsec Tunnel Mode Without GRE – How It Works
greipsectunnel
Related Solutions
GRE is just a tunneling protocol - its main reason for existence is toplogy hiding/bypass.
Some examples include:
Tunneling MPLS across a network that may otherwise not support it - MPLS shims are not IP-based, therefore wrapping them in a GRE tunnel allows two routers to appear adjacent when there could be a number of intermediate IP-only devices.
Configuring EBGP sessions with neighbours that are not directly attached - this is often used by Anti-DDoS services to allow your prefixes to be advertised at their scrubbing stations, and traffic delivered directly to you even in cases where they may be multiple ASs away from your border
GRE over IPSEC is another common use that allows upper-layer routing-protocols to be established across IPSEC-based networks, avoiding the often static configuration and routing limitations posed by traditional (eg: Cisco-based) VPN deployments.
This is also an example of the open-ended security that the RFC mentions. This is not an oversight, merely a way of not excluding future technologies from being used (GREoSSL, GREoQuantumCryptography etc).
From the perspective of intermediary devices, the encapsulated traffic IS "Native" inside a GRE header, the fact that the payload is interpreted as additional headers on the terminating device is IMHO largely irrelevant.
GRE is just a protocol that most routers understand and it is simple enough that encap/decap doesn't burden the router too much.
Think of it another way - if you wanted to tunnel IP inside HTTP (perfectly possible, if somewhat inefficient) you would need to implement an HTTP server on all your routers. GRE is just a simpler, stateless, minimalist way to achieve the same thing.
I had a similar issue using a Static VTI IPSec tunnel. Initially the tunnel interface IP MTU was set to 1400 bytes with the "Crypto IPSec DF-bit clear" command set under the global configuration. The expected behaviour was for packets received (being forwarded to the VTI) should have the DF bit cleared and allow the packet to be fragmented before encryption is required. We found that any packets arriving with DF bit set that exceeded the tunnel IP MTU were being dropped and not switched to the tunnel interface.
After a long discussion with Cisco TAC it was explained that that VTI tunnels do not support fragmentation before encryption (as per bug ID CSCsr97396/CSCsh30577), This is apparently undocumented in any publically available Cisco documents including configuration guides... poor show Cisco considering this bug has been known since 2007!!!
The fix is to ensure the tunnel interface IP MTU is large enough (changed IP MTU to 1500) not to cause fragmentation. In the solution we deployed the egress interface is a point to point ATM interface (OC12/STM4 ATM SPA) with a default MTU of 4470 so no post encryption fragmentation will occur.
BTW, we are using ASR1006 router with ESP-10, RP2 with IOS-XE 3.13 if that helps.
Best Answer
In GRE+IPsec the original IP packet is encapsulated in a GRE tunnel packet. The GRE packet is then encapsulated in the IPSec packet.
The most common reason for doing this is to allow broadcast and multicast across the tunnel. Neither is supported by IPSec alone. GRE can also encapsulate non-IP traffic, which IPsec does not support.