Re: What is the trick to get Windows XP firewall to stay on (after a reboot)?

From: Alun Jones [MSFT] (alunj_at_online.microsoft.com)
Date: 01/10/05 

Date: Mon, 10 Jan 2005 08:34:06 -0800

"Triffid" <triffid@nebula.net> wrote in message
news:VJVDd.80695$P%3.2580840@news20.bellglobal.com...
> Agreed, the third premise should have been "Destination IP address matches
> the PORT command sent by the client" per RFCs - but is there a downside to
> a stricter implementation?

Sure - it'll break anything that tries to use a different IP address. Such
as third-party transfer.

Now, you can certainly argue whether third-party transfer is appropriate or
not, but a stricter implementation will break functionality that is used by
some.

> Windows FTP client does not implement EPRT. It appears a "well behaved
> client" would be required to determine if Windows Firewall implements
> EPRT:
>
> ---------
> ftp> ls
> 200 PORT command successful.
> 150 Opening ASCII mode data connection for file list.
> dtdbcache_:0
> sdtvolcheck393
> speckeysd.lock
> 226 Transfer complete.
> ftp: 46 bytes received in 0.00Seconds 46000.00Kbytes/sec.
> ftp> literal EPRT |1|10.0.0.1|5003
> 200 EPRT command successful.
> ftp> literal LIST
> Connection closed by remote host.
> ---------

All you've shown here is that the EPRT command is accepted by this server,
and that you can't use "literal" to start a transfer without doing some
extra work.

> Client did not reply to SYN, but that doesn't help since:
>
> ---------
> ftp> ls
> 200 PORT command successful.
> 150 Opening ASCII mode data connection for file list.
> dtdbcache_:0
> sdtvolcheck393
> speckeysd.lock
> 226 Transfer complete.
> ftp: 46 bytes received in 0.00Seconds 46000.00Kbytes/sec.
> ftp> literal PORT 10,0,0,1,19,141
> 200 PORT command successful.
> ftp> literal LIST
> 425 Can't build data connection: Connection refused.
> ftp>
> ---------
>
> i.e. Windows Firewall is not simply proxying the PORT command.
> Interesting.

No, that's not what you've shown. You've shown that when you tell the
server to connect to a port (that's what "literal PORT blah..blah..blah"
does), which the client isn't listening on, the server gets a RST back -
connection refused. You have not shown whether that RST comes from the
firewall or the TCP stack behind the firewall.

Alun.
~~~~

Relevant Pages