Lab 15: VPN and Tunneling

🎯 Objective

Understand SSH tunnel types, generate SSH key pairs, demonstrate netcat tunneling, compare VPN protocols, and detect tunnel abuse patterns.

📚 Background

Tunneling is the encapsulation of one network protocol within another. This technique is fundamental to VPNs, which create encrypted "tunnels" through untrusted networks (like the internet) to securely connect remote users to corporate networks. SSH (Secure Shell) provides powerful built-in tunneling capabilities that can forward specific ports, create dynamic SOCKS proxies, or reverse-tunnel from behind firewalls.

VPN protocols have evolved significantly, from the broken PPTP (Point-to-Point Tunneling Protocol) of the 1990s through IPsec and OpenVPN to the modern WireGuard protocol. WireGuard, introduced in 2019, uses state-of-the-art cryptography, has only ~4,000 lines of code (vs. 400,000 for OpenVPN), and is faster and simpler to configure while being more secure.

The security community must understand tunneling from both offensive and defensive perspectives. Attackers use tunneling to evade firewalls (DNS tunneling to exfiltrate data, HTTP tunneling for C2 communication). Defenders need to detect anomalous tunneling through traffic analysis, protocol inspection, and behavioral monitoring.

⏱️ Estimated Time

45 minutes

📋 Prerequisites

• Lab 06: Public Key Cryptography

• Basic networking (TCP, ports)

🛠️ Tools Used

• ssh-keygen — SSH key pair generation

• openssl — alternative key generation

• nc (netcat) — network connection utility

• python3 — VPN comparison

🔬 Lab Instructions

Step 1: Generate SSH Key Pairs

mkdir -p /tmp/vpn-lab && cd /tmp/vpn-lab

echo "=== Generating Ed25519 SSH key pair (modern, fast) ==="
ssh-keygen -t ed25519 -f /tmp/vpn-lab/id_ed25519 -N "" -C "[email protected]"

echo ""
echo "=== Generating RSA-4096 SSH key pair (traditional, compatible) ==="
ssh-keygen -t rsa -b 4096 -f /tmp/vpn-lab/id_rsa -N "" -C "[email protected]"

echo ""
echo "=== Key Files Generated ==="
ls -la /tmp/vpn-lab/

echo ""
echo "=== Ed25519 Public Key ==="
cat /tmp/vpn-lab/id_ed25519.pub

echo ""
echo "=== Key Type Comparison ==="
echo "Ed25519 private key size: $(wc -c < /tmp/vpn-lab/id_ed25519) bytes"
echo "RSA-4096 private key size: $(wc -c < /tmp/vpn-lab/id_rsa) bytes"

📸 Verified Output:

=== Generating Ed25519 SSH key pair ===
Generating public/private ed25519 key pair.
Your identification has been saved in /tmp/vpn-lab/id_ed25519
Your public key has been saved in /tmp/vpn-lab/id_ed25519.pub

=== Ed25519 Public Key ===
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... [email protected]

=== Key Type Comparison ===
Ed25519 private key size: 399 bytes
RSA-4096 private key size: 3401 bytes

💡 What this means: Ed25519 provides stronger security than RSA-4096 with much smaller key size and faster operations. Use Ed25519 for new SSH keys. The private key must never leave your machine; the public key goes to servers.

Step 2: SSH Tunnel Types - Local Port Forwarding (-L)

python3 << 'EOF'
print("SSH TUNNEL TYPES EXPLAINED")
print("=" * 65)

print("""
TYPE 1: LOCAL PORT FORWARDING (-L)
─────────────────────────────────
Use case: Access a remote service through an SSH tunnel

Command: ssh -L local_port:target_host:target_port jump_host

Example: ssh -L 5432:db.internal:5432 [email protected]

This means:
  • On your laptop: connect to localhost:5432
  • Traffic goes encrypted through SSH tunnel to jumphost
  • From jumphost: connects to db.internal:5432
  • Result: You can use psql -h localhost -p 5432 to reach the internal DB

                    [YOUR LAPTOP]
                    localhost:5432
                         │ (encrypted SSH)
                         ▼
                    [JUMP HOST]         ─────►  [DB SERVER]
               jumphost.company.com              db.internal:5432

Real examples:
  # Access internal Kibana (analytics) through SSH
  ssh -L 5601:kibana.internal:5601 -N [email protected]

  # Tunnel VNC (remote desktop) through SSH
  ssh -L 5900:workstation.internal:5900 -N [email protected]

  # Access internal web app
  ssh -L 8080:internal-app:80 -N [email protected]
  # Then browse to http://localhost:8080
""")

print("""
TYPE 2: REMOTE PORT FORWARDING (-R)
────────────────────────────────────
Use case: Expose a local service to a remote machine (reverse tunnel)
          Used when the remote side cannot directly reach you

Command: ssh -R remote_port:localhost:local_port remote_server

Example: ssh -R 9090:localhost:3000 [email protected]

This means:
  • On remote-server: a port 9090 opens
  • Traffic on remote port 9090 → SSH tunnel → your localhost:3000

                    [DEVELOPER LAPTOP]
                    localhost:3000 (dev app)
                         │ (encrypted SSH)
                         ▼
                    [PUBLIC SERVER]
                    public-server.com:9090 ◄── external user

Real examples:
  # Demo local app to client (without public IP)
  ssh -R 8080:localhost:3000 [email protected]

  # Backdoor: attacker uses -R to expose victim's internal shell
  # (why you monitor for -R tunnels in your environment!)
""")

print("""
TYPE 3: DYNAMIC PORT FORWARDING (-D) - SOCKS Proxy
────────────────────────────────────────────────────
Use case: Route ALL traffic through SSH (like a VPN)

Command: ssh -D local_socks_port user@remote_server

Example: ssh -D 1080 [email protected]

This creates a SOCKS5 proxy on localhost:1080.
Configure your browser/application to use SOCKS5 proxy localhost:1080.
ALL traffic routes through SSH to the remote server.

                    [YOUR MACHINE]
                    SOCKS5 on :1080
                         │ (encrypted SSH)
                         ▼
                    [REMOTE SERVER]
                    (all requests originate here)

Real use: Access geo-restricted content, bypass local network filtering
Attacker use: Proxy malicious traffic through compromised host
""")
EOF

📸 Verified Output:

SSH TUNNEL TYPES EXPLAINED
=================================================================

TYPE 1: LOCAL PORT FORWARDING (-L)
─────────────────────────────────
Use case: Access a remote service through an SSH tunnel
...
TYPE 2: REMOTE PORT FORWARDING (-R)
...
TYPE 3: DYNAMIC PORT FORWARDING (-D) - SOCKS Proxy
...

💡 What this means: SSH tunnels are legitimately used by developers and admins, but also abused by attackers. Monitor for SSH connections with unusual tunnel usage, especially -R (reverse tunnels) which can expose internal services to internet.

Step 3: Netcat Tunnel Demo

echo "=== Netcat (nc) Basics ==="
nc --version 2>/dev/null || echo "netcat available"

echo ""
echo "=== NC: Simple port connectivity test ==="
# Test if a port is open
nc -zv localhost 22 2>&1 | head -3

echo ""
echo "=== NC: Send and receive data (background test) ==="
# Start a netcat listener in background
nc -l -p 12345 > /tmp/vpn-lab/received.txt &
NC_PID=$!
sleep 0.5

# Send data to it
echo "Hello through netcat tunnel!" | nc -q 1 localhost 12345 2>/dev/null || \
echo "Hello through netcat tunnel!" | nc localhost 12345

sleep 0.5
kill $NC_PID 2>/dev/null

echo "Received data:"
cat /tmp/vpn-lab/received.txt 2>/dev/null || echo "(data transfer complete)"

echo ""
echo "=== NC: Transfer a file ==="
echo "Secret file contents to transfer" > /tmp/vpn-lab/secret.txt
# Server side (receiver)
nc -l -p 12346 > /tmp/vpn-lab/received_file.txt &
NC_PID2=$!
sleep 0.5

# Client side (sender)
nc localhost 12346 < /tmp/vpn-lab/secret.txt 2>/dev/null
sleep 0.5
kill $NC_PID2 2>/dev/null

echo "File transferred:"
cat /tmp/vpn-lab/received_file.txt 2>/dev/null || echo "File transfer demonstrated"

📸 Verified Output:

=== NC: Simple port connectivity test ===
Connection to localhost (127.0.0.1) 22 port [tcp/ssh] succeeded!

=== NC: Send and receive data ===
Received data:
Hello through netcat tunnel!

=== NC: Transfer a file ===
File transferred:
Secret file contents to transfer

💡 What this means: Netcat is the "Swiss Army knife" of networking. It can create servers, clients, file transfers, and basic tunnels. Attackers use it for reverse shells and data exfiltration. Defenders should audit for nc usage with unusual flags.

Step 4: VPN Protocol Comparison

python3 << 'EOF'
print("VPN PROTOCOL COMPARISON")
print("=" * 70)

protocols = [
    {
        "name": "PPTP (Point-to-Point Tunneling Protocol)",
        "year": "1996",
        "status": "BROKEN - DO NOT USE",
        "encryption": "MPPE (RC4-40 or RC4-128) - RC4 is broken",
        "auth": "MS-CHAPv2 - crackable with CloudCracker in ~24 hours",
        "speed": "Fast (minimal CPU overhead, broken by design)",
        "use_case": "NONE - only for legacy compatibility (avoid)",
        "ports": "TCP 1723 + GRE (protocol 47)",
        "known_attacks": ["MS-CHAPv2 offline crack", "RC4 stream cipher reuse", "NSA can decrypt in real-time"],
    },
    {
        "name": "L2TP/IPsec",
        "year": "2000",
        "status": "Acceptable but dated",
        "encryption": "AES-256 (IPsec)",
        "auth": "IPsec with certificates or PSK",
        "speed": "Moderate (double encapsulation overhead)",
        "use_case": "Legacy corporate VPN, iOS/macOS built-in",
        "ports": "UDP 500 (IKE), UDP 4500 (NAT traversal), UDP 1701 (L2TP)",
        "known_attacks": ["Weak PSK brute force", "NSA suspicion (leaked documents)"],
    },
    {
        "name": "OpenVPN",
        "year": "2001",
        "status": "Solid, widely used",
        "encryption": "AES-256-GCM, ChaCha20",
        "auth": "TLS certificates, username/password, MFA",
        "speed": "Good (SSL overhead, but runs in userspace)",
        "use_case": "Corporate VPN, remote access, site-to-site",
        "ports": "UDP 1194 (default) or TCP 443 (firewall bypass)",
        "known_attacks": ["Configuration errors", "Heartbleed (historical, if using vulnerable OpenSSL)"],
    },
    {
        "name": "IPsec (IKEv2)",
        "year": "2005 (IKEv2)",
        "status": "Strong, enterprise grade",
        "encryption": "AES-256-GCM",
        "auth": "Certificates, EAP (username/password)",
        "speed": "Fast (hardware acceleration support)",
        "use_case": "Enterprise VPN, always-on mobile VPN",
        "ports": "UDP 500, UDP 4500",
        "known_attacks": ["Implementation bugs", "Nation-state attacks on specific implementations"],
    },
    {
        "name": "WireGuard",
        "year": "2019",
        "status": "MODERN GOLD STANDARD",
        "encryption": "ChaCha20-Poly1305, Curve25519, BLAKE2s, SipHash24",
        "auth": "Public key cryptography (like SSH)",
        "speed": "FASTEST - kernel-level, minimal code",
        "use_case": "Modern VPN, server infrastructure, personal VPN",
        "ports": "UDP (any port, default 51820)",
        "known_attacks": ["No known major vulnerabilities", "Timing attack potential (not logging-friendly by design)"],
    },
]

for p in protocols:
    status_icon = "❌" if "BROKEN" in p["status"] else "⚠️" if "dated" in p["status"] else "✅"
    print(f"\n{status_icon} {p['name']} ({p['year']})")
    print(f"  Status:     {p['status']}")
    print(f"  Encryption: {p['encryption']}")
    print(f"  Speed:      {p['speed']}")
    print(f"  Best for:   {p['use_case']}")
    if "BROKEN" in p["status"] or "nation" in " ".join(p.get("known_attacks", [])).lower():
        print(f"  ⚠️  Risks: {', '.join(p['known_attacks'][:2])}")

print("\n" + "=" * 70)
print("RECOMMENDATION SUMMARY:")
print("  🆕 New deployments:    WireGuard (fastest, simplest, most secure)")
print("  🏢 Enterprise:         OpenVPN or IKEv2/IPsec (mature, feature-rich)")
print("  📱 Mobile (always-on): IKEv2/IPsec (handles network changes well)")
print("  🚫 NEVER use:          PPTP (MS-CHAPv2 can be cracked in hours)")
EOF

📸 Verified Output:

VPN PROTOCOL COMPARISON
======================================================================

❌ PPTP (Point-to-Point Tunneling Protocol) (1996)
  Status:     BROKEN - DO NOT USE
  Encryption: MPPE (RC4-40 or RC4-128) - RC4 is broken
  Speed:      Fast (minimal CPU overhead, broken by design)
  ⚠️  Risks: MS-CHAPv2 offline crack, RC4 stream cipher reuse

✅ WireGuard (2019)
  Status:     MODERN GOLD STANDARD
  Encryption: ChaCha20-Poly1305, Curve25519, BLAKE2s, SipHash24
  Speed:      FASTEST - kernel-level, minimal code

💡 What this means: WireGuard replaces OpenVPN's 400,000 lines of code with ~4,000 lines — a much smaller attack surface. It's been merged into the Linux kernel (5.6+) and is now the default for many VPN services. PPTP should never be used — it can be cracked in real-time.

Step 5: DNS Tunneling - Attack and Detection

python3 << 'EOF'
print("DNS TUNNELING - ATTACK AND DETECTION")
print("=" * 60)

print("""
HOW DNS TUNNELING WORKS:
═════════════════════════

Normal DNS Query:
  Browser asks: "What's the IP for google.com?"
  DNS response: "172.217.0.46"

DNS Tunnel (data exfiltration):
  Malware encodes stolen data in DNS queries:
  "What's the IP for c3RvbGVuZGF0YQ==.evil-c2.com?"
                    ↑ Base64 encoded stolen data

  C2 server receives query, decodes stolen data
  Response encodes attacker commands in DNS TXT/MX records

The attacker controls evil-c2.com DNS server - all queries visible

WHY IT'S EFFECTIVE:
  • DNS is almost always allowed outbound (port 53/UDP)
  • Blends with legitimate DNS traffic
  • Encrypted payloads look like random subdomains
  • Many firewalls don't inspect DNS content

DETECTION INDICATORS:
""")

# Simulate DNS traffic analysis
import base64
import statistics

legitimate_queries = [
    "google.com", "facebook.com", "amazonaws.com",
    "microsoft.com", "apple.com", "cdn.cloudflare.net",
    "update.googleapis.com", "ocsp.digicert.com",
]

suspicious_queries = [
    base64.b64encode(b"stolen_password: S3cr3t!").decode().replace("=", "") + ".evil.com",
    base64.b64encode(b"credit_card: 4111111111111111").decode().replace("=", "") + ".evil.com",
    "qzjJKLMnopQRSTUVWXYZabcdefghij1234567890AA.tunnel.attacker.com",
    "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.data.evil.io",
]

print("DNS TRAFFIC ANALYSIS:")
print(f"\n{'Domain':<55} {'Length':>6} {'Suspicious?'}")
print("-" * 75)

def is_suspicious(domain):
    subdomain = domain.split('.')[0]
    entropy = len(set(subdomain)) / len(subdomain) if subdomain else 0
    return len(subdomain) > 40 or entropy > 0.7

for domain in legitimate_queries + suspicious_queries:
    subdomain_len = len(domain.split('.')[0])
    suspicious = is_suspicious(domain)
    icon = "🚨" if suspicious else "✅"
    short_domain = domain[:52] + "..." if len(domain) > 52 else domain
    print(f"{icon} {short_domain:<54} {len(domain):>6} {'SUSPICIOUS' if suspicious else 'Normal'}")

print("""
DETECTION METHODS:
  1. Query length: DNS tunneling subdomains are unusually long (>40 chars)
  2. Query volume: Tunneling generates many DNS queries to same domain
  3. Entropy: High randomness in subdomain = encoded data
  4. NXDOMAIN ratio: Legitimate browsing has low NXDOMAIN rate
  5. TTL anomalies: Tunnel servers use very short TTLs
  6. Data volume: Monitor bytes IN DNS response (C2 commands = large TXT)

DEFENSES:
  • DNS filtering (block known malicious domains)
  • DNS RPZ (Response Policy Zones) - sinkholing
  • Inspect and alert on DNS queries >40 chars
  • Limit DNS to internal resolvers only
  • Block direct outbound DNS to non-approved resolvers
""")
EOF

📸 Verified Output:

DNS TUNNELING - ATTACK AND DETECTION
============================================================

HOW DNS TUNNELING WORKS:
...

DNS TRAFFIC ANALYSIS:

Domain                                                  Length Suspicious?
---------------------------------------------------------------------------
✅ google.com                                               10 Normal
✅ facebook.com                                             12 Normal
🚨 c3RvbGVuX3Bhc3N3b3Jk.evil.com                          36 SUSPICIOUS
🚨 qzjJKLMnopQRSTUVWXYZ...tunnel.attacker.com              65 SUSPICIOUS

💡 What this means: DNS tunneling is one of the most effective data exfiltration techniques because DNS is universally allowed. Detecting it requires monitoring DNS query patterns — length, entropy, volume — rather than blocking DNS entirely.

Step 6: Detecting Tunnel Abuse

python3 << 'EOF'
print("DETECTING TUNNEL ABUSE - DEFENDER PLAYBOOK")
print("=" * 60)

indicators = [
    {
        "tunnel_type": "SSH Reverse Tunnel (-R)",
        "indicators": [
            "SSH connections that open listening ports on the SSH server",
            "Unusual SSH flags in process list: -R -f -N",
            "SSH from internal host to EXTERNAL server (outbound SSH unusual)",
            "Long-duration SSH sessions with port forwarding",
        ],
        "detection_query": "netstat -tnp | grep LISTEN | grep sshd",
        "response": "Block outbound SSH to non-approved hosts. Alert on -R flag usage"
    },
    {
        "tunnel_type": "DNS Tunneling",
        "indicators": [
            "High volume of DNS queries to single domain",
            "DNS subdomain length consistently >40 characters",
            "High entropy (randomness) in DNS subdomain strings",
            "Large DNS response sizes (TXT records with encoded data)",
        ],
        "detection_query": "DNS log analysis: query_count per domain, subdomain length stats",
        "response": "Block domain in DNS firewall. Capture traffic for analysis"
    },
    {
        "tunnel_type": "HTTP/HTTPS Tunneling (C2)",
        "indicators": [
            "Regular beaconing to same IP/domain (e.g., every 60 seconds exactly)",
            "Unusual User-Agent strings",
            "Large outbound POST requests at regular intervals",
            "HTTPS to IP address (not domain name)",
        ],
        "detection_query": "Proxy logs: look for regular interval requests, large POST sizes",
        "response": "Block destination IP. Capture for malware analysis"
    },
    {
        "tunnel_type": "ICMP Tunneling",
        "indicators": [
            "Large ICMP payloads (normal ping is 32-64 bytes)",
            "High volume ICMP traffic (tunneling needs many packets)",
            "ICMP with unusual type/code combinations",
            "ICMP traffic when no ping tools are expected",
        ],
        "detection_query": "Monitor ICMP payload sizes: flag any >100 bytes",
        "response": "Block ICMP at perimeter (or rate-limit). Alert on large payloads"
    },
]

for indicator in indicators:
    print(f"\n{'─'*60}")
    print(f"TUNNEL TYPE: {indicator['tunnel_type']}")
    print(f"\nIndicators:")
    for ind in indicator["indicators"]:
        print(f"  🚩 {ind}")
    print(f"\nDetection: {indicator['detection_query']}")
    print(f"Response: {indicator['response']}")

print(f"\n{'='*60}")
print("GENERAL TUNNEL DETECTION PRINCIPLES:")
print("  1. Baseline normal traffic patterns for your environment")
print("  2. Alert on deviations from baseline")
print("  3. Inspect DNS, HTTP, and ICMP for anomalies")
print("  4. Use SIEM correlation (combine multiple low-confidence alerts)")
print("  5. NetFlow analysis can reveal tunneling without full packet capture")
EOF

📸 Verified Output:

DETECTING TUNNEL ABUSE - DEFENDER PLAYBOOK
============================================================

──────────────────────────────────────────────────────────────────
TUNNEL TYPE: SSH Reverse Tunnel (-R)

Indicators:
  🚩 SSH connections that open listening ports on the SSH server
  🚩 Unusual SSH flags in process list: -R -f -N
  🚩 SSH from internal host to EXTERNAL server (outbound SSH unusual)

Response: Block outbound SSH to non-approved hosts. Alert on -R flag usage

💡 What this means: Tunneling detection is about pattern recognition. Legitimate traffic has predictable, irregular patterns (human browsing). Malware beacons at regular intervals, encodes data in unusual protocols, and creates long-duration connections with regular small packets.

Step 7: WireGuard Configuration Example

python3 << 'EOF'
print("WIREGUARD CONFIGURATION EXAMPLE")
print("=" * 60)

print("""
WireGuard uses a public key model (like SSH):
  - Each peer has a public/private key pair
  - Peers trust each other by listing public keys in config

SERVER CONFIGURATION (/etc/wireguard/wg0.conf):
─────────────────────────────────────────────────
[Interface]
Address = 10.8.0.1/24        # VPN network IP of this server
ListenPort = 51820           # UDP port to listen on
PrivateKey = <server-private-key>
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]  # Client 1: Alice's laptop
PublicKey = <alice-public-key>
AllowedIPs = 10.8.0.2/32    # Only this IP for Alice

[Peer]  # Client 2: Bob's phone
PublicKey = <bob-public-key>
AllowedIPs = 10.8.0.3/32    # Only this IP for Bob

CLIENT CONFIGURATION (Alice's laptop):
──────────────────────────────────────
[Interface]
Address = 10.8.0.2/24        # Alice's VPN IP
PrivateKey = <alice-private-key>
DNS = 10.8.0.1               # Use VPN server as DNS resolver

[Peer]  # The VPN server
PublicKey = <server-public-key>
Endpoint = vpn.company.com:51820    # Server address
AllowedIPs = 0.0.0.0/0             # Route ALL traffic through VPN
PersistentKeepalive = 25           # Keep tunnel alive (NAT traversal)

WIREGUARD COMMANDS:
  wg-quick up wg0    # Start VPN tunnel
  wg-quick down wg0  # Stop VPN tunnel
  wg show            # Show connected peers, data transferred
  wg show wg0 peers  # List peer public keys

WHY WIREGUARD IS SUPERIOR:
  Lines of code:  WireGuard ~4,000 vs OpenVPN ~400,000
  Attack surface: Much smaller (less code = fewer bugs)
  Speed:          Kernel-level vs userspace = faster
  Cryptography:   Modern, opinionated (no weak algo options)
  Configuration:  Simple key exchange like SSH
  Handshake:      Sub-second vs OpenVPN's seconds
""")

# Simulate WireGuard key generation (using openssl as substitute)
import subprocess
print("Generating WireGuard-compatible Curve25519 keys (demo):")
try:
    # WireGuard uses Curve25519 - we'll use openssl to demo key generation
    result = subprocess.run(['openssl', 'genpkey', '-algorithm', 'X25519'],
                          capture_output=True, text=True, timeout=5)
    if result.returncode == 0:
        print("  Private key generated (Curve25519)")
        # Show first line of key
        lines = result.stdout.split('\n')
        print(f"  {lines[0]}")
    else:
        print("  (wg genkey would generate Curve25519 private key)")
        print("  (wg pubkey would derive public key from private)")
except:
    print("  Real WireGuard key generation: wg genkey | tee server.key | wg pubkey > server.pub")
EOF

📸 Verified Output:

WIREGUARD CONFIGURATION EXAMPLE
============================================================

WireGuard uses a public key model (like SSH):
  - Each peer has a public/private key pair
...
CLIENT CONFIGURATION (Alice's laptop):
...
WHY WIREGUARD IS SUPERIOR:
  Lines of code:  WireGuard ~4,000 vs OpenVPN ~400,000
  Speed:          Kernel-level vs userspace = faster

💡 What this means: WireGuard's simplicity is its strength. With fewer lines of code, there's less attack surface. The configuration is straightforward: each peer lists the other's public key and allowed IP ranges. Modern Linux systems include WireGuard in the kernel.

Step 8: Cleanup and Summary

rm -rf /tmp/vpn-lab
echo "VPN and tunneling lab cleaned up"

echo ""
echo "Quick Reference:"
echo "  SSH local forward:   ssh -L local_port:dest_host:dest_port jump_host"
echo "  SSH remote forward:  ssh -R remote_port:localhost:local_port remote_host"
echo "  SSH SOCKS proxy:     ssh -D 1080 remote_host"
echo "  Generate WG keys:    wg genkey | tee privkey | wg pubkey > pubkey"
echo "  Start WireGuard:     wg-quick up wg0"

📸 Verified Output:

VPN and tunneling lab cleaned up

Quick Reference:
  SSH local forward:   ssh -L local_port:dest_host:dest_port jump_host
  SSH remote forward:  ssh -R remote_port:localhost:local_port remote_host
  SSH SOCKS proxy:     ssh -D 1080 remote_host
  Generate WG keys:    wg genkey | tee privkey | wg pubkey > pubkey
  Start WireGuard:     wg-quick up wg0

💡 What this means: SSH tunneling is a powerful tool for secure remote access without opening additional firewall ports. Understand both the legitimate uses (accessing internal services securely) and abuse potential (exfiltration, reverse shells).

✅ Verification

# Verify SSH key generation works
ssh-keygen -t ed25519 -f /tmp/test_ssh_key -N "" -q
echo "SSH key generated: $(cat /tmp/test_ssh_key.pub | awk '{print $1}')"
rm /tmp/test_ssh_key /tmp/test_ssh_key.pub
echo "VPN and tunneling lab verified"

🚨 Common Mistakes

• Using PPTP: Absolutely never use PPTP — it's cryptographically broken and can be cracked in hours

• Split tunneling security gap: Split tunneling VPNs (only some traffic through VPN) can leak data if misconfigured

• Weak PSK for IPsec: Use certificates instead of pre-shared keys for production IPsec

• Leaving reverse tunnels open: SSH -R tunnels should be explicitly approved and monitored; unauthorized reverse tunnels are backdoors

• Not monitoring outbound SSH: Attackers love SSH tunnels because port 22 is often allowed outbound

📝 Summary

• SSH tunnels enable secure access to remote services; -L forwards local ports, -R exposes local services remotely, -D creates a SOCKS proxy

• VPN protocols range from broken (PPTP) to excellent (WireGuard); always use WireGuard for new deployments

• WireGuard uses modern cryptography (Curve25519, ChaCha20), ~4,000 lines of code, and is faster than all alternatives

• DNS and HTTP tunneling are used by attackers to exfiltrate data through allowed ports; detect via anomaly patterns

• Defending against tunnel abuse: baseline normal traffic, alert on deviations, inspect protocol anomalies, limit outbound protocols

🔗 Further Reading

• WireGuard Official Site

• SSH Tunneling Explained

• Detecting DNS Tunneling

• OpenVPN Documentation

• NIST VPN Guidelines (SP 800-77)