<div dir="ltr">Hi J Carter,<div><br></div><div>Thank you so much for your suggestions, I did tcpdump concurrently on both nginx and client app host as well and able to find out that F5 device in between is sending out RST to both side. Now i am able to exclude Nginx's configuration as part of the investigation. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 22, 2024 at 1:46 AM J Carter <<a href="mailto:jordanc.carter@outlook.com">jordanc.carter@outlook.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
On Tue, 20 Feb 2024 11:57:27 +0800<br>
Kin Seng <<a href="mailto:ckinseng@gmail.com" target="_blank">ckinseng@gmail.com</a>> wrote:<br>
<br>
> Hi J Carter,<br>
> <br>
> Thank you for your reply.<br>
> I am capturing the packet from firewall, and the filtering is as per below<br>
> for the previously attached pcap.<br>
<br>
I see, I assumed you had run tcpdump on the nginx<br>
host. I'd reccomend doing that too then (as well as client app host) if<br>
you have a network firewall in the mix - to see what nginx itself<br>
truely sends/recieves.<br>
<br>
> Source : client app -- Dest : nginx proxy , any port to any port<br>
> <br>
> Source : public server -- Dest : nginx proxy , any port to any port<br>
> <br>
> Source : nginx proxy -- Dest : client app , any port to any port<br>
> <br>
> Source : nginx proxy -- Dest : public server , any port to any port.<br>
> <br>
<br>
It shouldn't be missing such data then - although again, this may be<br>
specific to the firewall itself.<br>
<br>
> Perhaps I will try to do tcpdump from the client app as well.<br>
> <br>
> One more info that I notice from client app host, from the netstat command,<br>
> it shows CLOSE_WAIT for the terminated session, it seems like close_wait is<br>
> the symbol that the closing is from external ( in this case client app is<br>
> connect to nginx proxy), is this right?<br>
<br>
close_wait on client would indicate that the other party initated<br>
connection close (sent the first FIN) - again, firewall makes me more<br>
skeptical, as it can have it's own timers for closing tcp connection /<br>
it's own logic.<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="https://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">https://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</blockquote></div>