Please reference the below text from an open case with TAC. Any ideas on how to address this ? The MS g/w NEVER sends TCP RST out. Only way connection can be re-established (at least from same source port on remote client) is to wait for TCP IDLE to kill the connection in the PIX. Then we can
SYN SYN ACK no problem. Anyone know of any settings in Microsoft SNA Gateway to cause it to kill an IDLE session ? Whats really weird, and as indicated below, is that on 6.1.2 the PIX passes the SYN request, the gateway responds with SYN-ACK but thats blocked by PIX outbound. I guess I'm a little baffled as to why the darn gateway would respond to a SYN request to the same port from the same port on which it already has a connection in the Gateway. I might add that this scenario is caused by either the app hanging on client end and user is power resetting the box, or a power failure occurs while app is up.
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 ?
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...