This sounds like the classic "port 20" problem. You don't indicate if this
is condition is true for all sites. We've had problems with Gauntlet only
when talking to Checkpoint firewalls. If so, you may need to dumb down and
use port 20; Checkpoint only supports data connections which have a source
port of 20; I don't know of any other firewall or system which has this
characteristic.
They indicated that port 20 is required in the RFC; I'm assuming in RFC 959
section 3.2 (incidentally, the same section indicates that they would be
required to support a port 20 (server) to port 21 (client) data connection
if a PORT command isn't issued. Rumor has it that one can configure their
firewall to allow the source port to float but, from what I've heard, if you
do that, then they won't support the firewall. I haven't spoken directly to
Checkpoint. Depending on how you read the standard, moving off source port
20 (server) might technically require a PASV command (for the server) and to
move off port 21 (client), a PORT command. I don't know of any
implementation which does this.
Note that if you use port 20, you are opening yourself up to "socket already
in use" problems if you use commands like MGET (that is, you open another
connection before the previous one has closed complete and the socket has
disappeared). Where we've had to allow port 20, those people complain that
consecutive data connections (ls, dir, get, put,...) randomly fail.
You don't need to create a filter, you need to hand-edit the netperm-table
file and add the following line before the GUI managed area:
ftp-gw: data-port 20
You can't set this in the GUI. This information is based on the UNIX
implementation of Gauntlet; I'm assuming that the NT implement works
similar.
Actually, from various RFCs dealing with "firewall-friendly" FTPs and such,
using PASV is better than using PORT. The reason for this is that, with
PASV, all the socket opens are from your internal systems to the external
one. This reasoning fails if 2 firewalls are talking to each other; one has
to accept an incoming socket connection, unless, of course, you don't allow
incoming FTP.
> -----Original Message-----
> From: Alexandre Vargas Rousseau Nunes [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, January 26, 2000 12:43 PM
> To: [EMAIL PROTECTED]
> Subject: Gauntlet 5.5 for NT - FTP problem
>
> Hi all,
>
> Does anyone have any information about a FTP problem in a Gauntlet 5.5 for
> NT 4.0 implementation?
>
> I've been tried to connect to a external FTP site using a common FTP
> client
> at
> the internal side of my network.
> After the connection has established, I can't get any command (ls, cd,
> get,
> ...)
> at the FTP server.
>
> Using the PASV command, the session behavior is ok. All the commands
> work fine.
>
> More details:
> - Transparency ON in both interfaces;
> - Client platform: Windows 95;
> - FTP server platform: many (Unix, NT);
> - No NAT rules used;
> - Permit * to * by the policy called 'Internet', all proxies (FTP proxy
> included).
>
> Any tips or suggestions?
> Must I have to create a stupid rule forwarding (packet-screen) all
> outbound
> traffic to port 20 through my firewall?
>
> I'd already contacted the NAI support and searched the Internet but I
> couldn't get any answer yet.
>
> Best regards,
> Alexandre Vargas
> ________________________________________________________
> Alexandre Vargas Rousseau Nunes
> Microsoft MCP, Cisco CCNA
> NT, Unix, Security, Internetworking & Telecommunications
> Modulo Security Solutions - Bras�lia - DF - Brasil
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
