Yeah PAT(and NAT) allocate xlation slots based on client ports, this can be a problem with FTP more specificaly the PORT commands. Use Fixup.
At 03:40 PM 3/26/2002 +0000, Daniel Crichton wrote: >I'm not sure how on-topic this is going to end up, but I've got a real >problem with passive FTP and one hosting provider. I'm using WS_FTP to >connect to their FTP server (Serv-U v3) and as I'm inside a PIX here using >PAT for outgoing connections I have WS_FTP set to use passive mode. This >is just not working ... the hosting provider have even moved the account >to a new server, and it still doesn't work. Passive mode does work from my >home machine, so that makes it look like PAT is the problem, and a static >NAT may be the solution, although I don't want to use up another public IP >from my already limited range just to enable FTP with this one provider. I >can connect to other FTP servers using passive mode from this machine, n >fact one of them is our sister company who also use Serv-U v3 and they >have a PIX using a static NAT at their end. For the server that I can't >connect to the hosting company assure me that there is nothing configured >on their firewall to prevent the outgoing connection from my machine here >from getting to their FTP server, and the fact that passive mode works >from home where I don't have NAT (using ADSL USB modem direct) suggests >that something in the packets being passed from my PC here to their server >contains the internal address here, and something in their Serv-U >configuration is trying to match that IP on the incoming connection to the >open data port on their server which fails as the address is being changed >via the PAT. I've tried logging packets with snort and I can see the >commands being passed correctly, but I don't know enough about the extra >packet information to determine if the internal address is being passed >out in the FTP commands too. And as a last resort I even tried other FTP >clients (W2K command line FTP, CuteFTP) and they won't open the data >connection either. Everything comes down to the hosting provider's FTP >server, but they don't know why it won't work. > >So I have a couple of questions: > >1). Does anyone know if there is an option in Serv-U to provide enhanced >security by requiring a port and IP match on the incoming data connection >based on the packet header in the initial connection? > >2). Is there any way to tell WS_FTP or CuteFTP what the machine's IP will >be on the outside of the PIX so that if it is somehow encoded into the >packets it will use the one that the FTP server will see? Or another FTP >client that can do this? > >3). Is there something I can set on the PIX (515UR running 5.3.1) to >handle any additional translation of IP information needed in outgoing FTP >connection packets? > >I really hope someone can help, or else it looks like I'm going to end up >having to find a spare machine to plug in outside the firewall just to >handle these FTP transfers which I really don't want to do! > >Dan >--- >D.C. Crichton email: [EMAIL PROTECTED] >Senior Systems Analyst tel: +44 (0)121 706 6000 >Computer Manuals Ltd. fax: +44 (0)121 606 0477 > >Computer book info on the web: > http://computer-manuals.co.uk/ >Want to earn money? Join our affiliate network! > http://computer-manuals.co.uk/affiliate/ > >_______________________________________________ >Firewalls mailing list >[EMAIL PROTECTED] >http://lists.gnac.net/mailman/listinfo/firewalls _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
