Skip to main content
T
TarasWSI
New Member
June 16, 2026
Solved

FG-200F / FortiOS 7.4.12 - packet loss / stalls only when NAT-T is enabled (remote access IPsec/IKEv2)

  • June 16, 2026
  • 3 replies
  • 157 views

Hi all,

I’m troubleshooting a remote access IPsec issue on a FortiGate 200F running FortiOS 7.4.12 and wanted to see if anyone else has run into something similar.

When NAT-T is enabled, remote users get noticeable packet loss / stalls over the tunnel during normal traffic — pings, file transfers, throughput tests, that kind of thing. When NAT-T is disabled, it gets a lot better.

A few things I’ve already confirmed:

  • the tunnel comes up fine
  • the issue is reproducible when NAT-T is enabled
  • the issue improves significantly when NAT-T is disabled
  • I tested with NPU offload both enabled and disabled
  • with offload enabled, tunnel error counters were higher on the problematic tunnel
  • with offload disabled, those RX errors were much lower or zero in my captures, but the user-visible stalls still weren’t fully explained by the lower-level counters
  • PDQ snapshots looked balanced during testing
  • HPE dropping stayed at 0 in the snapshots I collected
  • anomaly-drop output was empty
  • we also contacted our ISP and they ruled out any issues on their side
  • this is not happening with just one VPN client — we’re seeing it across multiple VPN clients, so it does not look like a single client ISP / local connection problem

At this point I’m mostly trying to figure out if anyone else has seen FG-200F / SoC4 / 7.4.12 behave badly specifically with NAT-T enabled on IPsec, where the tunnel stays up and traffic partially works, but there are intermittent stalls or packet loss under load.

I already have a TAC case open, so I’m not trying to bypass support — just curious whether anyone else has seen the same pattern, or knows of a bug / workaround related to it.

Thanks.

Best answer by TarasWSI

UPDATE:
I think we found the root cause of our packet drops. We changed our configuration for WAN ports recently (set gateway as promiscious and other ports that connect to VDOMs - isolated PVLANs). Traffic probably started flowing more cleanly/direct than before, and we started to experience issues with MS Teams calls. We checked security logs on Fortigate and saw that our DoS policy was blocking UDP flood from MS Teams. Then we noticed that same occured to our VPN packets.. 
We created 2 rules for Teams and VPN and since then we're not experiencing any problems.

3 replies

AEK
SuperUser
AEK
SuperUser
June 17, 2026

Hi Taras

Try disable IPsec NPU offload and see if it helps.

AEK
christian_89_
christian_89_
Explorer II
June 17, 2026

A few things before chasing the offload toggle, since you have already tested that both ways.

Platform note first: the 200F is not SoC4. The FortiGate 200F runs an NP6XLite network processor with a CP9 content processor, and Fortinet's hardware acceleration guide explicitly excludes the 200F and 201F from the NP6XLite (SOC4) grouping, so the NP6XLite here is discrete. Use the np6xlite diagnostics, and when you and TAC check known issues, scope them to NP6XLite rather than SoC4. CadgulfAmazon Web Services

Why "disable NAT-T" is a clue, not a fix: for remote-access dial-up, NAT-T floats to UDP/4500 because clients sit behind NAT. You cannot leave it off in production for road warriors. So the fact that it improves with NAT-T off tells you the problem is in how the UDP-encapsulated ESP path is being handled, not that NAT-T itself is the cure. The symptom set you describe (tunnel stays up, small traffic mostly fine, stalls and loss under load, worse with offload on) points at two specific causes that your anomaly-drop / HPE / PDQ counters will not surface. That last part matters: those counters do not show anti-replay or ESP-sequence drops, which is very likely why your lower-level numbers did not explain the user-visible stalls.

Hypothesis A: MTU / fragmentation of the UDP-encapsulated ESP. NAT-T adds the UDP/4500 header on top of ESP, lowering the usable payload. Under load with full-size packets (file transfers, throughput tests) you start fragmenting the encapsulated traffic, and fragmented NAT-T+ESP is exactly where stalls and loss appear, while pings stay fine. Tests:

  • Clamp TCP MSS on the policies that ride the tunnel, start around 1300 and tune: set tcp-mss-sender and set tcp-mss-receiver. This alone removes the large-packet fragmentation for your TCP file transfers.
  • On phase1, enable pre-encryption fragmentation so the FGT fragments before encrypt instead of relying on post-encap IP fragmentation: config vpn ipsec phase1-interface then set fragmentation enable.
  • Sniff UDP/4500 on the WAN and watch for fragments and for ICMP "fragmentation needed" being dropped on the path. If your test traffic is mostly UDP, MSS clamping will not help and you are squarely in PMTU territory.

Hypothesis B: anti-replay drops from packet reordering under NPU offload. This fits your "higher error counters with offload on" observation. When ESP packets get reordered, the per-SA anti-replay window discards out-of-window packets, which produces precisely this "up but partially working, stalls under load" pattern. Reordering, for example from priority queuing, can slide the anti-replay window and cause valid packets to be dropped as replay failures, leading to retransmits and performance loss. There is a documented lineage of this in 7.4.x: a known IPsec packet-drop issue (bug ID 1003830) with disabling replay detection as the standard diagnostic lever, referenced in the 7.4.3 known-issues list. Tests: ciscoFortinet Community

  • Diagnostic only, not production: on the phase2, set replay disable, then re-run your load test. If the stalls vanish, it is replay/reordering. Keep replay enabled in production and push TAC on the reordering instead.
  • Related NP reordering knob: under heavy NP load the FGT can transmit packets out of order, and set delay-tcp-npu-session enable on the ingress firewall policy is the documented mitigation. Low risk to try. Amazon Web Services

Where to actually look (the counter gap): diagnose vpn tunnel list shows per-SA replay and ESP sequence error counters, and diagnose vpn ike gateway list for the gateway side. Watch the replay/esp error deltas during a load test. That is the data anomaly-drop and HPE will never give you.

For your TAC case, hand them: the per-SA replay/esp error deltas from diagnose vpn tunnel list under load, a WAN UDP/4500 capture showing fragmentation, and the A/B results of (1) MSS clamp and (2) temporary set replay disable. Then ask them to map it against the 7.4.12 NP6XLite IPsec known-issues, since the 7.4.x replay/offload drop pattern has prior bug history. That moves the case from "tunnel up but slow" to a specific reproduction much faster.

My money is on A driving the user-visible stalls (it tracks NAT-T on/off and load), with B explaining the elevated counters with offload on.

CFR_
T
TarasWSIAuthorAnswer
New Member
June 19, 2026

UPDATE:
I think we found the root cause of our packet drops. We changed our configuration for WAN ports recently (set gateway as promiscious and other ports that connect to VDOMs - isolated PVLANs). Traffic probably started flowing more cleanly/direct than before, and we started to experience issues with MS Teams calls. We checked security logs on Fortigate and saw that our DoS policy was blocking UDP flood from MS Teams. Then we noticed that same occured to our VPN packets.. 
We created 2 rules for Teams and VPN and since then we're not experiencing any problems.

    Terms & ConditionsAccessibility statement