Skip to main content

Skillber v1.0 is here!

Learn more

VPN & Remote Access Security

Checking access...

A Virtual Private Network (VPN) creates an encrypted tunnel between a remote device and a corporate network. VPNs have been the standard remote access technology for 25+ years, but are increasingly being replaced by Zero Trust Network Access (ZTNA).

How VPNs Work

Without a VPN, traffic between a remote user and the corporate network traverses the public internet in cleartext. A VPN encrypts this traffic and encapsulates it inside a tunnel.

Remote User Internet (Encrypted) Corporate Network
┌──────────────┐ ┌──────────────────────────────────┐ ┌──────────────────┐
│ Laptop │────│ ======== VPN Tunnel ========== │────│ Internal Resources│
│ VPN Client │ │ (AES-256 encrypted packets) │ │ File Server │
│ (WireGuard/ │ │ │ │ Intranet │
│ OpenVPN) │ │ │ │ Email │
└──────────────┘ └──────────────────────────────────┘ └──────────────────┘

VPN Protocols Compared

ProtocolEncryptionSpeedSecurityEase of UseBest For
IPsec IKEv2AES-256-GCMFastHighModerateSite-to-site, mobile devices
OpenVPNAES-256-CBCModerateHighEasyCross-platform remote access
WireGuardChaCha20-Poly1305FastestHighEasyModern, lightweight deployments
SSL VPN (TLS)AES-256ModerateModerateVery easyBrowser-based, no client needed
PPTPMPPE-128FastVery lowEasyDEPRECATED — do not use
L2TP/IPsecAES-256ModerateHighModerateLegacy compatibility

WireGuard — The Modern Standard

WireGuard is significantly simpler than IPsec and OpenVPN:

Terminal window
# WireGuard server configuration (/etc/wireguard/wg0.conf)
[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = [SERVER_PRIVATE_KEY]
# Allow forwarding
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
# Remote user laptop
PublicKey = [USER_PUBLIC_KEY]
PresharedKey = [PSK] # Optional: adds layer of post-quantum resistance
AllowedIPs = 10.0.0.2/32
[Peer]
# Another user
PublicKey = [ANOTHER_USER_PUBLIC_KEY]
AllowedIPs = 10.0.0.3/32
Terminal window
# WireGuard client configuration
[Interface]
PrivateKey = [USER_PRIVATE_KEY]
Address = 10.0.0.2/24
DNS = 10.0.0.53
[Peer]
PublicKey = [SERVER_PUBLIC_KEY]
Endpoint = vpn.company.com:51820
AllowedIPs = 10.0.0.0/24, 192.168.1.0/24
PersistentKeepalive = 25

OpenVPN Configuration

Terminal window
# OpenVPN server config (/etc/openvpn/server.conf)
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
server 10.8.0.0 255.255.255.0
push "route 10.0.0.0 255.255.255.0"
push "dhcp-option DNS 10.0.0.53"
keepalive 10 120
tls-version-min 1.2
cipher AES-256-GCM
auth SHA256
max-clients 100
user nobody
group nogroup
status openvpn-status.log
log-append /var/log/openvpn.log
verb 3

Split Tunneling vs. Full Tunnel

AspectSplit TunnelFull Tunnel
Corporate trafficThrough VPNThrough VPN
Internet trafficDirect (not through VPN)Through VPN and out corporate egress
PerformanceFaster — less overheadSlower — all traffic double-encrypted
SecurityInternet traffic not inspectedCorporate security inspects all traffic
Corporate egress costLowHigh (all traffic uses corporate bandwidth)
Data exfiltration riskLower (less data in tunnel)Higher (all data accessible if VPN compromised)
Best forPerformance-sensitive usersRegulated environments requiring full inspection

When Split Tunneling Is Appropriate

Allow split tunnel for:
- General employees (web browsing, streaming)
- Contractors (limited internal access)
- SaaS-based companies (most apps are internet-based)
- Video conferencing (low latency required)
Require full tunnel for:
- PCI/SOX regulated roles
- Access to sensitive databases
- Legal and HR departments
- All privileged accounts (admin access)

Authentication Methods

VPN access is only as secure as the authentication method.

MethodSecurity LevelUser ExperienceNotes
Username + passwordLowSimpleBreached: every VPN vendor has had credential stuffing
Certificate-basedHighSeamlessMust be combined with device compliance check
MFA (TOTP)HighModerateMost common: Google Auth, Microsoft Auth
MFA (Push notification)HighGoodDuo, Okta Verify
MFA (U2F/WebAuthn)Very highBest (tap key)Phishing-resistant
Certificate + MFAVery highModerateDefense in depth — strongly recommended
Device posture checkHighTransparentCheck OS patch level, AV running, disk encryption

Real-World Case: Colonial Pipeline Ransomware (2021)

The Colonial Pipeline attack led to a 5-day shutdown of the largest fuel pipeline in the US. The root cause: a compromised VPN without MFA.

Timeline

April 29, 2021:
└─ DarkSide ransomware group gains access to Colonial Pipeline network
└─ Entry vector: Compromised VPN credential for an old VPN account
└─ Account was no longer in active use but still enabled
└─ VPN did NOT require MFA (single-factor authentication only)
May 4, 2021 (6 days later):
└─ Attackers deploy ransomware on Colonial Pipeline billing systems
└─ Operations systems (pipeline control) are isolated — NOT affected
└─ But billing systems taken offline → cannot invoice customers
└─ Decision: shut down pipeline operations as a precaution
May 7, 2021:
└─ Colonial Pipeline publicly discloses ransomware attack
└─ Fuel panic buying begins across US East Coast
May 8, 2021:
└─ Jet fuel shortage at major airports (Atlanta, Charlotte)
└─ States of emergency declared in 17 states + DC
May 9, 2021:
└─ Colonial pays $4.4M ransom in Bitcoin
└─ FBI later recovers $2.3M of the ransom
May 12, 2021:
└─ Pipeline operations fully restored
└─ Total cost: $4.4M ransom + millions in operational losses

Root Causes

Technical Failures:
└─ VPN without MFA
└─ Old/unused VPN account was still active
└─ VPN credential found in a prior breach (credential stuffing)
└─ No anomaly detection on VPN login (3 AM login from unusual IP)
└─ No lateral movement detection after VPN access
Governance Failures:
└─ No quarterly account review (orphan accounts)
└─ No MFA policy for remote access
└─ TSA had flagged pipeline cybersecurity gaps — no action taken
└─ No mandatory cybersecurity standards for critical infrastructure

Aftermath

Regulatory Response:
└─ TSA issued Security Directives for pipelines:
1. Mandatory MFA for all remote access
2. 24/7 incident monitoring
3. Vulnerability assessment within 30 days
4. Cyber coordinator designated for each pipeline
└─ CISA established Joint Cyber Defense Collaborative
└─ Biden Executive Order on Improving Cybersecurity (May 2021)

The Zero Trust Alternative (ZTNA)

ZTNA (Zero Trust Network Access) is increasingly replacing VPNs. Instead of placing users on the corporate network, ZTNA grants access to specific applications.

VPN vs ZTNA

Traditional VPN:
User → VPN → Internal Network → All Resources
└─ User gets full network access (over-privileged)
└─ Once on VPN, lateral movement is possible
└─ VPN is easy target for attackers (wide attack surface)
ZTNA (Zero Trust):
User → Authentication → Application Proxy → Specific App
└─ User gets access to specific app, not entire network
└─ No lateral movement (no network layer)
└─ Application never exposed to internet (hidden)
FeatureVPNZTNA
Network accessFull subnetNone (app-level only)
Lateral movementPossibleImpossible
Internet exposureVPN endpoint exposedNo exposed ports
PerformanceTunneling overheadApplication-level proxy
User experienceMust connect/disconnectAlways-on, seamless
ScalabilityHardware-boundCloud-native
MFAOptional (often not enforced)Mandatory per-session
Device postureNot checkedChecked per request
CostHardware + licensingPer-user subscription

ZTNA Products

ProductTypeKey Feature
Cloudflare AccessCloudIntegrated with CDN, WAF
Zscaler Private AccessCloudGlobal presence, SSE platform
Perimeter 81CloudSimple setup, good for SMB
TwingateCloudDeveloper-friendly, open-source core
NetFoundryCloudOpen-source Ziti project
TailscaleCloudBased on WireGuard, mesh networking
Appgate SDPOn-prem/CloudMature SDP vendor

VPN Security Checklist

Immediate (fix today):
└─ Enable MFA on ALL VPN connections
└─ Disable inactive/orphan VPN accounts
└─ Review VPN connection logs for anomalies
Short-term (this quarter):
└─ Enforce device posture checks (OS patch, AV, disk encryption)
└─ Implement certificate-based auth
└─ Deploy VPN with split tunnel for general users, full tunnel for sensitive roles
└─ Set up VPN concentrator high availability
Medium-term (this year):
└─ Migrate from legacy protocols (PPTP, L2TP) to WireGuard or OpenVPN
└─ Implement anomaly detection on VPN logins
└─ Consider ZTNA for high-risk or privileged access
Advanced:
└─ Deploy ZTNA as VPN replacement for all users
└─ Implement continuous authentication (beyond initial login)
└─ Zero standing privileges — JIT (just-in-time) VPN access

Key Takeaways

  • VPNs create encrypted tunnels but typically grant full network access — this is the fundamental security weakness exploited in the Colonial Pipeline attack ($4.4M ransom paid)
  • WireGuard is the modern VPN standard — simpler, faster, and more secure than IPsec or OpenVPN
  • Split tunneling improves performance but bypasses corporate security inspection — use full tunnel for sensitive roles
  • MFA is non-negotiable for VPN access — credential-stuffed VPN accounts were the entry vector for Colonial Pipeline, and dozens of other breaches
  • ZTNA is the evolution: grant access to specific applications, not to the entire network — this eliminates lateral movement as a concern
  • Orphan accounts (old/unused VPN accounts) are a common blind spot — the Colonial Pipeline breach used an old account
  • Certificate + MFA + device posture check provides defense-in-depth for remote access authentication
  • VPN logs are underutilised — anomaly detection on login times, locations, and devices can detect compromised credentials
  • The TSA now mandates MFA for all critical infrastructure remote access — this will become the standard across all industries