The internet will happily carry packets between your sites — it just refuses to know anything about your private LANs. This lab builds the classic answer: GRE tunnels that make three routers think they share a cable, OSPF running over those tunnels as if they were physical, and IPsec wrapped around the outside so the ISP sees only ESP noise. All of it works in Packet Tracer.
Part 13 built one modern IKEv2 tunnel between two offices. This lab scales the idea into a real hub-and-spoke WAN — and adds the ingredient that changes everything: a routing protocol over the tunnels. Plain IPsec carries packets between subnets you enumerate by hand; GRE gives you a virtual interface, and anything with an interface can run OSPF. Add a branch subnet and nobody edits crypto ACLs — OSPF just learns it.
The lab's secret weapon is the ISP cloud in the middle: three routers that only know the public /30s. Your first end-to-end ping must fail — the internet doesn't route RFC1918 — and that failure is the lesson everything else builds on. Then GRE smuggles the private traffic through in public envelopes, and IPsec makes the envelopes opaque. Every command here is Packet Tracer 8.x-compatible (crypto maps, not the VTI profiles of part 13 — we'll flag the difference).
01
The ISP router(s) get the public /30s and nothing else — no routes to any 192.168 network, ever. Prove the problem exists before solving it.
# ISP router — three legs, three public /30s. No statics. No OSPF. Nothing. ISP(config)# interface GigabitEthernet0/0 ISP(config-if)# ip address 198.51.100.1 255.255.255.252 ← toward HQ ISP(config)# interface GigabitEthernet0/1 ISP(config-if)# ip address 203.0.113.1 255.255.255.252 ← toward BR1 ISP(config)# interface GigabitEthernet0/2 ISP(config-if)# ip address 192.0.2.1 255.255.255.252 ← toward BR2 # Each site: WAN address + a default toward the ISP (as any customer router) HQ(config)# interface GigabitEthernet0/0 HQ(config-if)# ip address 198.51.100.2 255.255.255.252 HQ(config)# ip route 0.0.0.0 0.0.0.0 198.51.100.1 # The moment of truth — public works, private cannot: HQ# ping 203.0.113.2 ← BR1's public WAN !!!!! Success rate is 100 percent HQ# ping 192.168.20.1 ← BR1's LAN ..... Success rate is 0 percent ← correct! The ISP has no route and would drop RFC1918 anyway
Most VPN labs cheat with a crossover cable between the two routers, and students walk away never having seen the actual constraint: the underlay routes only what it knows. With a real cloud in the middle, every later failure gets diagnosed properly — "is this an underlay problem (can the tunnel endpoints reach each other?) or an overlay problem (is the tunnel/OSPF broken?)". That two-layer question is the whole troubleshooting model for VPNs, SD-WAN, and every overlay technology you'll ever touch.
02
A tunnel interface has a source (my public IP), a destination (your public IP), and its own private address. Packets entering it get wrapped in a public envelope the ISP can route.
HQ(config)# interface Tunnel10 HQ(config-if)# ip address 172.16.0.1 255.255.255.252 HQ(config-if)# tunnel source GigabitEthernet0/0 HQ(config-if)# tunnel destination 203.0.113.2 HQ(config-if)# ip mtu 1400 HQ(config-if)# ip tcp adjust-mss 1360 BR1(config)# interface Tunnel10 BR1(config-if)# ip address 172.16.0.2 255.255.255.252 BR1(config-if)# tunnel source GigabitEthernet0/0 BR1(config-if)# tunnel destination 198.51.100.2 BR1(config-if)# ip mtu 1400 BR1(config-if)# ip tcp adjust-mss 1360 # The virtual cable is up — ping across it: HQ# ping 172.16.0.2 !!!!! Success rate is 100 percent # The ISP carried that ping — as unicast between two PUBLIC addresses, # with the private packet hidden inside. That's the entire GRE trick.
GRE steals 24 bytes and IPsec will take ~58 more; a full-size 1500-byte packet no longer fits and gets fragmented or — with DF set, which all modern TCP sets — silently dropped. The classic symptom: ping works, SSH works, but HTTPS pages hang and file copies stall at 0%. Small packets fit, full segments don't. ip mtu 1400 + ip tcp adjust-mss 1360 on every tunnel interface, both ends prevents the entire symptom class. When any overlay "works but big things hang", MTU is guilty until proven innocent.
03
Here's the payoff for choosing GRE: the tunnels are interfaces, so OSPF runs on them like on any cable. The branches learn each other's subnets with zero enumeration.
HQ(config)# router ospf 1 HQ(config-router)# router-id 10.10.10.10 HQ(config-router)# passive-interface GigabitEthernet0/1 ← the LAN HQ(config-router)# network 172.16.0.0 0.0.0.7 area 0 ← both tunnels HQ(config-router)# network 192.168.10.0 0.0.0.255 area 0 BR1(config)# router ospf 1 BR1(config-router)# router-id 20.20.20.20 BR1(config-router)# passive-interface GigabitEthernet0/1 BR1(config-router)# network 172.16.0.0 0.0.0.3 area 0 BR1(config-router)# network 192.168.20.0 0.0.0.255 area 0 # NEVER put the WAN /30s or the default route into OSPF here — # the underlay must stay ignorant of the overlay (see gotcha below). BR1# show ip route ospf O 192.168.10.0/24 [110/1001] via 172.16.0.1, 00:01:12, Tunnel10 O 192.168.30.0/24 [110/2001] via 172.16.0.1, 00:01:02, Tunnel10 ← BR2's LAN, via the hub BR1# ping 192.168.30.1 source 192.168.20.1 !!!!! ← branch-to-branch, hairpinned through HQ. The full WAN works.
If OSPF ever learns a route to the tunnel destination itself (BR1's public 203.0.113.2) through the tunnel, the router tries to deliver the tunnel's envelopes into the tunnel — and IOS tears the interface down with %TUN-5-RECURDOWN: Tunnel10 temporarily disabled due to recursive routing. The tunnel flaps forever: down → route withdrawn → up → route relearned → down. The rule that prevents it: tunnel endpoints are reached only via the underlay (the static default), and the underlay's prefixes never enter the overlay's routing protocol. If you ever see RECURDOWN, you advertised something you shouldn't have.
04
GRE is a clear envelope — the ISP can read every LAN packet inside. An IPsec transform in transport mode encrypts exactly the GRE stream between each pair of public endpoints.
# Phase 1 — identical policy both ends HQ(config)# crypto isakmp policy 10 HQ(config-isakmp)# encryption aes 256 HQ(config-isakmp)# hash sha HQ(config-isakmp)# authentication pre-share HQ(config-isakmp)# group 5 HQ(config)# crypto isakmp key N0ctis-Lab-Key address 203.0.113.2 # Phase 2 — transport mode: we're only protecting router-to-router GRE HQ(config)# crypto ipsec transform-set TS-GRE esp-aes 256 esp-sha-hmac HQ(cfg-crypto-trans)# mode transport # Interesting traffic = the GRE stream itself (protocol 47) HQ(config)# ip access-list extended VPN-BR1 HQ(config-ext-nacl)# permit gre host 198.51.100.2 host 203.0.113.2 HQ(config)# crypto map CMAP 10 ipsec-isakmp HQ(config-crypto-map)# set peer 203.0.113.2 HQ(config-crypto-map)# set transform-set TS-GRE HQ(config-crypto-map)# match address VPN-BR1 # (map entry 20 = the same for BR2, then apply once:) HQ(config)# interface GigabitEthernet0/0 HQ(config-if)# crypto map CMAP # Mirror everything on BR1 (peer/ACL reversed), then verify counters move: HQ# show crypto ipsec sa | include pkts #pkts encaps: 214, #pkts encrypt: 214 #pkts decaps: 209, #pkts decrypt: 209 ← OSPF hellos being encrypted, live
On real IOS/IOS-XE you'd skip crypto maps entirely: build an crypto ipsec profile and put tunnel protection ipsec profile X straight on the tunnel interface — the part-13 approach, extended per tunnel. Packet Tracer doesn't support tunnel protection, so this lab uses the older crypto-map-matching-GRE pattern, which is also exactly what you'll find on thousands of surviving production routers. Learning both idioms means you can read old configs and write modern ones. (In PT, remember the 2911 needs the security license: license boot module c2900 technology-package securityk9, accept, save, reload.)
05
Every fault in an encrypted overlay is at one of four layers: underlay reachability, crypto, tunnel, routing. Test them in that order, always.
| Command | Layer it proves |
|---|---|
| ping <peer public IP> | 1 — Underlay: can the endpoints even reach each other? |
| show crypto isakmp sa | 2 — Phase 1 up? State must be QM_IDLE / ACTIVE. |
| show crypto ipsec sa | 2 — Phase 2: encaps/decaps counters must both climb. |
| show interface Tunnel10 | 3 — Tunnel up/up? (up/down = source/destination unreachable) |
| show ip ospf neighbor | 4 — Overlay routing: FULL across each tunnel. |
| show ip route ospf | 4 — Remote LANs present, next-hop = tunnel address. |
The order matters because each layer depends on the one before: OSPF can't form without the tunnel, the tunnel carries nothing if crypto eats the packets, and crypto can't negotiate without underlay reachability. When branch traffic dies at 3 a.m., start at layer 1 and climb — never start at the layer you suspect.
Start a continuous ping BR1-LAN → BR2-LAN, then delete the HQ–ISP cable. Everything dies — hub-and-spoke's honest weakness, both tunnels transit HQ. Reconnect and watch the layers rebuild in dependency order: ISAKMP renegotiates, tunnels return to up/up, OSPF re-FULLs, pings resume — about 40 seconds in PT, dominated by OSPF's dead-interval. Then ask the design question this drill teaches: what would it take for BR1→BR2 to survive an HQ failure? (A BR1–BR2 tunnel — turning the hub-and-spoke into a triangle. In the real world at scale: DMVPN or SD-WAN, both of which are exactly this lab's pattern with the tunnel-building automated.)
06
RouterOS builds the identical design — a mixed fleet interoperates fine, and we run several.
| This lab (Cisco) | MikroTik / RouterOS |
|---|---|
| interface Tunnel10 (GRE) | /interface gre add remote-address=… |
| ip mtu 1400 + adjust-mss | mtu= on the GRE interface + mangle change-mss rule |
| OSPF over tunnels | /routing ospf interface-template on the gre interfaces |
| crypto map + isakmp key | /ip ipsec policy + peer + identity (or ipsec-secret= right on the GRE interface — one-liner) |
| show crypto ipsec sa | /ip ipsec installed-sa print (watch the byte counters) |
| DMVPN (the scaled version) | No direct equivalent — WireGuard mesh or ZeroTier fill the niche |
Takeaways
tunnel protection with an IPsec profile. Know both.NOCTIS builds encrypted multi-site WANs on Cisco and MikroTik — with dynamic routing over the tunnels, MTU done right the first time, and failover we've actually tested by pulling the cable.
Book a Discovery Call →