When an IPsec VPN Tunnel is UP, Don't Assume the Problem Is the VPN
  

George Fady Lv2Posted 2026-Jul-24 16:32

As a Technical Support Engineer, I recently worked on a customer case involving a Sangfor NSF connected to a FortiGate firewall through an IPsec VPN.
The customer reported that the VPN tunnel was successfully established, but communication only worked in one direction.
Symptoms:

  • IPsec tunnel status was UP.

  • Phase 1 and Phase 2 negotiations completed successfully.

  • The FortiGate side could reach the Sangfor LAN.

  • The Sangfor side couldn't reach the FortiGate LAN.

At first glance, it looked like an IPsec issue. However, an established tunnel only confirms that the negotiation has succeeded—it doesn't guarantee that traffic is actually reaching the tunnel.
Instead of changing the VPN configuration, I followed a structured troubleshooting process:

  • Verify the Security Policy

      Confirm that a LAN → VPN allow policy exists.
      Check the policy order, since Sangfor evaluates policies from top to bottom.

  • Review Source NAT

      Ensure Internet SNAT policies aren't matching VPN-bound traffic.
      Configure a No-NAT rule when necessary.

  • Validate Route Selection

      Use Route Testing to verify that packets are choosing the IPsec route instead of a WAN interface.

  • Monitor IPsec Counters

      If the encrypt counter doesn't increase, traffic never reaches the tunnel.
      If encrypt increases but decrypt doesn't, the issue is likely on the remote firewall.

Root Cause
After reviewing the customer's configuration, I found that the LAN → VPN security policy had its source and destination zones reversed. Because of that, outbound traffic matched the default deny rule before it could enter the IPsec tunnel.
Correcting the policy immediately restored bidirectional communication, and the customer confirmed the issue was resolved.
Technical Tip:
When an IPsec VPN is established but traffic only works in one direction, don't start by rebuilding the tunnel. Verify the packet path first:
Security Policy → NAT → Routing → Tunnel Counters
A systematic troubleshooting methodology saves time, avoids unnecessary configuration changes, and helps identify the actual root cause much faster.
Has anyone else encountered a VPN issue where the tunnel was healthy, but the real problem was somewhere else in the packet flow?

This topic contains more resources

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

x
Humayun Ahmed Lv4Posted 2026-Jul-24 17:25
  
Thanks to share!
ASpen Lv2Posted 2026-Jul-25 13:10
  
Thank you for sharing