Hi jcbr2002,
A couple of things to nail down before diving into a capture, and then the capture itself as the key diagnostic step.
1. Confirm the platform first
Before deciding whether hardware acceleration is even a factor: is this BIG-IP running on a physical appliance (with an ePVA/PVA ASIC - i5000/i7000/i10000/i11000/i15000 series, VIPRION blades, VELOS/rSeries) or on a Virtual Edition (VE)? VE has no ePVA chip at all, so if you’re on VE the whole PVA/ePVA acceleration angle can be ruled out immediately and we go straight to a software-path capture. If it’s physical hardware, it would also help to know what PVA Acceleration mode is set on the FastL4 profile (“show ltm virtual <name>” reports the live acceleration status per connection: None / Partial (Assisted) / Dedicated).
2. Take the capture with the nnnp modifier - this is the key step
Since the profile is default FastL4 with no SSL profiles involved (Performance L4 is pure L4 forwarding, so BIG-IP never terminates the TLS session), there’s no master secret or client-ssl/server-ssl handshake to capture - decryption doesn’t apply here and isn’t needed to diagnose an L4-level RST anyway. The reset is a transport-layer decision made by TMM, and F5’s internal tcpdump extension already exposes the exact reason inline:
tcpdump -ni 0.0:nnnp -s0 -w /var/tmp/capture.pcap host <client-ip>
0.0 captures across all VLANs at the TMM forwarding plane. nnn pulls the maximum noise level (low+medium+high internal TMM detail), which - since BIG-IP 11.2.0 - includes the Reset Cause field directly in the packet trailer. p follows the full end-to-end flow (client-side and server-side legs) even with SNAT in play, so you get both sides of the connection in one capture.
Since the RST happens mid-session (not at setup), start this capture before reproducing the failure and let it run through the exact moment the reset occurs, so that specific event’s Reset Cause lands in the trailer.
Once you have the pcap, open it in Wireshark, enable the f5ethtrailer dissector (Analyze > Enabled Protocols > f5ethtrailer), and inspect the Ethernet II trailer on the RST packet for the Reset Cause field, along with VIP name, flow id/peer id, and which TMM/slot handled it.
3. Optional cross-check via logs
If you also want the cause logged in plain text (handy if pulling the exact packet is inconvenient), temporarily enable:
tmsh modify sys db tm.rstcause.log value enable
tmsh modify sys db tm.rstcause.pkt value enable
then check /var/log/ltm and “tmsh show /net rst-cause” after reproducing. Disable both afterward - tm.rstcause.pkt embeds the cause string in the RST payload itself, which you don’t want left on in production.
4. Once you have the Reset Cause
Common causes worth ruling out given your setup (no idle timeout involved): “TCP RST from remote system” (BIG-IP is just relaying a reset that actually originated at the client or the next-hop/pool member - quite possible in a SNAT + single-gateway topology), “TCP retransmit timeout”, “TCP zero window timeout”, or “No flow found for ACK”. If the cause points at the hardware path and this turns out to be physical hardware with PVA Acceleration enabled, that’s when it’s worth temporarily setting PVA Acceleration to None on the FastL4 profile to force everything through software and see if the resets stop - that isolates whether ePVA offload is involved, but I’d treat it as a confirmation step after you have a cause, not a first move, since it has a performance cost.
Share the Reset Cause value (and platform type) once you have it and we can narrow this down further.