Hello,
Thank you very much. I made prefilter and i have same situation. I capture traffic on my inside interface, when traffice come from outisde to indside.
i dont know why this TCP Retransmision happen, because i made prefiler where i allowed everyting to FTP server.
@MHM Cisco World thank you very much.
i configure prefilter inside to outside and outsdie to inside , picture below. i can see hitts.
i would like to add that i make source and destionation NAT in my side. that is reason why i have two ip address 192.168.1.28 is my real IP address, then i make source NAT to 10.5.6.28
@faruk.zaimovic, long time ago I wrote this: In the fpr1140-mo-node1-capture_test.pcap capture we see "227 Entering Passive Mode (10,5,6,28,218,137).\r\n". The capture was collected on the inside interface of the firewall, i.e. before any packet processing done by the firewall. This means that the 10.5.6.28 IP in the PASV reply is incorrect. It should have been 192.168.1.28, i.e. the real IP address the server runs on. FTP inspect on the firewall sees that this IP address doesn't match transport IP address of the packet (192.168.1.28) and drops it as expected.
192.168.1.0/24-my local LAN(First Location)-------FPR1140----------Internet------ FPR1140-----Remote LAN(Second Location) 192.168.1.2
> show running-config nat
nat (outside,inside) source static FMF-SERVER-3-192.168.1.2 FMF-SERVER3-SEEN-FROM-FMF-10.200.200.3 destination static LFILKA-SEEN-FROM-FMF-10.5.6.28 LFILKA-192.168.1.28
So, once again, host 192.168.1.2 ("Second Location") opens FTP connection to 10.5.6.28 and then user either tries to download a file or enters "dir". 192.168.1.2 sends "PASV" command. This can be seen in both captures above. The request is NATed on the "First Location" firewall. SrcIP 192.168.1.2 is translated to 10.200.200.3 and DstIP is translated to 192.168.1.28. So far, so good. The server responds with a PASV Reply and we can see it in the 1st capture: "227 Entering Passive Mode (10,5,6,28,218,137).\r\n". However, the reply is absent in the 2nd capture on the "Second Location" firewall. The retransmission is actually the same PASV command on the "Second Location" firewall and the same PASV Reply on the "First Location" firewall.
Is above description correct?
The 1st capture, where the PASV reply is seen, was collected on the inside interface of the "First Location" firewall, right? You used "capture" command in the firewall CLI, right?
Now tell us, how's that possible that the server 192.168.1.28 knows about 10.5.6.28 address to announce this address in its PASV reply?
Shouldn't the server respond with its real IP address 192.168.1.28 instead of 10.5.6.28?
Once again, if the firewall sees that IP address in the PASV reply (10.5.6.28 in this case) is different from the transport IP address (192.168.1.28), it drops the packet and sends TCP RST back. This is a function of ASA/Lina "inspect" feature. Playing around with ACP vs Pre-filter policies won't change this behavior whatsoever and the packet will still be dropped by the inspect. The reason is: "inspection" is a feature of underlying Lina (ASA code) and ACP is distributed between ASA/Lina and Snort. The FTD is NOT an integrated system, meaning that despite so many efforts and years of development it still consists of two loosely coupled parts.
You cannot disable the "inspect" which drops the packet, because you do NAT. You need to think and answer questions above to solve this problem.
