2.2.b GRE and IPsec tunneling

What this objective tests

This is a configure-and-verify objective. The exam wants you to build a Generic Routing Encapsulation (GRE) tunnel, verify it, and explain how IPsec protects it.

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

• GRE gives encapsulation. It creates a routed tunnel interface.
• IPsec gives encryption and authentication.
• GRE over IPsec gives a routable tunnel that is also protected.

Note: GRE does not encrypt anything by itself. If a question needs confidentiality, the answer must include IPsec.

GRE concepts

GRE wraps an original packet inside a new IP packet.

Inner packet:  10.1.1.10 -> 10.2.2.10
Outer packet:  198.51.100.1 -> 198.51.100.2 (protocol 47, GRE)

The underlay only routes between the tunnel endpoints. It never sees the private prefixes. GRE can also carry multicast and routing protocol traffic, which classic IPsec policy tunnels do not carry naturally.

IPsec concepts

IPsec protects IP traffic with confidentiality, integrity, authentication, and anti-replay protection. It works in two phases:

• IKE phase 1: builds the authenticated management channel between peers.
• IKE phase 2: negotiates the IPsec security associations (SAs) that protect data.

With GRE over IPsec, IPsec protects the GRE packets between the public tunnel endpoints.

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

Example: GRE tunnel between R1 and R2

Scenario: two sites connect over a WAN. R1 has public address 198.51.100.1 and LAN 10.1.1.0/24. R2 has public address 198.51.100.2 and LAN 10.2.2.0/24. The tunnel uses 172.16.12.0/30.

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 <-------> Tunnel0 172.16.12.2/30

R1 configuration:

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

R2 configuration mirrors R1. The tunnel source is Gi0/0 (198.51.100.2). The tunnel destination is 198.51.100.1. The tunnel IP is 172.16.12.2. The static route points 10.1.1.0/24 to 172.16.12.1.

Note the route targets. The route for the remote LAN points to the remote tunnel IP, not the WAN IP.

Expected show interfaces tunnel0 output on R1:

R1# show interfaces tunnel0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Description: GRE to R2
  Internet address is 172.16.12.1/30
  MTU 17868 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel linestate evaluation up
  Tunnel source 198.51.100.1 (GigabitEthernet0/0), destination 198.51.100.2
  Tunnel protocol/transport GRE/IP

Check three things: the interface is up/up, the source and destination are correct, and the protocol is GRE/IP.

Expected end-to-end test:

R1# ping 10.2.2.1 source 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5)

Adding IPsec protection

Modern IOS XE protects the tunnel directly with an IPsec profile. This is route-based IPsec: any traffic that enters Tunnel0 gets protected.

R1 additions:

crypto ikev2 proposal ENCOR-PROP
 encryption aes-cbc-256
 integrity sha256
 group 14
!
crypto ikev2 policy ENCOR-POLICY
 proposal ENCOR-PROP
!
crypto ikev2 keyring ENCOR-KEYS
 peer R2
  address 198.51.100.2
  pre-shared-key CcnpLabKey
!
crypto ikev2 profile ENCOR-IKEV2
 match identity remote address 198.51.100.2 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local ENCOR-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
!
interface Tunnel0
 tunnel protection ipsec profile GRE-PROTECT

R2 uses the mirror image: peer address 198.51.100.1, same pre-shared key, same transform set, same profile name. mode transport works here because the GRE header already provides the outer IP addresses.

Note: Older labs use a legacy crypto map with an ACL that matches GRE between the public endpoints, applied on the WAN interface. The selector is permit gre host 198.51.100.1 host 198.51.100.2. Recognize the pattern. Do not treat one syntax as the only correct one.

Expected IPsec verification output:

R1# show crypto ikev2 sa
 IPv4 Crypto IKEv2  SA
Tunnel-id Local          Remote         fvrf/ivrf   Status
1         198.51.100.1/500 198.51.100.2/500 none/none READY
      Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:14

R1# show crypto ipsec sa | include pkts
    #pkts encaps: 45, #pkts encrypt: 45, #pkts digest: 45
    #pkts decaps: 45, #pkts decrypt: 45, #pkts verify: 45

The IKEv2 SA must show READY. The encaps and decaps counters must increase when traffic flows. If encaps increases but decaps does not, check the return path and the peer policy. If neither increases, check the tunnel route and the profile binding.

Lab: GRE over IPsec site to site

Goal

Build a protected tunnel between two sites and prove each layer works.

Topology

LAN-A 10.1.1.0/24 -- R1 Gi0/1
R1 Gi0/0 198.51.100.1/30 == WAN == 198.51.100.2/30 Gi0/0 R2
R2 Gi0/1 -- LAN-B 10.2.2.0/24
Tunnel0: 172.16.12.1/30 (R1) to 172.16.12.2/30 (R2)

Do these steps:

1. Configure the WAN and LAN interfaces on R1 and R2 from the example above.
2. Add a default or specific route so each router reaches the remote public address.
3. Verify underlay reachability with ping 198.51.100.2 source 198.51.100.1.
4. Configure Tunnel0 on both routers from the example above.
5. Verify the tunnel with show interfaces tunnel0.
6. Ping 10.2.2.1 from R1 with source 10.1.1.1.
7. Add the IKEv2 and IPsec profile config from the example above to both routers.
8. Send traffic again across the tunnel.
9. Run show crypto ikev2 sa and confirm the SA is READY.
10. Run show crypto ipsec sa and confirm encaps and decaps counters increase.
11. Run ping 10.2.2.1 size 1400 df-bit source 10.1.1.1 to confirm MTU is safe.

Expected results:

• Step 3 succeeds before any tunnel config exists. If it fails, fix the underlay first.
• Step 5 shows Tunnel0 up/up with the correct source and destination.
• Steps 9 and 10 show a READY SA and matching counters.
• Step 11 succeeds without fragmentation errors.

MTU and MSS

Tunnels add headers. GRE adds 24 bytes. IPsec adds more. The outer packet is larger than the inner packet. If the path MTU is too small, large packets fragment or fail.

That is why the example uses these commands:

interface Tunnel0
 ip mtu 1400
 ip tcp adjust-mss 1360

The exact values depend on the environment. The idea matters: leave room for encapsulation overhead. Test with a large ping and the DF bit set.

Troubleshooting checklist

1. Can each router reach the remote tunnel destination? Check with show ip route 198.51.100.2 and an underlay ping.
2. Are the tunnel source and destination correct? Check with show run interface tunnel0.
3. Is there a route for the remote LAN through the tunnel? Check with show ip route 10.2.2.0.
4. Are the SAs up and counters increasing? Check with show crypto ikev2 sa and show crypto ipsec sa.
5. Is MTU causing partial failures? Test with ping 10.2.2.1 size 1400 df-bit.

Exam traps

• GRE by itself is not encryption.
• IPsec protects traffic. It does not create a routed interface like GRE does.
• The underlay must route between tunnel endpoints before GRE or IPsec works.
• Routes for remote private networks point to the tunnel IP, not the public WAN IP.
• A tunnel can show up/up while routes, IPsec, or MTU still break traffic.
• Encaps without decaps means a return path or peer problem, not a local send problem.

Pass check

You are ready for this objective when you can do these things:

• Configure a GRE tunnel with a concrete source, destination, and tunnel IP.
• Read show interfaces tunnel0 and confirm the three key facts.
• Explain the layer order of GRE over IPsec.
• Bind an IPsec profile to a tunnel and verify the SAs.
• Read encaps and decaps counters and localize the failure.
• Explain why ip mtu and ip tcp adjust-mss belong on tunnels.