VPN troubleshooting diagnoses failures in both remote access VPNs (users connecting from home) and site-to-site VPNs (connecting offices). CompTIA Network+ N10-009 tests VPN troubleshooting concepts — understanding common failure points (authentication, firewall blocking, phase negotiation, split tunneling issues) and the systematic approach to diagnosing them.
Practice this topic
Cannot connect to VPN: verify internet connectivity first (VPN requires internet access). Verify VPN gateway IP or hostname is correct. Check firewall: UDP 500/4500 (IPsec), TCP 443 (SSL VPN) must be permitted. Check authentication credentials (wrong username/password, expired password, locked account). Certificate expired or not trusted (for certificate-based auth).
Connected but cannot reach internal resources: check split tunneling configuration — if enabled, ensure corporate subnets are routed through the tunnel. Check DNS: VPN client may not be using internal DNS. Verify the VPN-assigned IP is in the correct IP range and has routing to internal networks. Check firewall rules on the VPN gateway — inbound traffic from VPN pool to internal servers.
VPN disconnects intermittently: NAT traversal (NAT-T) issues on UDP 4500 — some NAT devices drop idle UDP sessions. Enable NAT-T keepalives. ISP-level DPI blocking VPN traffic. DPD (Dead Peer Detection) — if enabled and the connection is dropped too aggressively, reduce DPD timeout.
Phase 1 (IKE) failure: IKE negotiation fails because parameters don't match. Check: both sides must have identical IKE version, encryption algorithm, hash, DH group, lifetime, and authentication method. Any mismatch causes Phase 1 to fail — the tunnel never forms.
Phase 2 (IPsec) failure: Phase 1 succeeds but Phase 2 fails. Check: transform set (encryption, hash) must match on both sides. Interesting traffic (proxy IDs / traffic selectors) must match — both sides must agree on what traffic is 'interesting' and should go through the tunnel. Asymmetric interesting traffic definitions prevent the tunnel from forming.
Tunnel up but no traffic: Phase 1 and 2 succeed, but traffic doesn't flow. Check routing: is there a route pointing traffic to the VPN tunnel interface? Check NAT: is NAT translating the tunnel traffic before it reaches the VPN? NAT exemption rules are needed to prevent NAT from modifying VPN traffic.
If Phase 1 succeeds, the VPN should work
Phase 1 only establishes the control channel (IKE SA). Phase 2 must separately negotiate the data channel (IPsec SA). Mismatched transform sets or traffic selectors cause Phase 2 to fail even when Phase 1 succeeds — the tunnel doesn't carry traffic until both phases complete
These questions are representative of what you will see on Network+ exams. The correct answer and explanation are shown immediately below each question.
An IPsec site-to-site VPN shows Phase 1 established but Phase 2 fails. Both sides have matching encryption and hash algorithms. What else should be checked?
Explanation: Phase 2 failure after Phase 1 success, with matching encryption/hash algorithms, most commonly indicates a mismatch in proxy IDs (traffic selectors) — the local and remote subnet definitions that determine what traffic goes through the tunnel. If Site A defines 10.1.0.0/24 → 10.2.0.0/24 but Site B defines 10.1.0.0/16 → 10.2.0.0/16, the selectors don't match and Phase 2 fails. PSK and IKE version affect Phase 1.
IPsec's AH and ESP protocols operate at IP layer and don't use TCP/UDP ports — NAT devices can't track them in state tables and may drop them. NAT-T encapsulates IPsec traffic in UDP port 4500, allowing it to traverse NAT devices. IKE auto-detects NAT in the path and switches to NAT-T mode. Most IPsec implementations enable NAT-T automatically. If a VPN works on direct internet but fails behind NAT, verify NAT-T is enabled and UDP 4500 is permitted.
Try free VPN Troubleshooting practice questions with explanations, topic links and progress tracking.