2.2.b GRE and IPsec tunneling

5 min read ENCOR 350-401 v1.2

Aligned to Cisco's 350-401 ENCOR v1.2 exam topics.

On this page

A tunnel carries traffic across a network that does not natively provide the path you want.

For ENCOR, you need to understand GRE, IPsec, and why they are often used together.

GRE gives you encapsulation.
IPsec gives you encryption and authentication.
GRE over IPsec gives you a routable tunnel that can also be protected.

GRE in plain English

GRE wraps an original packet inside a new packet.

Original packet: 10.1.1.10
10.2.2.10
GRE outer packet: 198.51.100.1
203.0.113.2

The underlay network only needs to know how to route between the tunnel endpoints. It does not need to know the private prefixes behind each router.

GRE is useful because it can carry routed traffic across another IP network. It can also carry multicast and routing protocol traffic, which plain IPsec site-to-site policy tunnels do not handle as naturally.

GRE does not encrypt traffic by itself.

IPsec in plain English

IPsec protects IP traffic. It can provide confidentiality, integrity, authentication, and anti-replay protection depending on how it is configured.

On its own, IPsec is often used to encrypt traffic between two sites. When combined with GRE, IPsec protects the GRE packets between the public tunnel endpoints.

Private traffic
GRE tunnel -> IPsec protection -> WAN/Internet

IKE phase 1 · UDP 500/4500 (NAT-T) between peers
IKE phase 2 · IPsec SA negotiated
Data plane · match crypto map → encrypt → underlay → decrypt

Host 10.1.1.10 on LAN-A -> Route lookup via Tunnel0 GRE -> GRE outer 198.51.100.1 to 198.51.100.2 -> ESP encrypts GRE packet -> Underlay Internet / WAN -> R2 decrypt · GRE decap · deliver to 10.2.2.0/24

Basic GRE lab

Topology

LAN-A 10.1.1.0/24
R1 · 198.51.100.1
WAN
R2 · 198.51.100.2
LAN-B 10.2.2.0/24
Tunnel0 172.16.12.1/30 ↔ 172.16.12.2/30

R1

conf t
interface GigabitEthernet0/0
 description WAN to R2
 ip address 198.51.100.1 255.255.255.252
 no shutdown
!
interface GigabitEthernet0/1
 description LAN-A
 ip address 10.1.1.1 255.255.255.0
 no shutdown
!
interface Tunnel0
 description GRE to R2
 ip address 172.16.12.1 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination 198.51.100.2
 ip mtu 1400
 ip tcp adjust-mss 1360
 no shutdown
!
ip route 10.2.2.0 255.255.255.0 172.16.12.2
end

R2

conf t
interface GigabitEthernet0/0
 description WAN to R1
 ip address 198.51.100.2 255.255.255.252
 no shutdown
!
interface GigabitEthernet0/1
 description LAN-B
 ip address 10.2.2.1 255.255.255.0
 no shutdown
!
interface Tunnel0
 description GRE to R1
 ip address 172.16.12.2 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination 198.51.100.1
 ip mtu 1400
 ip tcp adjust-mss 1360
 no shutdown
!
ip route 10.1.1.0 255.255.255.0 172.16.12.1
end

Verify GRE

show interface tunnel0
show ip interface brief | include Tunnel0
show ip route 10.2.2.0
show ip route 198.51.100.2
ping 172.16.12.2 source 172.16.12.1
ping 10.2.2.1 source 10.1.1.1
traceroute 10.2.2.1 source 10.1.1.1

If the tunnel fails, check the underlay route to the tunnel destination before chasing LAN routes.

GRE over IPsec: what ENCOR should recognize

There are several valid ways to build this. Older IOS labs often use a classic crypto map that matches GRE between public endpoints. Many modern IOS XE examples use IKEv2 and an IPsec profile applied directly to the tunnel with tunnel protection ipsec profile. Do not memorize one vendor-lab syntax as if it is the technology.

The exam value is the layer separation:

GRE creates the routed tunnel interface and carries the private overlay packet.
IPsec protects the GRE packet between the public tunnel endpoints.
The underlay route must reach the tunnel destination before GRE or IPsec can work.
Overlay routes for private networks usually point to the tunnel IP, not the WAN IP.
IPsec verification must show security associations and packet counters increasing.

Classic crypto-map examples are still useful for reading older configurations, but label them as legacy-style labs.

Modern IOS XE recognition pattern:

crypto ikev2 proposal ENCOR-IKEV2-PROP
encryption aes-cbc-256
integrity sha256
group 14
!
crypto ikev2 policy ENCOR-IKEV2-POLICY
proposal ENCOR-IKEV2-PROP
!
crypto ikev2 keyring ENCOR-IKEV2-KEYS
peer R2
address 198.51.100.2
pre-shared-key local CcnpLabKey
pre-shared-key remote CcnpLabKey
!
crypto ikev2 profile ENCOR-IKEV2-PROFILE
match identity remote address 198.51.100.2 255.255.255.255
authentication local pre-share
authentication remote pre-share
keyring local ENCOR-IKEV2-KEYS
!
crypto ipsec transform-set ENCOR-TS esp-aes 256 esp-sha256-hmac
mode transport
!
crypto ipsec profile GRE-PROTECT
set transform-set ENCOR-TS
set ikev2-profile ENCOR-IKEV2-PROFILE
!
interface Tunnel0
 tunnel source GigabitEthernet0/0
 tunnel destination 198.51.100.2
 tunnel protection ipsec profile GRE-PROTECT

This is still a recognition pattern, not a complete deployment recipe. Exact syntax varies by platform and release. For ENCOR, recognize the relationship between the tunnel, peer authentication, IKEv2 profile matching, IPsec profile binding, peer reachability, SAs, and counters.

Read route-based GRE/IPsec as a layer stack:

private packet
route lookup -> Tunnel0 -> GRE outer packet -> IPsec protection -> underlay next hop

If any layer is wrong, the symptom may look like "the tunnel is down" even when the real failure is routing, selectors, NAT, MTU, or return path.

GRE over IPsec legacy-style lab

The example below uses a classic crypto map that matches GRE between the public endpoints. Treat it as a legacy study lab pattern and a configuration-reading exercise.

R1 IPsec protection for GRE

conf t
crypto isakmp policy 10
encryption aes 256
hash sha256
authentication pre-share
group 14
lifetime 86400
!
crypto isakmp key CcnpLabKey address 198.51.100.2
!
crypto ipsec transform-set TS esp-aes 256 esp-sha-hmac
mode transport
!
ip access-list extended GRE-TO-R2
permit gre host 198.51.100.1 host 198.51.100.2
!
crypto map CMAP 10 ipsec-isakmp
set peer 198.51.100.2
set transform-set TS
match address GRE-TO-R2
!
interface GigabitEthernet0/0
 crypto map CMAP
 end

In this legacy pattern, the crypto ACL matches the GRE packet between public tunnel endpoints. It does not match 10.1.1.0/24 to 10.2.2.0/24; those private packets are inside the GRE wrapper.

R2 IPsec protection for GRE

conf t
crypto isakmp policy 10
encryption aes 256
hash sha256
authentication pre-share
group 14
lifetime 86400
!
crypto isakmp key CcnpLabKey address 198.51.100.1
!
crypto ipsec transform-set TS esp-aes 256 esp-sha-hmac
mode transport
!
ip access-list extended GRE-TO-R1
permit gre host 198.51.100.2 host 198.51.100.1
!
crypto map CMAP 10 ipsec-isakmp
set peer 198.51.100.1
set transform-set TS
match address GRE-TO-R1
!
interface GigabitEthernet0/0
 crypto map CMAP
 end

Verify IPsec

Generate interesting traffic first.

ping 10.2.2.1 source 10.1.1.1

Then check the security associations.

show crypto ikev2 sa
show crypto isakmp sa
show crypto ipsec sa
show access-lists GRE-TO-R2
show interface tunnel0

Look for encapsulated and decapsulated packet counters increasing in show crypto ipsec sa.

Crypto selectors and counter proof

For a classic crypto-map GRE-over-IPsec lab, the interesting traffic selector usually matches GRE between the two public tunnel endpoints:

permit gre host 198.51.100.1 host 198.51.100.2

The peer must have the mirror image selector. If one side protects GRE between public endpoints and the other side expects private LAN prefixes, the tunnel can fail even when reachability and keys look right.

When reading show crypto ipsec sa, do not stop at "SA exists." Check:

local and remote crypto endpoints;
local and remote protected identities or proxy IDs;
encaps counters increasing when you send traffic outbound;
decaps counters increasing when return traffic comes back;
replay, verify, or decrypt errors.

If encaps increases but decaps does not, suspect return path, peer policy, or remote decryption. If neither counter increases, suspect routing into the tunnel, crypto selector mismatch, or the wrong interface/policy.

MTU and MSS

Tunnels add headers. That means the outer packet is larger than the original packet. If the path MTU is too small, large packets can fragment or fail.

That is why you often see:

interface Tunnel0
 ip mtu 1400
 ip tcp adjust-mss 1360

The exact values depend on the environment, but the idea is important: leave room for encapsulation overhead.

Troubleshooting checklist

Can each router reach the other's tunnel destination?

ping 198.51.100.2 source 198.51.100.1
show ip route 198.51.100.2

Is the tunnel configured with the correct source and destination?

show run interface tunnel0

Is there a route for the remote private network through the tunnel?

show ip route 10.2.2.0

If using IPsec, are SAs up and counters increasing?

show crypto ikev2 sa
show crypto isakmp sa
show crypto ipsec sa

Is MTU causing partial failures?

ping 10.2.2.1 size 1400 df-bit

Exam traps

GRE by itself is not encryption.
IPsec protects traffic but does not automatically create a normal routed interface like GRE does.
Classic crypto maps and route-based tunnel protection can both appear in study material. The exam skill is recognizing the layers and verification output, not worshipping one syntax block.
Crypto-map selectors and route-based tunnel protection fail in different places. A crypto-map lab often fails at proxy identity or interesting-traffic matching; a route-based lab often fails at tunnel protection binding, overlay routing, or peer/IKEv2 profile matching.
The underlay must be able to route between tunnel endpoints.
Routes for remote private networks usually point to the tunnel IP, not the public WAN IP.
Tunnels add overhead; MTU problems can look like random application failures.
A tunnel can appear up while traffic still fails because routes, ACLs, IPsec, or MTU are wrong.

Quick check

What does GRE add?
What does IPsec add?
What route must exist before a GRE tunnel can work?
Why are ip mtu and ip tcp adjust-mss common on tunnels?
Which command shows IPsec encrypted/decrypted packet counters?