GWLB TCP half-closed timeout

In addition to the answer of the re:Post Agent:

Silent Drops vs. TCP RST: When the GWLB idle timeout expires, it silently removes the flow from its table without sending a TCP RST to the endpoints. This explains why your firewall sessions "age out" instead of being closed immediately—the firewall is left waiting for a FIN/RST that never arrives through the GWLB.

Timeout Alignment: To avoid "non-SYN" noise, ensure your Firewall session timeout is shorter than the GWLB idle timeout (e.g., Firewall at 300s, GWLB at 350s). If the firewall closes the session first, it won't be surprised by delayed packets for a flow the GWLB has already forgotten.

Gateway Load Balancer tracks the state of TCP connections and manages them based on idle timeout settings. For TCP flows, GWLB has a default idle timeout of 350 seconds, which can be configured to any value between 60-6000 seconds.

When no data is sent through the connection by either the client or target for longer than the idle timeout period, the connection is closed and the flow is removed from GWLB's flow table. After the idle timeout elapses, GWLB considers the next TCP SYN packet as a new flow and routes it to a new target. However, data packets sent after the idle timeout period - including non-SYN TCP packets like FIN packets - are dropped.

This behavior can explain what you're observing. If one side of the connection closes (sends FIN) but the other side doesn't respond before the idle timeout expires, GWLB will remove the flow from its table. When the delayed FIN from the other side eventually arrives, it will be dropped as a non-SYN packet for a flow that no longer exists in GWLB's state table. This can result in the non-SYN TCP packets you're seeing at your firewalls.

To mitigate this issue, you can:

1. Configure TCP keepalive packets on your clients or targets to reset the idle timeout and keep connections active
2. Adjust the TCP idle timeout value on your GWLB listener to better match your application's timeout requirements
3. Ensure your applications have TCP timeout values that are shorter than or aligned with the GWLB idle timeout setting

The key point is that GWLB doesn't have a specific "half-closed" timeout - it relies on the general TCP idle timeout mechanism, which removes flows when no traffic is observed for the configured duration.
Sources
Gateway Load Balancers - Elastic Load Balancing
Update the TCP idle timeout for your Gateway Load Balancer listener - Elastic Load Balancing
Troubleshooting general issues in AWS Network Firewall - AWS Network Firewall