Dan,

Check the Firewall logs to see if the IP address of the data connection is
the same as the server.  I had a problem similar to this and found that the
vendor had two IP addresses assigned to their FTP server interface and the
server was trying to use the second address for the data connection.  The
firewall rejected it because it didn't match the control connection IP.

-- Bill Stackpole, CISSP

----- Original Message -----
From: "Daniel Crichton" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 26, 2002 7:40 AM
Subject: Passive FTP and NAT/PAT with PIX and Serv-U


> 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

Reply via email to