Tunneling - Learning Module

Loading content...

0/228

Tunneling Applications: Real-World Deployments

Tunneling in Production

Tunneling isn't an academic exercise—it's the foundation of virtually every enterprise network, cloud connection, and secure communication you use daily. When you connect to your company's resources from home, your traffic travels through a VPN tunnel. When data centers replicate across continents, tunneling bridges them. When cloud providers offer private connectivity, tunneling makes it possible.

This page explores how the tunneling concepts we've covered are applied in real-world scenarios. From the site-to-site VPN connecting branch offices to the software-defined overlays powering modern data centers, tunneling enables the flexible, secure, and scalable networks that modern business demands.

What You Will Learn

By the end of this page, you will understand: site-to-site VPN architectures and topologies; remote access VPN designs for mobile workforces; data center interconnect solutions using tunneling; cloud connectivity options (AWS, Azure, GCP); software-defined networking overlays; service provider tunneling for customer isolation; and emerging tunneling technologies.

Site-to-Site VPN

Site-to-site VPNs connect entire networks across geographic distances, creating unified enterprise infrastructure over the public Internet. These are the most fundamental tunneling application—enabling branch offices, data centers, and partner networks to communicate securely.

Architecture components:

1. VPN Gateways Dedicated devices (firewalls, routers, VPN concentrators) at each site perform tunnel establishment, encryption/decryption, and routing.

2. Tunnel Configuration IPSec policies, GRE tunnels, or VTI interfaces define the endpoints, security parameters, and traffic selectors.

3. Routing Integration Dynamic routing protocols (OSPF, BGP) or static routes direct traffic into the tunnels. Sites appear as directly connected subnets.

site-to-site-topology.txt
SITE-TO-SITE VPN TOPOLOGIES
═══════════════════════════════════════════════════════════════════════════
 
TOPOLOGY 1: POINT-TO-POINT (Simple)
────────────────────────────────────
 
     Site A                                          Site B
  ┌──────────┐                                    ┌──────────┐
  │ 10.1.0.0 │          IPSec Tunnel              │ 10.2.0.0 │
  │   /24    ├════════════════════════════════════┤   /24    │
  └──────────┘                                    └──────────┘
 
  • Single tunnel between two sites
  • Simplest configuration
  • Common for small businesses
 
 
TOPOLOGY 2: HUB-AND-SPOKE (Centralized)
───────────────────────────────────────
 
                        ┌──────────┐
                   ┌────┤ Branch 1 │
                   │    │10.1.0.0  │
                   │    └──────────┘
  ┌──────────┐     │
  │   HQ     │═════╪════┌──────────┐
  │10.0.0.0  │     │    │ Branch 2 │
  │ (Hub)    │═════╪════│10.2.0.0  │
  └──────────┘     │    └──────────┘
                   │
                   │    ┌──────────┐
                   └────┤ Branch 3 │
                        │10.3.0.0  │
                        └──────────┘
 
  • Central HQ connects to all branches
  • Branch-to-branch traffic routes through HQ
  • Easier to manage (N tunnels, not N×(N-1)/2)
  • HQ is single point of failure
 
 
TOPOLOGY 3: FULL MESH (Maximum Connectivity)
────────────────────────────────────────────
 
         Site A ═══════════════ Site B
           ║ ╲                   ╱ ║
           ║   ╲               ╱   ║
           ║     ╲           ╱     ║
           ║       ╲       ╱       ║
           ║         ╲   ╱         ║
           ║           ╳           ║
           ║         ╱   ╲         ║
           ║       ╱       ╲       ║
           ║     ╱           ╲     ║
           ║   ╱               ╲   ║
           ║ ╱                   ╲ ║
         Site C ═══════════════ Site D
 
  • Every site connects to every other site
  • Optimal path between any two sites
  • Complex: N sites = N×(N-1)/2 tunnels
  • 4 sites = 6 tunnels; 10 sites = 45 tunnels
 
 
TOPOLOGY 4: PARTIAL MESH (Hybrid)
─────────────────────────────────
 
         Regional HQ 1 ═══════ Regional HQ 2
             ╱│╲                   ╱│╲
            ╱ │ ╲                 ╱ │ ╲
           ╱  │  ╲               ╱  │  ╲
       Branch Branch Branch  Branch Branch Branch
         1A    1B    1C        2A    2B    2C
 
  • Hierarchical structure
  • Regional hubs with full mesh at tier 1
  • Spoke sites connect to regional hub
  • Balance of efficiency and resilience

Site-to-Site VPN Technology Options
Technology	Pros	Cons	Best For
IPSec Tunnel Mode	Strong security, widely supported	No multicast, complex policy	Policy-based VPN
GRE over IPSec	Multicast, routing protocols	Higher overhead	Dynamic routing environments
VTI (Virtual Tunnel Interface)	Route-based, clean config	Not universal support	Modern deployments
DMVPN (Dynamic Multipoint VPN)	Dynamic spoke-to-spoke	Cisco-specific	Large hub-spoke networks

DMVPN for Scale

Cisco's DMVPN (Dynamic Multipoint VPN) combines mGRE (multipoint GRE) with NHRP (Next Hop Resolution Protocol) to dynamically establish spoke-to-spoke tunnels on demand. This provides full-mesh reachability with hub-and-spoke simplicity—spokes only configure the hub, but can build direct tunnels to each other when needed.

Remote Access VPN

Remote access VPNs connect individual users to enterprise networks from any location. Unlike site-to-site VPNs with fixed endpoints, remote access must handle:

Dynamic client IP addresses (hotel WiFi, home networks)
NAT traversal (clients behind consumer routers)
User authentication (not just device authentication)
Client provisioning (every user device needs software)

Common remote access VPN protocols:

Remote Access VPN Technologies
Protocol	Layer	Authentication	Platform Support
IKEv2/IPSec	L3	EAP, Certificates, PSK	Windows, macOS, iOS, Android, Linux
L2TP/IPSec	L2	PAP, CHAP, MS-CHAPv2	Windows, macOS, iOS (legacy)
OpenVPN	L3	Certificates, Username/Password	All platforms (needs client)
WireGuard	L3	Public key cryptography	All platforms, kernel-level on Linux
SSL VPN (Portal)	L7	Web-based, SAML, MFA	Browser-only, limited access

Split tunneling vs full tunneling:

Full Tunnel (All Traffic)

All client traffic routes through VPN
Corporate can inspect everything
Increased bandwidth on VPN concentrator
Latency for Internet access (hairpins through HQ)

Split Tunnel (Selective Traffic)

Only corporate-destined traffic uses VPN
Internet traffic goes direct
Reduces VPN infrastructure load
Security concern: client exposed while split

Modern hybrid: Split tunnel with security

Corporate traffic through VPN
Cloud services (M365, Google) direct
DNS through corporate (for visibility)
Endpoint protection required on client

remote-access-architecture.txt
REMOTE ACCESS VPN ARCHITECTURE
═══════════════════════════════════════════════════════════════════════════
 
                                    ┌─────────────────────────────────┐
                                    │          DATA CENTER            │
                                    │  ┌─────────────────────────────┐│
         Remote                     │  │     VPN Concentrator        ││
         Users                      │  │    ┌─────────────────────┐  ││
           │                        │  │    │ IKEv2 Responder     │  ││
    ┌──────┴──────┐                │  │    │ RADIUS Client       │  ││
    │             │     Internet   │  │    │ Certificate Auth    │  ││
    ▼             ▼        │       │  │    └─────────────────────┘  ││
┌───────┐    ┌───────┐     │       │  │              │              ││
│Laptop │    │Mobile │     │       │  └──────────────┼──────────────┘│
│  VPN  │    │  VPN  │     │       │                 │               │
│Client │    │Client │     │       │                 ▼               │
└───┬───┘    └───┬───┘     │       │    ┌────────────────────────┐  │
    │            │         │       │    │    RADIUS/AAA Server   │  │
    │   ┌────────┴─────────┤       │    │  ┌──────────────────┐  │  │
    │   │                  │       │    │  │ User Database    │  │  │
    │   │  IKEv2/IPSec     │       │    │  │ MFA Integration  │  │  │
    │   │  Tunnels         │       │    │  │ Group Policies   │  │  │
    │   │                  │       │    │  └──────────────────┘  │  │
    └───┴──────────────────┼───────┤    └────────────────────────┘  │
                           │       │                                 │
                           ▼       │    ┌────────────────────────┐  │
                    ┌──────────┐   │    │   Corporate Network    │  │
                    │   NAT    │   │    │   10.0.0.0/8          │  │
                    │ Gateway  │───┤    │                        │  │
                    └──────────┘   │    │   ┌────┐ ┌────┐ ┌────┐ │  │
                                   │    │   │Srv1│ │Srv2│ │Srv3│ │  │
                                   │    │   └────┘ └────┘ └────┘ │  │
                                   │    └────────────────────────┘  │
                                   └─────────────────────────────────┘
 
 
AUTHENTICATION FLOW (IKEv2 with EAP):
─────────────────────────────────────
 
1. Client → VPN: IKE_SA_INIT (propose algorithms, DH exchange)
2. VPN → Client: IKE_SA_INIT (select algorithms, DH response)
3. Client → VPN: IKE_AUTH (client ID, request EAP)
4. VPN → RADIUS: Access-Request (username)
5. RADIUS → VPN: Access-Challenge (EAP challenge)
6. VPN → Client: IKE_AUTH (EAP challenge)
7. Client → VPN: IKE_AUTH (EAP response - password/MFA)
8. VPN → RADIUS: Access-Request (EAP response)
9. RADIUS → VPN: Access-Accept (success, group membership)
10. VPN → Client: IKE_AUTH (success, assigned IP, routes)

Zero Trust and VPN Evolution

Traditional VPNs grant network access upon authentication—once connected, users can reach many resources. Zero Trust Network Access (ZTNA) evolves this by providing application-specific access based on continuous verification. ZTNA uses tunneling concepts but connects users to specific applications, not networks.

Data Center Interconnect (DCI)

Data Center Interconnect extends network connectivity between geographically separated data centers. The requirements are demanding:

High bandwidth (10 Gbps to 100+ Gbps)
Low latency (for replication, clustering)
Layer 2 extension (for VM mobility)
Multi-tenancy (isolated customer networks)

DCI tunneling technologies:

Data Center Interconnect Technologies
Technology	Encapsulation	Use Case	Scale
VXLAN	UDP/IP (port 4789)	General DC overlay	16 million VNIs
NVGRE	GRE	Microsoft environments	16 million VSIDs
MPLS/VPLS	MPLS labels	Carrier Ethernet	4K VPN labels (extensible)
OTV (Overlay Transport Virtualization)	GRE+IPSec	L2 extension over L3	Multi-site DCI
GENEVE	UDP/IP	Next-gen overlay	Extensible metadata

VXLAN (Virtual Extensible LAN):

VXLAN is the dominant DCI and overlay technology. It tunnels Layer 2 Ethernet frames over UDP/IP:

Key features:

VNI (VXLAN Network Identifier): 24-bit identifier supports 16 million isolated networks
VTEP (VXLAN Tunnel Endpoint): Switch or hypervisor that performs encapsulation
UDP encapsulation: Enables transit across standard IP networks
Multicast or unicast flooding: For BUM (Broadcast, Unknown unicast, Multicast) traffic

vxlan-packet-structure.txt
VXLAN PACKET STRUCTURE
═══════════════════════════════════════════════════════════════════════════
 
Outer Ethernet Header (14 bytes):
┌─────────────────────────────────────────────────────────────────────────┐
│ Dst MAC │ Src MAC │ EtherType (0x0800 = IPv4 or 0x86DD = IPv6)        │
└─────────────────────────────────────────────────────────────────────────┘
 
Outer IP Header (20 bytes):
┌─────────────────────────────────────────────────────────────────────────┐
│ Version │ IHL │ ToS │ Total Length │ ID │ Flags │ Offset │ TTL │ Proto │
│ (4)     │ (5) │     │              │    │       │        │     │ (17)  │
├─────────────────────────────────────────────────────────────────────────┤
│ Header Checksum │ Source VTEP IP │ Destination VTEP IP                 │
└─────────────────────────────────────────────────────────────────────────┘
 
Outer UDP Header (8 bytes):
┌─────────────────────────────────────────────────────────────────────────┐
│ Source Port (hash) │ Dest Port (4789) │ Length │ Checksum              │
└─────────────────────────────────────────────────────────────────────────┘
 
VXLAN Header (8 bytes):
┌─────────────────────────────────────────────────────────────────────────┐
│ Flags (8 bits) │ Reserved (24 bits) │ VNI (24 bits) │ Reserved (8 bits)│
│   (I flag=1)   │                    │  (0-16777215) │                   │
└─────────────────────────────────────────────────────────────────────────┘
 
Inner Ethernet Frame (original L2 frame):
┌─────────────────────────────────────────────────────────────────────────┐
│ Inner Dst MAC │ Inner Src MAC │ Inner EtherType │ Inner IP │ Payload   │
│ (original VM) │ (original VM) │                 │          │           │
└─────────────────────────────────────────────────────────────────────────┘
 
 
OVERHEAD: 50 bytes (14 + 20 + 8 + 8) for IPv4 underlay
EFFECTIVE MTU: 1500 - 50 = 1450 bytes for inner frame
 
 
VXLAN IN DATA CENTER FABRIC:
────────────────────────────
 
  Rack 1                 Spine Layer                 Rack 2
  ┌─────┐               ┌─────────┐               ┌─────┐
  │ VM1 │               │ Spine 1 │               │ VM3 │
  │VNI: │               └────┬────┘               │VNI: │
  │1000 │                    │                    │1000 │
  └──┬──┘               ┌────┴────┐               └──┬──┘
     │                  │ Spine 2 │                  │
  ┌──┴──┐               └────┬────┘               ┌──┴──┐
  │VTEP │◄───── VXLAN Tunnel over IP fabric ────►│VTEP │
  │Leaf1│                                         │Leaf2│
  └─────┘                                         └─────┘
 
VM1 (10.0.1.5 in VNI 1000) communicates with VM3 (10.0.1.8 in VNI 1000):
1. VM1 sends frame to Leaf1 VTEP
2. Leaf1 encapsulates in VXLAN with VNI 1000
3. Outer IP: Leaf1 VTEP → Leaf2 VTEP
4. Spines route based on outer IP (standard L3 routing)
5. Leaf2 receives, strips VXLAN, delivers to VM3

EVPN/VXLAN

Modern data center fabrics combine VXLAN with EVPN (Ethernet VPN) for control plane. EVPN uses BGP to distribute MAC addresses and VTEP information, eliminating flood-and-learn and providing efficient multicast handling. EVPN/VXLAN is the standard for leaf-spine data center fabrics.

Cloud Connectivity

Every major cloud provider offers tunneling-based connectivity options to link on-premises networks with cloud virtual networks. Understanding these services is essential for hybrid cloud architectures.

Cloud Provider VPN Services
Provider	VPN Service	Protocol	Throughput
AWS	Site-to-Site VPN	IPSec (IKEv1/v2)	Up to 1.25 Gbps per tunnel
Azure	VPN Gateway	IPSec (IKEv2)	Up to 10 Gbps (VpnGw5)
GCP	Cloud VPN	IPSec (IKEv2)	Up to 3 Gbps per tunnel
AWS	Client VPN	OpenVPN-based	Variable
Azure	Point-to-Site VPN	IKEv2, OpenVPN, SSTP	Variable

AWS Site-to-Site VPN architecture:

AWS provides managed VPN endpoints called Virtual Private Gateways (VGW) that attach to VPCs. Key characteristics:

Redundancy: Each VPN connection provides two tunnels to different availability zones
BGP support: Dynamic routing via BGP for automatic failover
Accelerated VPN: Uses AWS Global Accelerator for optimized routing
Transit Gateway: Central hub for connecting multiple VPCs and VPNs

High-availability design:

For production deployments, best practices include:

Use both tunnels provided by AWS (active/active or active/standby)
Deploy dual customer gateways for on-premises redundancy
Configure BGP with asymmetric routing support
Monitor tunnel status with CloudWatch

cloud-vpn-architecture.txt
AWS SITE-TO-SITE VPN HIGH AVAILABILITY
═══════════════════════════════════════════════════════════════════════════
 
              ON-PREMISES                              AWS CLOUD
    ┌─────────────────────────┐          ┌─────────────────────────────────┐
    │                         │          │              VPC                │
    │   ┌─────────────────┐   │          │         10.0.0.0/16            │
    │   │  Customer       │   │          │                                 │
    │   │  Gateway 1      │═══╪══════════╪═══> VPN Tunnel 1              │
    │   │  (Primary)      │   │          │          │                     │
    │   │                 │═══╪══════════╪═══> VPN Tunnel 2 ──┐          │
    │   └─────────────────┘   │          │                     │          │
    │           │             │          │                     ▼          │
    │           │             │          │    ┌───────────────────────┐   │
    │      ┌────┴────┐        │          │    │  Virtual Private      │   │
    │      │Corporate│        │          │    │  Gateway (VGW)        │   │
    │      │ Router  │        │          │    │                       │   │
    │      └────┬────┘        │          │    │  AZ-a    │    AZ-b    │   │
    │           │             │          │    │ Endpoint │  Endpoint  │   │
    │   ┌───────┴─────────┐   │          │    └─────┬─────────┬───────┘   │
    │   │  Customer       │   │          │          │         │           │
    │   │  Gateway 2      │═══╪══════════╪═══> VPN ─┘         │           │
    │   │  (Secondary)    │   │          │   Tunnel 3         │           │
    │   │                 │═══╪══════════╪═══> VPN Tunnel 4 ──┘           │
    │   └─────────────────┘   │          │                                │
    │                         │          │        ┌─────────────────┐     │
    │  Corporate Network      │          │        │   EC2 Instances │     │
    │    192.168.0.0/16       │          │        │   10.0.x.x      │     │
    │                         │          │        └─────────────────┘     │
    └─────────────────────────┘          └─────────────────────────────────┘
 
 
BGP CONSIDERATIONS:
──────────────────
 
On-Prem AS: 65000            AWS AS: 64512 (or custom)
 
Advertise to AWS:            Receive from AWS:
• 192.168.0.0/16             • 10.0.0.0/16 (VPC CIDR)
• Any other on-prem ranges   • Any other VPC ranges
 
BGP Path Selection:
• Prefer active tunnel over standby (AS path prepending)
• Or use MED (Multi-Exit Discriminator) for preference
• Equal-cost multipath for load balancing across tunnels

Direct Connect / ExpressRoute

For higher bandwidth or lower latency, cloud providers offer dedicated private connections (AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect). These use private circuits rather than Internet VPN, but still involve tunneling concepts—VLAN tags, VRFs, and BGP peering establish isolated virtual connections over shared physical infrastructure.

Software-Defined Networking Overlays

Software-Defined Networking (SDN) fundamentally relies on tunneling to decouple the logical network from physical infrastructure. SDN overlays create virtual networks that exist independently of the underlying physical topology.

SDN overlay architecture:

Underlay Network The physical network provides IP connectivity between all devices. It handles routing, switching, and forwarding based on physical addresses.

Overlay Network Virtual networks created through tunneling. Logical topologies, isolation, and policies operate at this layer.

SDN Controller Central intelligence that programs both layers, telling virtual switches how to encapsulate and where to send traffic.

sdn-overlay-diagram.txt
SDN OVERLAY ARCHITECTURE
═══════════════════════════════════════════════════════════════════════════
 
               ┌─────────────────────────────────────┐
               │          SDN CONTROLLER             │
               │   ┌─────────────────────────────┐   │
               │   │  Topology Discovery         │   │
               │   │  Policy Engine              │   │
               │   │  Overlay Programming        │   │
               │   │  Underlay Abstraction       │   │
               │   └─────────────────────────────┘   │
               └────────────────┬────────────────────┘
                                │ Control Plane (OpenFlow, OVSDB, gRPC)
          ┌─────────────────────┼─────────────────────┐
          │                     │                     │
          ▼                     ▼                     ▼
     ┌─────────┐           ┌─────────┐           ┌─────────┐
     │ Virtual │           │ Virtual │           │ Virtual │
     │ Switch 1│◄═════════►│ Switch 2│◄═════════►│ Switch 3│
     │ (OVS)   │  Tunnels  │ (OVS)   │  Tunnels  │ (OVS)   │
     └────┬────┘  (VXLAN/  └────┬────┘  (VXLAN/  └────┬────┘
          │       GENEVE)       │       GENEVE)       │
     ┌────┴────┐           ┌────┴────┐           ┌────┴────┐
     │ VM  VM  │           │ VM  VM  │           │ VM  VM  │
     │  A   B  │           │  C   D  │           │  E   F  │
     └─────────┘           └─────────┘           └─────────┘
          │                     │                     │
          └─────────────────────┼─────────────────────┘
                                │
                    ┌───────────┴───────────┐
                    │   UNDERLAY NETWORK    │
                    │   (Physical Fabric)   │
                    │   IP Routing Only     │
                    └───────────────────────┘
 
 
OVERLAY OPERATIONS:
───────────────────
 
1. VM A (on vSwitch 1) sends packet to VM D (on vSwitch 2)
2. vSwitch 1 checks forwarding table (programmed by controller)
3. vSwitch 1 encapsulates in tunnel (VXLAN to vSwitch 2)
4. Underlay forwards based on physical IPs
5. vSwitch 2 decapsulates, delivers to VM D
 
Controller's role:
• Learns VM locations (which vSwitch hosts which VM)
• Programs tunnel endpoints in each vSwitch
• Distributes forwarding entries
• Enforces network policies (ACLs, QoS)

SDN Overlay Platforms
Platform	Tunnel Protocol	Controller	Deployment
VMware NSX	GENEVE, VXLAN	NSX Manager	Enterprise/DC
Cisco ACI	VXLAN	APIC	Enterprise DC
OpenStack Neutron	VXLAN, GRE	Neutron Server	OpenStack clouds
Kubernetes CNI (Calico)	VXLAN, IPIP, WireGuard	Kube-apiserver	Container networks
Kubernetes CNI (Cilium)	VXLAN, GENEVE	Cilium Operator	Container networks

Container Networking

Kubernetes networking plugins (CNI) heavily use tunneling. Calico can use IPIP or VXLAN for cross-node pod communication. Cilium uses VXLAN or GENEVE. Flannel supports multiple backends including VXLAN. Understanding tunneling is essential for troubleshooting container network issues.

Protocol Transition Tunneling

Tunneling enables coexistence and gradual transition between incompatible protocol versions, most notably in the IPv4-to-IPv6 transition.

IPv6 Transition Mechanisms:

IPv6 Transition Tunneling Technologies
Mechanism	Type	Description	Status
6in4 / 6to4	Configured/Automatic	IPv6 over IPv4 static tunnels	Deprecated (6to4)
ISATAP	Automatic	IPv6 over IPv4 intra-site	Legacy
Teredo	NAT traversal	IPv6 over UDP/IPv4	Legacy/backup
DS-Lite	Carrier NAT	IPv4 over IPv6 to CGN	ISP deployments
MAP-T/MAP-E	Stateless	IPv4/IPv6 translation+encap	Modern approach
464XLAT	Mobile	IPv4 apps over IPv6-only	Mobile networks

DS-Lite (Dual-Stack Lite):

DS-Lite is used by ISPs who have deployed IPv6 to their customers but still need to provide IPv4 Internet access:

Customer receives only IPv6 (and private IPv4 or CGNAT)
Customer device tunnels IPv4 traffic over IPv6 to ISP's AFTR (Address Family Transition Router)
AFTR performs NAT from private IPv4 to shared public IPv4
Return traffic is NAT'd and tunneled back over IPv6

This allows ISPs to run IPv6-only infrastructure while maintaining IPv4 connectivity for customers.

Deprecation Notice

Many early IPv6 transition mechanisms (6to4, ISATAP, Teredo) are deprecated due to security concerns, reliability issues, or declining necessity as native IPv6 becomes widespread. Modern deployments prefer native IPv6 or well-controlled tunneling like DS-Lite within ISP infrastructure.

Summary: Tunneling Applications

Tunneling underpins modern networking across every domain. Let's consolidate the key applications:

Key Takeaways

•Site-to-site VPNs connect networks — IPSec, GRE over IPSec, and DMVPN create secure links between offices, data centers, and partners.
•Remote access VPNs enable mobility — IKEv2, OpenVPN, and WireGuard connect individual users from anywhere to corporate resources.
•Data center interconnect uses overlay — VXLAN with EVPN provides scalable, multi-tenant connectivity between data centers.
•Cloud connectivity leverages IPSec — AWS, Azure, and GCP all use IPSec tunnels for hybrid cloud connections.
•SDN overlays decouple logical from physical — Tunneling enables virtual networks independent of underlying infrastructure.
•Protocol transition bridges incompatible networks — IPv6 over IPv4 (and vice versa) enables gradual migration.

Module complete:

You've now completed the comprehensive study of network tunneling. From the fundamental concept of encapsulation through GRE, IPSec, mode comparisons, and real-world applications, you understand how tunneling enables the secure, flexible, and scalable networks that power modern computing.

Module Complete

Congratulations! You've mastered network tunneling—the techniques that create virtual links, secure communications, and enable modern network architectures. From VPNs to cloud connectivity to container networking, tunneling is everywhere, and you now have the knowledge to design, deploy, and troubleshoot tunneled networks.