GRE and IPsec Tunneling for CCNP 350-401 ENCOR: Configuration, Verification, and Troubleshooting

Ramez Dous -

Introduction

For CCNP 350-401 ENCOR, I always tell people to keep three ideas straight in their head: GRE is just a way to encapsulate traffic, IPsec is what gives you the security, and GRE over IPsec is the classic recipe for building a secure routed overlay on top of an untrusted underlay. That distinction matters on the exam and even more in production. And here's the thing: a tunnel can be up while routing is still a mess, IKE can come up while not a single protected packet is flowing, and even a config that looks perfectly clean on paper can still fail because the underlay path, MTU, or firewall policy isn't doing what you think it is.

My rule of thumb is pretty simple: prove the underlay first, then check the overlay, then validate the control plane, and only then move on to the data plane. Once you really keep underlay and overlay separate in your mind, GRE and IPsec stop feeling like vague exam theory and start acting like solid, predictable building blocks.

GRE Fundamentals

GRE, or Generic Routing Encapsulation, is a tunneling mechanism that can carry one protocol inside another. In the Cisco IOS XE examples here, tunnel mode gre ip creates a Layer 3 overlay that carries IP over an IP underlay. That means the tunnel interface behaves like a logical point-to-point routed link between two routers.

GRE itself is not encryption. It doesn't give you confidentiality, integrity, peer authentication, or anti-replay protection. It is only encapsulation. On an untrusted network, plain GRE exposes payloads unless another security mechanism such as IPsec is added.

A GRE tunnel depends on a local tunnel source and a remote tunnel destination. Those are underlay addresses, not overlay addresses. If the local router cannot reach the far-end underlay address through the physical network, the GRE overlay will not function. This is also where recursive routing becomes dangerous: if the route to the tunnel destination resolves back through the tunnel itself, the tunnel can flap or collapse. A common fix is an explicit host route to the remote tunnel destination via the physical next hop or a default route that clearly points to the underlay.

GRE is popular because it can transport multicast and other non-unicast traffic over a unicast underlay, which makes routing protocols such as OSPF and EIGRP comfortable across the tunnel. That said, forwarding behavior always depends on platform and design; in these IOS XE routed tunnel examples, think of GRE as a multicast-friendly Layer 3 overlay interface, not a generic promise that any Layer 2 behavior will magically work.

GRE keepalives can help detect some failures, but they are optional and not a substitute for routing protocol hellos, BFD, or IP SLA/object tracking. In enterprise designs, layered liveness is more reliable than GRE keepalives alone.

One more practical note: plain GRE rides on IP protocol 47. So if a firewall or NAT device in the underlay blocks protocol 47, a GRE-only tunnel's going to fail even though plain old ping or basic IP reachability may look completely fine.

IPsec Fundamentals

IPsec is what gives your traffic the security side of the house — confidentiality, integrity, peer authentication, and anti-replay protection all wrapped up together. In the real world, ESP is the one you care about most. AH exists academically, but it is rarely deployed because it does not provide confidentiality and does not work well with NAT. ESP is the normal enterprise choice.

IPsec has two major operating modes. In tunnel mode, the original IP packet is protected and then wrapped with a new outer IP header. In transport mode, IPsec protects the payload of the original outer IP packet. For classic GRE over IPsec on Cisco IOS XE using tunnel protection, transport mode is commonly used because GRE already provides the overlay encapsulation. That is a common Cisco pattern, not a universal rule across every platform and vendor.

Security relationships are built with Security Associations. With IKEv1, you’ll usually hear people talk about Phase 1 and Phase 2, which is the old-school way most of us learned to think about it. IKEv2 cleans that up a bit: first the router brings up an IKE SA, and then it builds one or more CHILD_SAs for the actual traffic you want protected. And that distinction matters a lot when you're troubleshooting, because most of the time you’re trying to figure out whether the control-plane SA is alive, whether the data-plane SA is alive, or whether both are up but nothing’s actually matching them.

IKEv1 is definitely older, sure, but don’t ignore it — it’s still absolutely fair game for the exam. IKEv2 is cleaner, more scalable, and generally preferred in current designs. Authentication is typically done with pre-shared keys or certificate-based authentication. Certificates scale better for peer identity management, but they also require PKI planning, trustpoints, enrollment, revocation handling, and lifecycle management.

Crypto choices matter. Modern designs prefer IKEv2, strong AES-based encryption, strong DH groups supported by the platform, and avoidance of legacy algorithms where possible. AES-GCM is worth knowing because it is an AEAD option that combines encryption and integrity differently from older combinations such as AES plus HMAC-SHA. Group 14 still appears often in labs and exam content, but stronger groups may be preferred where supported.

NAT traversal is also critical. IKE normally starts on UDP/500. If NAT is detected, ESP is encapsulated in UDP/4500 so traffic can cross NAT devices. Without NAT-T, native IPsec depends on ESP, which is IP protocol 50, being permitted through the path.

Anti-replay protection is a major benefit of IPsec, but in edge cases heavy packet reordering or asymmetric forwarding can interact with replay windows. Usually that is not the first thing to suspect, but it belongs in the advanced troubleshooting toolbox.

Policy-based IPsec, route-based IPsec, and GRE over IPsec

This is one of those distinctions that's really important to get right. Traditional crypto map IPsec is policy-based. It protects traffic matched by selectors, usually ACL-defined interesting traffic. That model works really well when you just need subnet-to-subnet encryption, but it starts to feel a little awkward once you’re dealing with routed overlays or protocols that depend on multicast.

Route-based IPsec creates a virtual interface model. On Cisco, that can mean VTIs, SVTIs, or FlexVPN-style designs. These can carry dynamic routing without GRE because the router now has a routed interface to work with. So it's not really accurate to say GRE is the only way to run routing over encrypted overlays.

GRE over IPsec is basically two layers working together: GRE gives you the routed overlay interface, and IPsec protects the GRE packet. That's why it still shows up so often in enterprise WAN designs, migrations, and branch-to-HQ overlays. But for ENCOR, don't get tunnel vision: GRE over IPsec is common, VTI/FlexVPN gives you a route-based alternative, and DMVPN takes related ideas and stretches them into a more scalable hub-and-spoke model.

Quick comparison

  • GRE: Encapsulation only, excellent for routing, supports multicast-friendly routed overlays, but is not secure by itself.
  • Policy-based IPsec: Encrypts interesting traffic matched by selectors, works well for simple site-to-site subnet encryption, but is less natural for dynamic routing.
  • Route-based IPsec (VTI/FlexVPN): Uses a virtual routed interface protected by IPsec, supports routing well, and is a modern way to build encrypted routed connectivity without GRE.
  • GRE over IPsec: Uses GRE for the overlay and IPsec for protection, making it a strong choice for secure routed overlays with dynamic routing.

Packet Walks and Encapsulation Order

A packet walk clears up most confusion.

GRE only: an inner packet from 172.16.1.10 to 172.16.2.10 is routed to Tunnel0. Then the router slaps on the GRE header and wraps the whole thing in a new outer IP header using the tunnel source and destination from the underlay. On the wire, that payload is still visible because GRE doesn't encrypt anything.

Policy-based IPsec tunnel mode: a packet matching the crypto ACL is selected as interesting traffic. IPsec then protects the original packet and adds a fresh outer IP header between the VPN peers. There is no GRE interface unless you build one separately.

GRE over IPsec transport mode: the router first encapsulates the inner packet in GRE. That GRE packet then becomes the traffic protected by IPsec. On the wire, you see the underlay outer IP header plus ESP, or UDP/4500 if NAT-T is in use. The original payload and GRE details are hidden by encryption.

That is the exam memory aid in precise form: GRE provides the overlay encapsulation; IPsec protects it.

Building a GRE Tunnel on Cisco IOS XE

I always start with a simple two-router topology because, honestly, if you can make it work there, you can usually reason your way through the bigger design. So picture R1’s underlay as 203.0.113.1/30, R2’s underlay as 198.51.100.2/30, the tunnel network as 10.10.10.0/30, and the LANs as 172.16.1.0/24 and 172.16.2.0/24.

! R1 underlay
interface GigabitEthernet0/0 ! Apply the crypto map to the WAN-facing interface ! R2 underlay-facing interface ! This is the physical underlay-facing interface ip address 203.0.113.1 ! Peer address in the R2 keyring ! Remote peer underlay address on the opposite side 255.255.255.252 ! R1 underlay IP no shut
ip route 198.51.100.2 255.255.255.255 203.0.113.2 ! Keep the remote tunnel destination reachable through the underlay interface Tunnel0 ip address 10.10.10.1 255.255.255.252 ! Tunnel IP on R1 ! Overlay tunnel IP tunnel source 203.0.113.1 ! Underlay source for the VTI ! Use the underlay interface or address as the tunnel source ! Use the underlay address as the tunnel source tunnel destination 198.51.100.2 ! Remote VTI peer ! Remote GRE endpoint ! Point the tunnel at the remote underlay endpoint tunnel mode gre ip keepalive 10 3 ! Optional tunnel keepalive ! Optional, but handy for spotting a dead tunnel faster ip route 172.16.2.0 255.255.255.0 10.10.10.2 ! Send the remote LAN toward the tunnel ! R2 underlay
interface GigabitEthernet0/0 ! Apply the crypto map to the WAN-facing interface ! R2 underlay-facing interface ! This is the physical underlay-facing interface ip address 198.51.100.2 ! Peer address for the keyring entry ! Remote peer underlay address 255.255.255.252 ! R2 underlay IP no shut
ip route 203.0.113.1 255.255.255.255 198.51.100.1 ! Make sure the far-end underlay is reachable interface Tunnel0 ip address 10.10.10.2 255.255.255.252 ! Tunnel IP on R2 ! Overlay tunnel IP on R2 tunnel source 198.51.100.2 ! R2 underlay source ! Underlay source for the tunnel2 tunnel destination 203.0.113.1 ! R1 underlay destination ! Remote tunnel endpoint tunnel mode gre ip keepalive 10 3 ! Optional tunnel keepalive ! Optional, but handy for spotting a dead tunnel faster ip route 172.16.1.0 255.255.255.0 10.10.10.1 ! Return path back across the overlay

For point-to-point GRE, you’ll often see routes pointing either straight through the tunnel or to the next-hop tunnel IP. In labs, I usually find the tunnel IP easier to reason about when I'm troubleshooting.

I’d verify it in this order:

ping 198.51.100.2 source 203.0.113.1
show interface tunnel0
show ip route
show ip cef 198.51.100.2 ! Confirm how the router is actually resolving the path
ping 10.10.10.2 source 10.10.10.1 ! Test the overlay once the underlay is proven

Setting Up Policy-Based Site-to-Site IPsec

This is the pure native IPsec example, corrected so it is clearly policy-based LAN-to-LAN IPsec rather than GRE protection.

! R1
crypto ikev2 proposal IKEV2-PROP ! Same IKEv2 proposal on the far end ! IKEv2 proposal for the GRE over IPsec example ! Reference the proposal you just defined ! Start the IKEv2 build with a proposal encryption aes-cbc-256 ! Same encryption choice for symmetry ! AES-256 is a common practical choice ! Use a strong encryption algorithm integrity sha256 ! Same integrity setting on both peers ! SHA-256 integrity for the IKE negotiation ! Add integrity checking to the negotiation group 14 crypto ikev2 policy IKEV2-POL ! Reuse the same policy logic on R2 ! Tie the proposal into a policy ! Build the IKEv2 policy around the proposal proposal IKEV2-PROP ! Reference the proposal you just defined crypto ikev2 keyring KR peer R2 address 198.51.100.2 ! Peer address for the keyring entry ! Remote peer underlay address pre-shared-key ccnpkey crypto ikev2 profile PROF match identity remote address 198.51.100.2 ! Peer address for the keyring entry ! Remote peer underlay address 255.255.255.255 authentication local pre-share authentication remote pre-share keyring local KR crypto ipsec transform-set TS-LAN esp-aes 256 esp-sha256-hmac ! IPsec transform set for the LAN-to-LAN VPN ! Define the protection suite for the protected traffic mode tunnel ip access-list extended ACL-LAN-TO-LAN ! Traffic selector for the other side ! Match the traffic you actually want to encrypt permit ip 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255 ! This is the interesting traffic selector crypto map CMAP 10 ipsec-isakmp ! Same crypto map concept, opposite side ! Attach the IPsec policy to the interface set peer 198.51.100.2 ! Define the VPN peer set ikev2-profile PROF set transform-set TS-LAN match address ACL-LAN-TO-LAN ! Tell IPsec which traffic should be protected interface GigabitEthernet0/0 ! Apply the crypto map to the WAN-facing interface ! R2 underlay-facing interface ! This is the physical underlay-facing interface crypto map CMAP
! R2
crypto ikev2 proposal IKEV2-PROP ! Same IKEv2 proposal on the far end ! IKEv2 proposal for the GRE over IPsec example ! Reference the proposal you just defined ! Start the IKEv2 build with a proposal encryption aes-cbc-256 ! Same encryption choice for symmetry ! AES-256 is a common practical choice ! Use a strong encryption algorithm integrity sha256 ! Same integrity setting on both peers ! SHA-256 integrity for the IKE negotiation ! Add integrity checking to the negotiation group 14 crypto ikev2 policy IKEV2-POL ! Reuse the same policy logic on R2 ! Tie the proposal into a policy ! Build the IKEv2 policy around the proposal proposal IKEV2-PROP ! Reference the proposal you just defined crypto ikev2 keyring KR peer R1 address 203.0.113.1 ! Peer address in the R2 keyring ! Remote peer underlay address on the opposite side pre-shared-key ccnpkey crypto ikev2 profile PROF match identity remote address 203.0.113.1 ! Peer address in the R2 keyring ! Remote peer underlay address on the opposite side 255.255.255.255 authentication local pre-share authentication remote pre-share keyring local KR crypto ipsec transform-set TS-LAN esp-aes 256 esp-sha256-hmac ! IPsec transform set for the LAN-to-LAN VPN ! Define the protection suite for the protected traffic mode tunnel ip access-list extended ACL-LAN-TO-LAN ! Traffic selector for the other side ! Match the traffic you actually want to encrypt permit ip 172.16.2.0 0.0.0.255 172.16.1.0 0.0.0.255 ! Reverse direction for the selector crypto map CMAP 10 ipsec-isakmp ! Same crypto map concept, opposite side ! Attach the IPsec policy to the interface set peer 203.0.113.1 ! Remote peer for R2 set ikev2-profile PROF set transform-set TS-LAN match address ACL-LAN-TO-LAN ! Tell IPsec which traffic should be protected interface GigabitEthernet0/0 ! Apply the crypto map to the WAN-facing interface ! R2 underlay-facing interface ! This is the physical underlay-facing interface crypto map CMAP

This is useful for simple subnet encryption, but it is not the same operational model as a routed GRE overlay.

Configuring GRE over IPsec with Tunnel Protection

This is the classic route-based Cisco pattern for a secure GRE overlay. GRE builds the overlay interface; IPsec protects GRE traffic. Transport mode is commonly used here because GRE already adds the tunnel encapsulation.

! R1
crypto ikev2 proposal IKEV2-PROP ! Same IKEv2 proposal on the far end ! IKEv2 proposal for the GRE over IPsec example ! Reference the proposal you just defined ! Start the IKEv2 build with a proposal encryption aes-cbc-256 ! Same encryption choice for symmetry ! AES-256 is a common practical choice ! Use a strong encryption algorithm integrity sha256 ! Same integrity setting on both peers ! SHA-256 integrity for the IKE negotiation ! Add integrity checking to the negotiation group 14 crypto ikev2 policy IKEV2-POL ! Reuse the same policy logic on R2 ! Tie the proposal into a policy ! Build the IKEv2 policy around the proposal proposal IKEV2-PROP ! Reference the proposal you just defined crypto ikev2 keyring IKEV2-KR ! R2’s keyring for R1 ! Store the remote peer credentials here peer R2 address 198.51.100.2 ! Peer address for the keyring entry ! Remote peer underlay address pre-shared-key ccnpkey crypto ikev2 profile IKEV2-PROFILE ! R2’s IKEv2 profile ! Build the IKEv2 profile used by the IPsec profile match identity remote address 198.51.100.2 ! Peer address for the keyring entry ! Remote peer underlay address 255.255.255.255 authentication local pre-share authentication remote pre-share keyring local IKEV2-KR crypto ipsec transform-set GRE-TS esp-aes 256 esp-sha256-hmac ! Same transform set on both sides ! Protect the GRE payload with ESP mode transport crypto ipsec profile GRE-IPSEC-PROFILE ! R2’s IPsec profile for the GRE tunnel ! Create the IPsec profile that will be applied to the tunnel set transform-set GRE-TS set ikev2-profile IKEV2-PROFILE ! Bind the IPsec profile to the IKEv2 profile ! Bind the profile to the IKEv2 settings set pfs group14 interface Tunnel0 ip address 10.10.10.1 255.255.255.252 ! Tunnel IP on R1 ! Overlay tunnel IP ip mtu 1400 ! Match the tunnel MTU on both ends ! Lower the tunnel MTU to account for encapsulation overhead ip tcp adjust-mss 1360 ! Keep MSS consistent on both ends ! Keep TCP from sending oversized segments into the tunnel qos pre-classify tunnel source 203.0.113.1 ! Underlay source for the VTI ! Use the underlay interface or address as the tunnel source ! Use the underlay address as the tunnel source tunnel destination 198.51.100.2 ! Remote VTI peer ! Remote GRE endpoint ! Point the tunnel at the remote underlay endpoint tunnel mode gre ip tunnel path-mtu-discovery ! Let the tunnel try to discover a workable path MTU tunnel protection ipsec profile GRE-IPSEC-PROFILE ! This is the key line that turns GRE into GRE over IPsec
! R2
crypto ikev2 proposal IKEV2-PROP ! Same IKEv2 proposal on the far end ! IKEv2 proposal for the GRE over IPsec example ! Reference the proposal you just defined ! Start the IKEv2 build with a proposal encryption aes-cbc-256 ! Same encryption choice for symmetry ! AES-256 is a common practical choice ! Use a strong encryption algorithm integrity sha256 ! Same integrity setting on both peers ! SHA-256 integrity for the IKE negotiation ! Add integrity checking to the negotiation group 14 crypto ikev2 policy IKEV2-POL ! Reuse the same policy logic on R2 ! Tie the proposal into a policy ! Build the IKEv2 policy around the proposal proposal IKEV2-PROP ! Reference the proposal you just defined crypto ikev2 keyring IKEV2-KR ! R2’s keyring for R1 ! Store the remote peer credentials here peer R1 address 203.0.113.1 ! Peer address in the R2 keyring ! Remote peer underlay address on the opposite side pre-shared-key ccnpkey crypto ikev2 profile IKEV2-PROFILE ! R2’s IKEv2 profile ! Build the IKEv2 profile used by the IPsec profile match identity remote address 203.0.113.1 ! Peer address in the R2 keyring ! Remote peer underlay address on the opposite side 255.255.255.255 authentication local pre-share authentication remote pre-share keyring local IKEV2-KR crypto ipsec transform-set GRE-TS esp-aes 256 esp-sha256-hmac ! Same transform set on both sides ! Protect the GRE payload with ESP mode transport crypto ipsec profile GRE-IPSEC-PROFILE ! R2’s IPsec profile for the GRE tunnel ! Create the IPsec profile that will be applied to the tunnel set transform-set GRE-TS set ikev2-profile IKEV2-PROFILE ! Bind the IPsec profile to the IKEv2 profile ! Bind the profile to the IKEv2 settings set pfs group14 interface Tunnel0 ip address 10.10.10.2 255.255.255.252 ! Tunnel IP on R2 ! Overlay tunnel IP on R2 ip mtu 1400 ! Match the tunnel MTU on both ends ! Lower the tunnel MTU to account for encapsulation overhead ip tcp adjust-mss 1360 ! Keep MSS consistent on both ends ! Keep TCP from sending oversized segments into the tunnel qos pre-classify tunnel source 198.51.100.2 ! R2 underlay source ! Underlay source for the tunnel2 tunnel destination 203.0.113.1 ! R1 underlay destination ! Remote tunnel endpoint tunnel mode gre ip tunnel path-mtu-discovery ! Let the tunnel try to discover a workable path MTU tunnel protection ipsec profile GRE-IPSEC-PROFILE ! This is the key line that turns GRE into GRE over IPsec

qos pre-classify is useful when QoS decisions must inspect the inner headers before GRE encapsulation and IPsec encryption hide them. Without it, classification may only see the outer tunnel traffic.

Firewall requirements matter. For GRE-only, permit IP protocol 47. For IPsec, make sure UDP/500 is allowed, permit ESP protocol 50 if NAT-T isn’t involved, and open UDP/4500 when NAT-T is in play. If a branch is behind NAT, expect IKE to begin on UDP/500 and then shift over to UDP/4500 once NAT gets detected.

A route-based IPsec alternative: VTI/FlexVPN

ENCOR expects you to know GRE over IPsec, but do not overlearn the wrong lesson. Cisco also gives you route-based IPsec without GRE by way of VTIs and FlexVPN. That gives you a routed interface you can run dynamic routing across, and you’re not dragging the extra GRE header around with you.

interface Tunnel10 ip address 10.20.20.1 255.255.255.252 ! VTI address on the route-based tunnel tunnel source 203.0.113.1 ! Underlay source for the VTI ! Use the underlay interface or address as the tunnel source ! Use the underlay address as the tunnel source tunnel destination 198.51.100.2 ! Remote VTI peer ! Remote GRE endpoint ! Point the tunnel at the remote underlay endpoint tunnel mode ipsec ipv4 ! This is the route-based IPsec tunnel mode tunnel protection ipsec profile VTI-PROFILE

As a general rule, I’d reach for VTI or FlexVPN when you want route-based encrypted connectivity without GRE overhead, use GRE over IPsec when GRE-specific behavior or an existing GRE design fits the problem better, and think DMVPN when you need hub-and-spoke scale with a lot less manual tunnel maintenance.oke scale with spoke-to-spoke behavior.

Running Routing Over the Tunnel

OSPF over GRE/IPsec is common because GRE gives you a multicast-friendly routed interface. OSPF isn't running directly through policy-based IPsec; it's running over the GRE tunnel that IPsec is protecting.

! R1
router ospf 10 network 10.10.10.0 0.0.0.3 area 0 network 172.16.1.0 0.0.0.255 area 0 interface Tunnel0 ip ospf network point-to-point ip ospf authentication message-digest ip ospf message-digest-key 1 md5 cisco ! R2
router ospf 10 network 10.10.10.0 0.0.0.3 area 0 network 172.16.2.0 0.0.0.255 area 0 interface Tunnel0 ip ospf network point-to-point ip ospf authentication message-digest ip ospf message-digest-key 1 md5 cisco

Set the OSPF network type to point-to-point on GRE tunnels to simplify adjacency behavior. If adjacency sticks in EXSTART or EXCHANGE, suspect MTU mismatch. Fix the real MTU if possible; ip ospf mtu-ignore can be a tactical workaround but should not be your first design choice.

EIGRP is also straightforward because multicast hellos work naturally across GRE. BGP is common in larger overlays when you want explicit policy control and predictable scaling.

! R1
router bgp 65001 neighbor 10.10.10.2 remote-as 65002 network 172.16.1.0 mask 255.255.255.0 ! R2
router bgp 65002 neighbor 10.10.10.1 remote-as 65001 network 172.16.2.0 mask 255.255.255.0

For faster failure detection, BFD over the tunnel can be paired with routing protocols where supported. That is often more responsive than waiting on GRE keepalives alone.

MTU, MSS, Fragmentation, and Performance

GRE plus IPsec adds overhead, and the exact amount depends on GRE options, ESP mode, cipher suite, NAT-T, and whether the underlay is IPv4 or IPv6. That is why ip mtu 1400 ! Match the tunnel MTU on both ends ! Lower the tunnel MTU to account for encapsulation overhead and ip tcp adjust-mss 1360 ! Keep MSS consistent on both ends ! Keep TCP from sending oversized segments into the tunnel are starting points, not universal values.

Operationally, the symptoms are classic: small pings work, large pings fail, application sessions hang on uploads, OSPF adjacencies behave strangely, or file transfers stall. PMTUD can help, but if ICMP is filtered, blackholing is common.

Validate with DF-bit testing:

ping 10.10.10.2 size 1476 df-bit
ping 172.16.2.1 size 1400 df-bit source 172.16.1.1

If large packets fail, tune tunnel MTU and MSS, then retest. Fragmentation behavior also matters: fragmentation before or after encryption affects efficiency and troubleshooting visibility. On IOS XE platforms, hardware crypto offload can dramatically improve throughput, but platform limits, licensing, and tunnel scale still matter.

Troubleshooting Workflow

The best troubleshooting method is layered and methodical. That is good news, because methodical methods work.

  1. Verify underlay reachability to the remote peer
  2. Verify route resolution to the tunnel destination is via the underlay
  3. Verify tunnel interface state
  4. Verify IKE SA establishment
  5. Verify IPsec SA establishment and packet counters
  6. Verify routing adjacencies and learned routes
  7. Verify end-to-end application traffic and MTU behavior
show interface tunnel0
show ip route
show ip cef 198.51.100.2 ! Confirm how the router is actually resolving the path
show crypto session
show crypto ikev2 sa
show crypto ikev2 sa detail
show crypto ipsec sa
show crypto ipsec sa peer 198.51.100.2
show ip ospf neighbor
show ip ospf interface tunnel0
show platform hardware qfp active feature ipsec data

If you are using IKEv1, use show crypto isakmp sa. On many IOS platforms, QM_IDLE is a common healthy established state for site-to-site IKEv1. For IKEv2, focus on whether the IKE SA is established and whether CHILD_SAs exist.

Common Symptoms and What They Usually Mean

  • Cannot ping remote public peer: usually an underlay problem such as routing, provider reachability, ACLs, NAT, or firewall policy. Check routing, path visibility, and filtering rules.
  • Tunnel down/down or up/down: usually a GRE or underlay issue such as wrong source or destination, recursive routing, or blocked protocol 47. Check tunnel interface status and forwarding resolution to the peer.
  • IKE SA absent: usually an IKE issue such as pre-shared key mismatch, proposal mismatch, identity mismatch, or blocked UDP/500. Check detailed IKE SA output.
  • IKE up, no IPsec SA: usually an IPsec negotiation issue such as transform mismatch, PFS mismatch, or policy mismatch. Check IPsec SA details.
  • IPsec SA up, encaps/decaps zero: usually a routing or traffic-selection problem. Traffic may not be using the tunnel, or the protected traffic definition may be wrong. Check routes and generate test traffic from the correct source.
  • Tunnel up, OSPF neighbor missing: usually a routing issue such as timer mismatch, authentication mismatch, MTU problems, passive-interface configuration, or a tunnel that is up but not passing traffic correctly. Check OSPF interface details.
  • Small traffic works, large traffic fails: usually an MTU or MSS issue caused by PMTUD failure, fragmentation problems, or oversized packets. Use DF-bit ping tests.

A compact real-world walkthrough looks like this: first ping the remote underlay IP. If that fails, stop and fix underlay routing or firewall policy. If it works, check Tunnel0 and confirm the route to the tunnel destination is not recursive. If the tunnel exists but no secure session forms, inspect IKE. If IKE is up but IPsec counters stay at zero, either traffic is not using the tunnel or the protected traffic definition is wrong. If counters move but applications fail, go straight to MTU, MSS, and routing protocol health.

Use debugs carefully: debug crypto ikev2 and debug crypto ipsec are powerful but noisy. In production, pair them with logging, timestamps, and a maintenance window.

Security and Design Best Practices

Prefer IKEv2 over IKEv1 when platform support and design allow. Use modern algorithms approved by your security policy. Avoid weak or legacy options where possible. Restrict permitted peers with infrastructure ACLs, protect the management plane, and log tunnel establishment and teardown events to centralized logging, monitoring, or telemetry systems.

Pre-shared keys are fine for small labs and small estates, but certificates become more attractive as peer count grows. Just remember that PKI is not free operationally. Plan trustpoints, enrollment, renewal, and revocation before you declare certificates more scalable.

For high availability, dual underlays and redundant tunnels require more than extra interfaces. You need convergence logic: dynamic routing metrics, floating statics, IP SLA tracking, DPD, and sometimes BFD. For segmented enterprises, VRF-aware GRE/IPsec and route-based VPNs matter. For modern migrations, also think about IPv6 underlays or dual-stack overlays.

ENCOR Exam Focus

What ENCOR expects you to know: GRE purpose and limitations, IPsec purpose and components, IKEv1 versus IKEv2, transport versus tunnel mode, policy-based versus route-based VPN concepts, GRE over IPsec use cases, VTI/FlexVPN awareness, DMVPN as an adjacent concept, MTU/MSS implications, and a basic verification workflow.

Common distractors: GRE is not encryption. IPsec does not automatically create a multicast-friendly routed interface in policy-based form. Tunnel up/up does not mean routing is healthy. IKE SA up does not guarantee IPsec data-plane success. Zero encaps/decaps usually means no matching traffic or bad routing.

Quick selection rules: use GRE when you need an overlay but not security; use policy-based IPsec for simple subnet encryption; use GRE over IPsec for a secure routed overlay; use VTI/FlexVPN when you want route-based IPsec without GRE; think DMVPN when you need scalable hub-and-spoke overlays.

Final cram list: GRE = overlay transport. IPsec = protection. GRE over IPsec = routed encrypted overlay. VTI = route-based IPsec without GRE. GRE-only needs protocol 47. IPsec needs UDP/500, ESP/50, and UDP/4500 with NAT-T. IKEv2 builds an IKE SA and then CHILD_SAs. On IKEv1, QM_IDLE is a common healthy state. MTU/MSS problems are common. Always verify underlay before crypto.

Conclusion

The clean way to remember the topic is this: GRE gives you a routed overlay, IPsec gives you security, and GRE over IPsec gives you both. But in modern Cisco networks, it is not the only answer. Route-based IPsec with VTI or FlexVPN can also run dynamic routing without GRE, and DMVPN extends the model for scale.

For the exam and for real operations, build in layers. Verify underlay reachability, then GRE, then IKE, then IPsec counters, then routing, then applications. That habit is what keeps tunnel work from turning into midnight guesswork.