Please refernece below the text of a case currently open with TAC. It describes the situation we're experiencing:
Problem Description: TCP Connection appears to hang. Entry in SHO CONN shows aging at 2+hrs, no activity. Source port 1026 dest port 1478. Sniffers on both sides sho inbound from p1026 to p1478 (SYN requests), and packet making it through firewall to INSIDE, hits the SNA Gateway, and Gateway repsonds to device as appropriate with SYN ACK. THIS RESPONSE NEVER gets through firewall back to end desktop. If we wait for TCP idle to tear down, connection comes up, or we artificially make it use a different port and connection is sucessful.
My main question is how can part of this connection through the firewall work yet the return side is blocked ?
I've searched till I'm blind and cant find anything directly related on your website. Help !
our main problem here is that for whatever reason the client hangs, our user power cycles pc, or power failure occurs. Our TCP CONN is set at 3 hours and open connections to ports 1477,1478 remain from this particular client.
Based on the PC being reset (and not cleanly so app/ip stck doesnt clean up by issuing FIN or RST) and the client being reloaded, the SYNs come from the same source port. As mentioned above, 6.1.2 lets the inbound SYN through, the gateway responds (I have a problem with that as well, a device responded to a new SYN request on a connection already active) with SYN ACK, but firewall blocks outbound response. The behavior changes in 6.2.2 whereby the PIX blocks the inbound request.
Our main problem is that the gateway appears to not clean up dead connections, or at least we havent found a way for it to by changing parameters either in OS or SNA portion. WE either have to have the user restart the app multiple times to increment the source port so a new connection will establish, or wait for the connection to timeout in the PIX. At three hours, this isnt going to work for us very well (and yes I know I can trim the idle timeout but our exposure there is that we have other apps that do not do ANY type of keepalive, yet they walk away from their desktop with app running [lunch] and expect to be able to get right back in and if we trim the timer we would kill the current, and force them to restart the app).
Sorry for the extremely long post, but wanted all the details out there. I appreciate anyone who takes the time to at least read this ;-). Hopefully someone has encountered something similar and can offer fix/workaround.
Thanks again !!!