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

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Triffid (triffid_at_nebula.net)
Date: 01/11/05 

Date: Mon, 10 Jan 2005 19:58:12 -0500

Alun Jones [MSFT] wrote:

> "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.

My bad, I provided incomplete information.

If the firewall were external to the client, and configured to permit
the traffic, the EPRT command would cause the firewall to start a listen
for the incoming data connection. In most cases the firewall would also
modify the EPRT command prior to forwarding it, changing the address (if
  it's doing NAT) and the port (most just grab the next available rather
than checking if the port specified by the client is available first).

Windows Firewall does not appear to 'see' the EPRT command - at least it
did not modify it, nor did it start a listen.

>>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.

Similar to above - Windows Firewall does not start a listen in response
to the PORT command, whereas an external firewall would. An external
firewall would have no way of knowing 'literal' was used to generate the
PORT command, Windows Firewall apparently does.

Relevant Pages