WAN Architectures & IPsec VPNs

WAN options

WAN choices on CCNA: MPLS Layer 3 VPN, Internet + VPN (IPsec/DMVPN themes), Metro Ethernet, and broadband (cable/DSL/fiber handoff). Each trades cost, SLA, and how much routing the provider owns. Provider-managed MPLS shifts routing operations toward the PE; Internet VPN keeps operations on your CE.

Private WAN (MPLS/Metro) usually offers better SLA and simpler addressing; Internet VPN is cheaper and ubiquitous but pushes security and performance variance onto you. Metro Ethernet feels like a long LAN handoff; broadband feels like a consumer Internet edge.

Pick from requirements: number of sites, need for any-to-any, encryption mandate, budget, and whether you can run BGP with a provider. List mandatory encryption, site count, and budget before you favor any one option. There is no universal “best WAN.”

Exam trap: “Internet is always worse” is false when the stem emphasizes cost and rapid provisioning—VPN over Internet is a valid architecture answer.

MPLS glance

MPLS in provider networks forwards labels instead of doing IP lookup at every hop in the core. For enterprises, the CCNA view is usually MPLS L3VPN: the provider routes your VRFs between sites; you peer CE–PE, often with BGP. CE–PE routing may be eBGP, OSPF, or static depending on the handoff.

You do not configure the provider’s P routers. You care about CE routing, QoS markings the provider honors, and the SLA. Traffic between your sites stays in your VRF logically isolated from other customers. VRFs separate customers; your prefixes should not leak across VRFs.

Any-to-any connectivity is natural in MPLS VPNs without building a full mesh of tunnels yourself. That is a major design contrast with hub-and-spoke IPsec. QoS markings may be honored only within contracted classes—map carefully.

Exam trap: MPLS is not “replacing IP on your LAN.” It is a WAN transport/provider technology; campus still runs Ethernet/IP.

Internet VPN

Site-to-site IPsec VPN over the Internet encrypts traffic between gateways. You get reachability everywhere the Internet reaches, with confidentiality the MPLS VRF model does not inherently provide on its own. Interesting traffic definitions and tunnel IKE state are first checks when LANs cannot talk.

Design issues: NAT traversal, dynamic peer IPs on broadband, MTU/fragmentation, and routing over tunnels (static, BGP, or IGP over tunnel interfaces). Hub-and-spoke is common; full mesh scales poorly without help. MTU/TCP MSS clamps avoid silent black holes on IPsec overlays.

Performance varies with Internet paths. Use SLA probes and dual ISPs if downtime is expensive. Dual ISP designs need clear primary/backup routing. The VPN does not remove the need for local Internet edge security (firewall).

Exam trap: Internet VPN without encryption keywords is just “Internet.” The security answer needs IPsec/VPN, not a naked public path for private subnets. Troubleshoot underlay public reachability before overlay LAN routes.

Site-to-site and remote access

Objective 4.5 asks you to describe IPsec, not to build a crypto map. Site-to-site IPsec peers are gateways: a router or firewall at each site. They protect traffic between the LANs behind them. The tunnel is typically up whether or not a user is logged in, and the users do not run a VPN client. Either gateway can initiate. You troubleshoot peer reachability, IKE, and the traffic selector or the route that points into the tunnel.

Remote access is the other model. The user’s laptop or phone runs the client and initiates the tunnel to a concentrator. The user authenticates, often with a password, a certificate, or both, and the concentrator commonly checks those credentials with RADIUS. The client receives a virtual address and a policy about which subnets are inside the tunnel. Branch routers are not the peers in that flow. If the laptop is off, there is no tunnel.

Exam trap: “the branch firewall builds a permanent tunnel to headquarters” is site-to-site. “The employee opens a client and signs in” is remote access. Both can use IPsec. The stem’s answer turns on who initiates and what is being protected: LAN-to-LAN, or a single host into the network.

Tunnel mode and transport mode

Tunnel mode wraps the original IP packet in a new outer IP header. The outer addresses are the VPN gateways. The inner addresses are the real hosts, and they stay hidden from the underlay. This is the mode site-to-site designs use, because the two private LANs are not directly routable on the Internet and the gateways are the IPsec peers. A capture on the WAN shows the gateway addresses and the IPsec protocol, not the payroll server’s address.

Transport mode inserts the IPsec header between the original IP header and the transport header. The original source and destination stay visible, and they must be the IPsec peers. That fits host-to-host protection. It does not fit two private subnets behind a pair of firewalls, because those firewalls are not the addresses in the original packet. You would be asking the underlay to route private addresses.

Exam trap: “hide the original source and destination between two firewalls” is tunnel mode. “Protect this TCP session between two hosts that already address each other” is transport mode. The mode is independent of the marketing name of the VPN product. Read who the outer addresses have to be.

ESP, AH, and IKE

ESP, protocol 50, encrypts the payload and can authenticate it. When the requirement is confidentiality, ESP is the protocol you name. AH, protocol 51, authenticates the packet, including parts of the IP header, and does not encrypt. AH is the wrong answer on any stem that says the payload must be unreadable. Both protocols can be used in tunnel mode or transport mode. The mode is how the packet is wrapped. The protocol is what protection you get.

IKE negotiates the security associations those protocols use: algorithms, keys, and which traffic matches. IKEv2 is the current form you should recognize. IKE runs on UDP 500. When a NAT sits between the peers, NAT Traversal encapsulates ESP in UDP 4500, because a NAT device would otherwise break the ESP header and because AH’s coverage of the IP header does not survive translation. A firewall in the path has to permit those UDP ports or the data-plane protocols, or the tunnel never establishes. You can describe that list without configuring a transform set.

Exam trap: confidentiality is ESP. Integrity without encryption is AH. UDP 500 and UDP 4500 are the control plane that builds the SA, not a substitute for ESP. A stem that only opens UDP 500 and then expects encrypted user traffic still needs the negotiated ESP, or NAT-T on 4500, to carry the payload.

DMVPN glance

DMVPN builds multipoint GRE with IPsec and NHRP so spokes can discover dynamic spoke-to-spoke tunnels instead of hairpinning all traffic through a hub forever. NHRP resolves spoke addresses dynamically so the hub is not a permanent hairpin for spoke–spoke flows.

CCNA depth is conceptual: hub has a stable address; spokes register; NHRP resolves mappings; traffic can go spoke–spoke dynamically. Phases differ in how shortcuts form; you need the multipoint + dynamic mapping idea, not every phase quirk.

Compared with classic static IPsec crypto maps to every peer, DMVPN reduces configuration sprawl for large branch counts. IPsec protects the GRE overlay; without crypto, mGRE alone is not a secure Internet design.

Exam trap: DMVPN is still over an underlay (often Internet). It is an overlay design pattern, not a replacement ISP product like MPLS. Two-site static IPsec is simpler—use DMVPN when spoke scale demands it.

Broadband

Broadband handoffs (cable modem, DSL, FTTH ONT) deliver Internet access to small branches and home workers. The CE router usually gets a DHCP or PPPoE address and NATs users or builds a VPN back to HQ. PPPoE auth, DHCP WAN, and CGNAT all change how you build stable VPN peers.

Expect dynamic public IPs, CGNAT on some providers, and asymmetrical upload. Design VPNs for dynamic peers (FQDN, DMVPN, or always-on client VPN) when the address changes. Upload caps hurt voice and backup jobs—measure both directions.

Treat broadband as an underlay with weak SLA. Use it as primary only when cost dominates; otherwise as backup beside MPLS/Metro. Use broadband as backup beside a private WAN when SLA matters.

Exam trap: broadband is not Metro Ethernet. Metro is typically a carrier Ethernet service with different SLA and handoff assumptions—do not confuse a copper Ethernet jack with Metro Ethernet guarantees.

Metro Ethernet

Metro Ethernet delivers Ethernet handoffs between sites in a metro area—E-Line (point-to-point) or E-LAN (multipoint) themes. Your routers/switches see Ethernet; the provider network is opaque. Know which topology the stem describes before you pick features.

You may run your own L2 or L3 across the service. Stretching L2 across Metro E recreates campus failure-domain problems—prefer L3 at the handoff unless there is a strong reason. Prefer routing on CE routers over stretching STP across the metro cloud.

Bandwidth upgrades are often simpler than legacy TDM. Still negotiate SLA, MTU (jumbo needs), and whether the service is shared or committed. Ask the provider about MTU so IPsec designs do not fragment painfully.

Exam trap: Metro Ethernet does not automatically encrypt. Privacy is provider isolation plus whatever IPsec you add.

SLA themes

SLA themes: availability percentage, latency, jitter, packet loss, mean time to repair. MPLS and managed Metro often publish clearer SLAs than raw Internet. Voice budgets often cite latency/jitter/loss caps; map those to transport selection.

Map applications to needs: voice cares about jitter/loss; bulk backup cares about throughput windows; interactive apps care about latency. Do not buy a premium SLA for traffic that only runs nightly. Repair-time commitments matter as much as availability decimals for branch outages.

Measure with IP SLA / twamp-style probes and provider reports. An SLA without measurement is a brochure. Congestion without an SLA violation still hurts apps—capacity and SLA are cousins.

Exam trap: five-nines availability does not mean zero packet loss during congestion—read what the SLA actually guarantees.

Underlay overlay

Underlay is the reachable transport network (Internet, MPLS, Metro). Overlay is the virtual topology you build on top (IPsec tunnels, DMVPN, SD-WAN fabrics) with its own routing and policies. Underlay examples include ISP routed Internet and MPLS PE reachability; overlays include IPsec VTI/GRE and DMVPN.

Overlays let you keep private addressing and encryption independent of underlay changes. If the underlay path changes but tunnel endpoints stay reachable, the overlay stays up.

Troubleshooting splits: underlay ping/traceroute to peer public/PE addresses first; then overlay tunnel state and routes. Mixing the two layers in one mental model causes long outages. Debug peer public IP ping before debugging OSPF over a tunnel.

Exam trap: fixing OSPF on the LAN will not bring up a down IPsec peer if the underlay path to the public IP is dead.

Design choose transport

Decision cues: many sites + provider-managed any-to-any → MPLS L3VPN. Strong encryption + cheap circuits → Internet VPN/DMVPN. Metro campuses → Metro E. Tiny branch → broadband + VPN. Any-to-any with provider routing → MPLS; cheap encrypted → Internet VPN.

Hybrid is normal: MPLS primary, Internet VPN backup, or dual Internet with SD-WAN themes. Policy routing or dynamic routing decides failover. Hybrid designs need explicit failover tests for both underlays.

Write constraints first: budget, encryption mandate, multicast needs, IPv6, operational skill. Then pick the transport that fits—not the trendiest acronym. Multicast or voice requirements may eliminate some cheap Internet-only answers.

Exam trap: choosing MPLS when the stem says “cheapest possible encrypted connectivity between two sites” (Internet VPN wins).

Exam compare

Compare on axes: cost, SLA, encryption, any-to-any ease, who runs routing. MPLS: higher cost, strong SLA, provider routing, isolation via VRF. Internet VPN: lower cost, variable SLA, you encrypt, you route overlays. Build a 2×2 in your notes: cost vs SLA, and encryption vs provider isolation.

Metro E: Ethernet simplicity, metro distance, encryption optional. Broadband: consumer-grade underlay, VPN almost mandatory for private use. Broadband and Metro E both may use Ethernet jacks—SLA and addressing differ.

DMVPN vs static IPsec: DMVPN scales spoke config; static maps are fine for two sites. Do not invent DMVPN for a two-router lab stem unless asked. DMVPN reduces config blast radius versus per-spoke crypto maps as site count grows.

Exam trap: “most secure WAN” without defining threat model. Encryption and provider isolation answer different threats.

Lab mental models

Lab model 1: two routers + GRE/IPsec tunnel over a simulated Internet router; run a /24 on each LAN and route through the tunnel. Break the underlay path and watch the overlay die. Break the Internet router’s path and confirm the tunnel drops before you touch LAN routes.

Lab model 2: three sites hub-and-spoke; compare hairpinned flows vs a sketch of DMVPN spoke-spoke. Even without full DMVPN config, draw NHRP resolution on paper. Draw spoke–spoke traffic for DMVPN even if the lab only builds hub-and-spoke IPsec.

Lab model 3: CE–PE BGP toward a “provider” router advertising VPN routes—stand-in for MPLS L3VPN from the CE view. CE–PE eBGP labbing teaches the MPLS customer view without a full P-router core.

Exam trap: lab success on tunnel up/up without testing interesting traffic. Always send packets between LANs and check `show ip route` for tunnel next hops.

Security on WAN

Encrypt overlays that cross untrusted underlays. Authenticate peers (PSKs/certificates). Filter what enters the campus from WAN with ACLs/firewall zones—VPN is not automatic full trust. A VPN peer compromise should not mean full LAN trust.

Management plane to branch routers should not rely on clear-text Telnet across the Internet. Prefer SSH inside the overlay or out-of-band. Prefer management over the overlay or OOB—not clear-text Telnet to public CE addresses.

Provider VRF isolation ≠ end-to-end confidentiality from the provider itself. If the threat includes the carrier, add IPsec even on MPLS. IPsec over MPLS is valid when the threat includes the provider path.

Exam trap: assuming MPLS needs no security controls at CE. Still harden CE, route only intended prefixes, and monitor—SSH, ACL, logging, unused services off.

Ops monitoring

Monitor underlay reachability to peers/PEs, tunnel/IPsec state, overlay routes, and application SLAs. SNMP/telemetry on CE WAN interfaces catches utilization before users do. Track CE WAN utilization, IPsec status, and BGP/OSPF overlay sessions as separate metrics.

Alert on tunnel flaps and BGP VPN session drops. Correlate with provider tickets—many “app outages” are WAN underlay brownouts. Flap storms often correlate with ISP maintenance—match tickets to timestamps.

Keep runbooks: who owns MPLS tickets vs Internet ISP vs your crypto gear. Split-brain ownership delays repair. Clarify which vendor owns MPLS versus broadband versus your crypto endpoints.

Exam trap: monitoring only LAN switches when the symptom is inter-site. Always include CE WAN interface and peer status—LAN-only NOC views miss inter-site root causes.

Checklist

WAN options named with one use case each. MPLS CE–PE glance clear. Internet VPN and DMVPN distinguished. Broadband vs Metro E separated with SLA differences stated.

SLA metrics listed. Underlay/overlay troubleshooting order stated. Transport choice tied to requirements. Security: encrypt untrusted, filter CE, harden management.

Lab mental model practiced with real interesting traffic. Ops monitoring includes CE/peer state. Exam compare axes memorized: cost, SLA, encryption, any-to-any, ownership.

Exam trap check: can you pick a transport from a stem that only gives cost + encryption + site count?