One-Way IPsec Traffic Between NSF and FortiGate? Check Your Security Policy Zones First
  

George Fady Lv2Posted 2026-Aug-11 21:32

Tunnel shows UP on both ends, Phase 1/2 fine, but traffic only flows one direction — FortiGate can ping into our NSF network, but NSF can't reach the FortiGate LAN at all (100% packet loss on ping, 26/26 dropped). Classic "tunnel's up, so why isn't it working" case. Here's what it actually was.
  
Root cause: a Network Security Policy misconfiguration on the NSF (model NSF-1050A-I, v8.0.107.1606). We had two policies — "VPN-LAN" and "LAN-VPN" — and the second one, which was supposed to allow LAN → VPN traffic, was accidentally configured identically to the first one (Src Zone = VPN, Dst Zone = LAN) instead of the correct Src Zone = LAN, Dst Zone = VPN. So nothing permitted traffic leaving the LAN zone toward the VPN zone, and it fell through to the default-deny rule at the bottom. Confirmed via the policy list — 0 hit count and a warning flag sitting right on that policy.
  
Our diagnostic order (useful checklist for any one-way tunnel issue):
  

  • Security Policy — explicit allow rule needed: Src = internal LAN, Dst = zone containing the VPN tunnel interface (VPNTUN), placed above any deny rules (NSF matches top-down).

  • NAT exemption — make sure your general internet-access SNAT rule isn't also translating traffic headed for the remote LAN, which would push it out the WAN instead of the tunnel. Add a "Do Not Use Source NAT" exemption above the general rule.

  • Route Testing (Network → Routing) — check nothing static/policy-based is overriding the auto-generated IPsec route. NSF's priority order: Direct > Policy-Based > SSL VPN > IPsec VPN > Static/Dynamic > Default.

  • IPsec packet counters (Network → VPN Status) — flat encrypt counter = policy/NAT/routing problem on your side; encrypt climbing but decrypt flat = look at the peer's return path instead.

  • If still stuck, System → Troubleshooting → Troubleshooting (software bypass) for the destination IP isolates whether it's a security policy or something further upstream.

  
Fixing the zone direction on Policy #2 resolved it immediately — customer confirmed bidirectional reachability on retest.

This topic contains more resources

You must log in to download or view the file. Not registered yet? Register

x

Like this topic? Like it or reward the author.

Creating a topic earns you 5 coins. A featured or excellent topic earns you more coins. What is Coin?

Enter your mobile phone number and company name for better service. Go

Humayun Ahmed Lv4Posted 2026-Aug-12 13:04
  
Thanks to share!