At the moment we can make the control connection but when we issue commands the connection times out.
Looking at the logs we can see the initial connection made to the server on port 21 from the client, this is also seen on the second firewall context (nearest the FTP server). The data channel is then seen on the first context, made using high src & dst port numbers and initiated from the client, successfully passing the ACL/Inspection, then on the second context we see the connection being denied by the incoming ACL on the second contexts interface connected to the VRF instance.
The rules are identical on the contexts and have been made by copying and paste the rule using CSM, we are using the predefined service group 'FTP-Group' which contains both tcp 20 & 21. FTP inspection is at default on both contexts.
We have tested with Win XP (capable of Active FTP only) & Firefox 3.6.12 which is the connections we are seeing in the logs trying to do Passive FTP.
Is this a problem with teh contexts randomizing sequence numbers or TCP Normalization? Or do we just have a problem with the Inspection engine on one of the contexts (I would have expected to see this on both contexts if it was a bug).
Any help gratefully received as it is doing my nut in.
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...