PCNSE Secure Access and VPN Practice Question
Which THREE troubleshooting steps should be taken when a site-to-site VPN tunnel is up but no traffic passes?
⚠ Common exam trap
It's easy for candidates to assume a tunnel being 'up' guarantees traffic flow, but the PCNSE exam tests that you must separately verify routing, security policies, and proxy IDs—each of which can block traffic independently of the tunnel's control-plane state.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Verify the routing table on both firewalls.
Option A is correct because when a site-to-site VPN tunnel is up but traffic does not pass, the most common cause is a missing or incorrect route on one or both firewalls; verifying the routing table ensures that traffic destined for the remote subnet is directed into the tunnel interface rather than out a default or wrong interface. Option B is correct because firewall policies (security rules) must explicitly permit traffic between the local and remote tunnel zones; even with a healthy IPSec SA, an implicit deny or missing allow rule for the tunnel zone will silently drop packets. Option D is correct because proxy IDs (traffic selectors) define which source/destination subnets are permitted through the tunnel, and if the local and remote peers have mismatched proxy IDs, Phase 2 may appear up while traffic for the actual subnets is dropped or not encrypted. Option C is not correct because increasing the IPSec SA lifetime only affects how often keys are renegotiated and does not resolve a no-traffic condition when the tunnel is already established. Option E is not correct because placing the tunnel interface in a virtual router is a design/configuration choice, not a troubleshooting step, and a tunnel can pass traffic without being bound to a virtual router.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Verify the routing table on both firewalls.
Why this is correct
A tunnel can be up while traffic fails because no route directs packets into the VPN. Verifying the routing table on both firewalls confirms that remote subnet routes point to the tunnel interface, satisfying the stem's requirement.
- ✓
Check the firewall policies for the tunnel zone.
Why this is correct
Even with the tunnel established, security policy must permit traffic between the tunnel zone and the destination zone. If no rule allows the VPN zone as source or destination, the firewall silently drops packets, producing exactly the up-but-no-traffic symptom.
- ✗
Increase the IPSec SA lifetime.
Why it's wrong here
IPSec SA lifetime governs rekeying frequency, not traffic forwarding; raising it changes nothing when the tunnel is already up. Mismatched proxy IDs, missing routes or security policy blocks cause silent drops. Lifetime tuning suits environments experiencing frequent rekey failures or renegotiation instability.
- ✓
Verify the proxy IDs on both peers match.
Why this is correct
Proxy IDs define which subnets each peer permits through the tunnel. If they mismatch, Phase 2 selectors fail to align, so traffic is dropped despite the tunnel showing as up. Verifying both peers' proxy IDs directly resolves this constraint.
- ✗
Ensure the tunnel interface is placed in a virtual router.
Why it's wrong here
Placing the tunnel interface in a virtual router is a mandatory configuration step, not a troubleshooting action for an established tunnel. When the tunnel is up but traffic fails, the fault lies in proxy IDs, routing or security policy. Interface-to-virtual-router binding matters during initial setup.
Visual reference
Quick reference
VPN Protocol Comparison
| Protocol | Port | Encryption | Authentication | Use Case |
|---|---|---|---|---|
| IKEv2 / IPsec | UDP 500 / 4500 | AES-256 | Certificates / PSK | Site-to-site & remote access |
| SSL / TLS VPN | TCP 443 | TLS 1.3 | Certificates / MFA | Clientless remote access |
| L2TP / IPsec | UDP 1701 | AES (IPsec) | PSK / Certificates | Legacy remote access |
| WireGuard | UDP 51820 | ChaCha20 | Public keys | Modern high-performance VPN |
| PPTP | TCP 1723 | MPPE (weak) | MS-CHAPv2 | Legacy — avoid in production |
PPTP is considered insecure. IKEv2/IPsec and SSL VPN are the current recommended options.
Go deeper
Related to this question
About these practice questions
One of 319 original PCNSE practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCNSE practice question is part of Courseiva's free Palo Alto Networks certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCNSE exam.