Hi,
We had a similar issue just a few weeks back. Our customer outsource thier
firewall to thier ISP and we use NAT for our server. Switching to passive
mode solved our problem as the server hands control over to the client
meaning the client initiates the data session on a not well known port
I had the same issue with another client.
The answer was 2 fold. There is a bug that is fixed on ver 6.2.2(100)
available from TAC - relates to PAT and FTP. Our particular problem was a
cache engine that proxied the connection so the PIX dropped it - found this
out from a packet sniff. For
Hi Vikram,
have tried connecting to the server using passive ftp ? I have
encountered bugs relating to PAT as Andrew mentioned. The workaround I
applied was to remove ip route-cache on the nat inside and outside
interface. This was temporary till the bug was fixed offcourse...
It could be a bug or it could just be that FTP is a huge pain to get working
with NAT and firewalls due to its behavior. Firewalls at either end,
including a personal firewall on the end system, can wreak havoc. Changing
to passive might help because then the server doens't try to open a session
4 matches
Mail list logo