Can you share any Suricata logs generated for this traffic? Would also be good record a pcap to see if that gives any clues.

Hello Victor,

I sent you the requested packet captures via email (I don’t want to share them publicly). I’m not sure which Suricata logs might be helpful. As far as I could see when looking through them, there wasn’t really anything that stood out or seems related to this request.

This issue only occurs when divert-to is used on a WAN-side pf rule, i.e., when the passing traffic is still encrypted.
If I add the divert-to setting to the rule from the reverse proxy to the web server (where traffic is unencrypted) instead, the request works correctly and the eve logging shows:

{"timestamp":"2026-03-14T09:47:41.161486+0100","flow_id":1411451134062175,"event_type":"http","src_ip":"ip.from.reverse.proxy","src_port":54814,"dest_ip":"ip.from.web.server","dest_port":8080,"proto":"TCP","ip_v":4,"pkt_src":"wire/pcap","tx_id":0,"http":{"hostname":"example.com","url":"/","http_user_agent":"axios/0.30.3","xff":"::ffff:ip.from.requesting.host","http_content_type":"text/html","http_method":"GET","protocol":"HTTP/1.1","status":200,"length":123929,"request_headers":[{"name":"accept","value":"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"},{"name":"user-agent","value":"axios/0.30.3"},{"name":"host","value":"example.com"},{"name":"x-forwarded-proto","value":"https"},{"name":"x-forwarded-for","value":"::ffff:ip.from.requesting.host"}],"response_headers":[{"name":"Date","value":"Sat, 14 Mar 2026 08:47:41 GMT"},{"name":"Server","value":"Apache/2.4.66 (Debian)"},{"name":"X-Powered-By","value":"PHP/8.3.30"},{"name":"Link","value":"<https://example.com/wp-json/>; rel=\"https://api.w.org/\""},{"name":"Vary","value":"Accept-Encoding"},{"name":"Transfer-Encoding","value":"chunked"},{"name":"Content-Type","value":"text/html; charset=UTF-8"}]}}
{"timestamp":"2026-03-14T09:47:48.431785+0100","flow_id":1133209534922269,"event_type":"http","src_ip":"ip.from.reverse.proxy","src_port":35892,"dest_ip":"ip.from.web.server","dest_port":8080,"proto":"TCP","ip_v":4,"pkt_src":"wire/pcap","tx_id":0,"http":{"hostname":"example.com","url":"/robots.txt","http_user_agent":"Uptime-Kuma/2.2.1","xff":"::ffff:ip.from.requesting.host","http_content_type":"text/plain","http_method":"GET","protocol":"HTTP/1.1","status":200,"length":168,"request_headers":[{"name":"accept","value":"text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9"},{"name":"user-agent","value":"Uptime-Kuma/2.2.1"},{"name":"host","value":"example.com"},{"name":"x-forwarded-proto","value":"https"},{"name":"x-forwarded-for","value":"::ffff:ip.from.requesting.host"}],"response_headers":[{"name":"Date","value":"Sat, 14 Mar 2026 08:47:48 GMT"},{"name":"Server","value":"Apache/2.4.66 (Debian)"},{"name":"X-Powered-By","value":"PHP/8.3.30"},{"name":"X-Robots-Tag","value":"noindex, follow"},{"name":"Link","value":"<https://example.com/wp-json/>; rel=\"https://api.w.org/\""},{"name":"Vary","value":"Accept-Encoding"},{"name":"Content-Length","value":"168"},{"name":"Content-Type","value":"text/plain; charset=utf-8"}]}}

The PR above puts sendto into a loop, however its not confirmed if that is the actual issue. If sendto was failing, Suricata should log a warning:

SCLogWarning("Write to ipfw divert socket failed: %s", strerror(r));

Another theory is that the socket buffer, for receiving packets into Suricata is not large enough for bursts of traffic, which I think defaults just a bit over 64k.

I gave my robot a Proxmox lab to deploy and test OPNsense end-to-end. It confirmed my suspicion that sendto is not the issue, however still needs further review.

On OPNsense, PF RDR/NAT and the FreeBSD divert path can present the two directions of one TCP connection to Suricata under different 5-tuples. The request is seen with the translated internal destination, while the response is seen with the public address as its source. The divert API does not provide the original PF tuple or a PF state identifier, so Suricata cannot safely associate the packets as one bidirectional flow. The response therefore reaches the TCP stream engine as a one-sided flow without handshake or session state.

A sessionless ACK packet containing payload is normally allowed, but adding FIN to that same packet sends it through the fin_but_no_session error path. In inline mode with stream.drop-invalid enabled, Suricata does not reinject the packet, truncating the response when the final body data and FIN are coalesced. This was reproduced with the untouched OPNsense configuration. Direct routing without NAT passed, PF RDR passed when diversion was disabled, and enabling midstream with async-oneside did not resolve the failure.

The smallest tested fix retains the fin_but_no_session event but avoids treating the packet as a stream error when it has ACK, contains payload, has no SYN, and differs from an otherwise accepted sessionless data packet only by also carrying FIN. Pure FIN, SYN+FIN, and RST packets remain on the existing error path. The change passed a base-failure -> candidate-success -> base-failure -> candidate-success sequence on OPNsense.

diff --git a/src/stream-tcp.c b/src/stream-tcp.c
index 47ca5a7bd..7245a4f73 100644
--- a/src/stream-tcp.c
+++ b/src/stream-tcp.c
@@ -1209,6 +1209,15 @@ static int StreamTcpPacketStateNone(
         if (!stream_config.midstream || p->payload_len == 0) {
             StreamTcpSetEvent(p, STREAM_FIN_BUT_NO_SESSION);
             SCLogDebug("FIN packet received, no session setup");
+
+            /* A no-session ACK carrying payload is already allowed through this state. In inline
+             * mode, do not turn the same untracked payload into a stream-error drop solely because
+             * it also closes the sender side. Keep pure FIN and SYN+FIN packets on the existing
+             * error path. */
+            if (!stream_config.midstream && StreamTcpInlineDropInvalid() &&
+                    (tcph->th_flags & TH_ACK) && !(tcph->th_flags & TH_SYN) && p->payload_len > 0) {
+                return 0;
+            }
             return -1;
         }