IPsec VPN Tunnel Established But Traffic Not Passing
A network administrator is troubleshooting an IPsec VPN tunnel between two FortiGate devices. The tunnel is established, but traffic is not passing. Which configuration should the administrator check first?
Quick Answer
The answer is firewall policies. When an IPsec VPN tunnel is established but traffic is not passing, the most common root cause is missing or misconfigured firewall policies, not the VPN configuration itself. Even with perfectly negotiated Phase 1 and Phase 2 settings, a FortiGate uses stateful inspection, meaning it will not forward any traffic between the tunnel interface and the destination network unless an explicit policy permits it. On the Fortinet NSE 7 Advanced Security NSE7 exam, this concept tests your understanding that a VPN tunnel is merely a secure transport layer; it does not automatically authorize traffic flow. A common trap is to immediately recheck Phase 2 selectors or routing, but the exam emphasizes that policy inspection is the gatekeeper. Remember the memory tip: “Tunnel up, traffic stuck? Check the policy first, not the crypto.”
⚠ Common exam trap
Test-takers frequently assume a working Phase 1 and Phase 2 automatically allows traffic, but FortiGate requires explicit firewall policies to permit traffic through the tunnel, unlike some other vendors where the VPN configuration itself implies a permit.
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
✓
Firewall policies
When an IPsec VPN tunnel is established but traffic does not pass, the most common cause is missing or misconfigured firewall policies. Even with correct Phase 1 and Phase 2 settings, the FortiGate will not forward traffic between the tunnel interface and the destination network unless an explicit firewall policy permits it. This is because FortiGate uses a stateful inspection model where all traffic must be allowed by a policy, regardless of the VPN being up.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Firewall policies
Why this is correct
Firewall policies govern whether traffic is permitted through the tunnel; an established IPsec tunnel with no passing traffic typically indicates missing or misordered policies blocking the interesting traffic. FortiGate requires explicit policies permitting traffic between the VPN interfaces, so checking these first addresses the stem's constraint of a tunnel that is up but not forwarding data.
- ✗
NAT traversal configuration
Why it's wrong here
NAT traversal only matters when a device sits behind a NAT gateway and the tunnel fails to establish; here the tunnel is already up, so NAT-T has done its job. It is tempting because NAT-T is a common IPsec pitfall, but it governs IKE negotiation, not whether traffic traverses an established tunnel.
- ✗
Static routes
Why it's wrong here
Static routes matter only when the tunnel fails to establish or selectors mismatch; here the tunnel is up, so the fault lies in policy, phase 2 selectors or routing within the tunnel. Checking static routes is tempting because route lookups commonly break VPN traffic, and it would be right if the tunnel were down or traffic egressed the wrong interface.
- ✗
Phase1 parameters
Why it's wrong here
Phase1 parameters govern IKE SA negotiation; if they mismatched, the tunnel would not establish at all. Since the tunnel is up, Phase1 has already succeeded, so it cannot explain the traffic failure. It is tempting because Phase1 mismatches are a classic IPsec fault, but they produce establishment failures, not silent drops.
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 718 original NSE7 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 →
Same concept, more angles
3 more ways this is tested on NSE7
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A network administrator is troubleshooting an IPsec VPN tunnel between two FortiGates. The tunnel is up but traffic is not passing. The administrator runs 'diagnose vpn ike gateway list' and sees that the IKE SA has been established. However, 'diagnose vpn tunnel list' shows no IPsec SA entries. What is the most likely cause?
medium- A.The firewall policies are not configured to allow traffic through the tunnel
- ✓ B.The phase 2 proposal (encryption, authentication, etc.) does not match between peers
- C.The pre-shared key on both sides does not match
- D.The interface MTU is set too low
Why B: If the IKE SA is established but no IPsec SA entries appear in 'diagnose vpn tunnel list', the most likely cause is a Phase 2 proposal mismatch. Phase 1 (IKE SA) negotiates the secure channel, while Phase 2 (IPsec SA) negotiates the actual tunnel parameters. If the encryption, authentication, or other Phase 2 settings do not match, the IPsec SA will fail to establish, even though Phase 1 is up.
Variation 2. A network administrator is troubleshooting an IPsec VPN tunnel between two FortiGates. The tunnel is established but traffic is not passing. The administrator runs 'diagnose vpn ike log' and sees 'no matching policy for this IPsec SA'. What is the most likely cause?
medium- A.The phase2 selectors do not match between peers
- ✓ B.There is no firewall policy allowing traffic from the local network to the remote network via the VPN tunnel interface
- C.The pre-shared key is mismatched
- D.The tunnel interface is administratively down
Why B: The log message 'no matching policy for this IPsec SA' on a FortiGate means the IKE/IPsec SA was negotiated successfully but no firewall policy matches the traffic that needs to traverse the tunnel. In FortiOS, a firewall policy with the tunnel interface as the outgoing interface (and matching source/destination) is required for traffic to be encrypted and forwarded. Without it, the tunnel stays up but no data flows.
Variation 3. An administrator is troubleshooting an IPsec VPN tunnel between two FortiGates. The tunnel is up, but traffic is not passing. The administrator runs 'diagnose vpn tunnel list' and sees that both phase 1 and phase 2 are up. The policy allows traffic from both sides. What should the administrator check next?
medium- ✓ A.Check the routing table for routes to the remote subnet
- B.Increase the phase 2 keylife
- C.Check the FortiGate's NTP status
- D.Disable DPD
Why A: If both IPsec phases are up and policies allow traffic, the next most likely issue is missing or incorrect routing. Without a route to the remote subnet pointing to the IPsec tunnel interface, the FortiGate will not send traffic into the tunnel, even though the tunnel is established. Checking the routing table is the logical next step.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This NSE7 practice question is part of Courseiva's free Fortinet 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 NSE7 exam.