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

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

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

Date: Tue, 11 Jan 2005 16:46:13 -0800

Nothing you have posted so far suggests the conclusions that you have drawn.

The only way to tell for sure whether the firewall pays any attention to the
EPRT or PORT commands are to:
1. Check at the _server_ side to see what the command looked like when it
reached the server (that way, you can tell if NAPT is happening), to compare
with the command you sent.
2. Have a process bound to, and listening on, the port that you specified.
In your tests, the server is attempting to connect to the address and port
the client gave in the EPRT or PORT command, and is receiving a RST as a
result. You have no way to tell whether this RST is prompted by the
firewall refusing the SYN to come in, or by the TCP stack saying "I don't
have any listening sockets on that port". You do not have any listening
sockets on that port, so an incoming SYN will be reset, firewall or no.

The firewall has no knowledge of the difference between a PORT command that
you specify by using literal and one that is specified by a client's action
(if it did, how would third-party FTP clients be supported?)

To be honest, I don't know (yet) if EPRT is supported by our NAPT component.

If you have information (server logs, say) that would support your
assertions, please post them, but what you have posted to date is not a
basis for the assertions you have made.

Alun.
~~~~ 

-- 
Software Design Engineer, Internet Information Server (FTP)
This posting is provided "AS IS" with no warranties, and confers no rights.
"Triffid" <triffid@nebula.net> wrote in message 
news:DwFEd.21638$b64.365731@news20.bellglobal.com...
>
>
> 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