Suricata IPS: Fixing Legitimate Traffic Drops by Disabling drop-invalid

I encountered a peculiar issue where my WordPress instance was unable to reach wordpress.org, and DokuWiki could not access its plugin repository. All standard network checks (wget, curl, DNS) worked fine, and no drops were registered by the standard firewall rules.

However, logging revealed a problem deep within the Intrusion Prevention System (IPS) layer.

The Diagnostic: Stream Errors

I noticed an unusually high number of dropped packets related to stream errors in the stats.log:

ips.drop_reason.flow_drop | Total | 837
ips.drop_reason.rules | Total | 3398
ips.drop_reason.stream_error | Total | 19347

This confirmed that Suricata’s TCP Stream Engine was classifying legitimate traffic as invalid, causing the connection to stall before the application layer could proceed. The volume of stream_error drops was alarmingly high.

Further investigation into Suricata’s internal statistics revealed details about the nature of the errors:

stream.fin_but_no_session                     | Total | 12508
stream.rst_but_no_session                     | Total | 2577
stream.pkt_spurious_retransmission            | Total | 14735

These specific counters (FINs/RSTs without an active session, spurious retransmissions) point to common issues in asymmetric routing or session tracking in complex bridged/virtualized environments.

The Workaround: Disabling Strict Stream Enforcement

Based on community discussions regarding unexpected drops in IPS mode, I tested a key stream-configuration variable.

The default setting drop-invalid: yes instructs Suricata to immediately drop packets it deems invalid according to its internal state machine (often due to out-of-sync sequence numbers or timing issues).

The Fix: I set this directive to no.

stream:
  memcap: 64mb
  memcap-policy: ignore  
  drop-invalid: no # Set to 'no' to fix legitimate traffic drops
  checksum-validation: yes
  midstream-policy: ignore
  inline: auto
  reassembly:

As soon as I applied this change, the traffic to wordpress.org and the DokuWiki repository resumed functioning normally.

Conclusion: The Security Trade-off

While this workaround immediately solved the connectivity problem, I am consciously accepting a security trade-off. Disabling drop-invalid instructs the IPS to allow potentially ambiguous or invalid packets to pass.

• Risk: This allows a low-volume attacker to potentially use malformed packets to bypass the stream state-tracking.
• Benefit: It ensures Service Availability for crucial application updates and connections that the IPS was incorrectly flagging due to virtualization or network environment subtleties.

My next step will be to investigate the root cause of the high stream_error count to see if the error is caused by a kernel-level configuration or a misaligned network path.

Sources / See Also (Quellen)

1. Suricata Documentation. Stream Configuration and Settings (Specifically drop-invalid). https://docs.suricata.io/en/latest/configuration/stream.html
2. Suricata Documentation. Understanding and Analyzing the Stats Log. https://docs.suricata.io/en/latest/output/stats/stats-log.html
3. Suricata Documentation. IPS Mode and Traffic Drop Reasons. https://docs.suricata.io/en/latest/performance/ips-mode.html
4. OISF Community Forum. Discussion on high stream errors/spurious retransmissions and network offloading. (Diese Art von Diskussion ist der primäre Fundort für solche Workarounds).
5. Linux Manpage: ethtool. Documentation on Network Offloading (TSO, GSO, LRO) which often causes Suricata Stream issues.

---