none
Identify which FW rule is responsible for blocking specific data RRS feed

  • Question

  • How can I determine exactly what firewall rule is blocking particular data?

    I have an application that gets all the way through opening an FTP connection and logging onto the FTP server, but then stalls on mput (the actual upload command), leaving a zero-byte file on the FTP server. The log reveals that the FW is blocking port 20 (the FTP data port) even though it is not blocking port 21 (the command port). That explains why it stalls only when it gets to the actual file upload. Here is a sample DROP line from the log:

     2016-03-24 22:19:06 DROP TCP [FTP server address] [Workstation address] 20 49432 60 S 2753606402 0 29200 - - - RECEIVE

    I added an explicit TCP Allow rule for remote port 20, and this allowed the process to complete the upload correctly. But then I disabled it for further testing and then re-enabled it--and now the process is again stalling on the FTP data transfer.

    I cannot understand is why this process is not blocked on other stations not having explicit port 20 rules. But it seems that it would be most useful to somehow trace all of this to what (rule), explicitly, is blocking port 20 on this workstation and/or allowing it on other workstations.

    Friday, March 25, 2016 7:28 AM

Answers

  • The log does not give me any more information than what port was blocked. However, I did find the answer by a bit more experimentation. I found that this particular station was using the 64-bit version of FTP, not the 32-bit version as other stations.

    The default firewall rule allowed C:\Windows\System32\ftp.exe but not C:\windows\syswow64\ftp.exe. They are both listed as "Firewall Transfer Program", and it was only by looking at the details that I found the 32/64-bit difference. I allowed the 64-bit version, and the problem is solved.


    Monday, March 28, 2016 3:14 AM

All replies

  • Hi Brian D. Hart,

    From our experience, Windows Firewall rule will not distinguish specific data, it is aimed at port, program, scope or system service.

    We can’t determine which rule blocks specific data, if we has configured one rule, this rule just can:

    disable a program or a system services from the exceptions list.

    disable a TCP or UDP port from the exceptions list.

    disable a preconfigured system service exceptions.

    In your post, since you have found out your FW settings blocks port 20, I think you should know why your FTP app can’t transfer data to your server normally. Also, your test successfully, you could make data upload correctly by adding an explicit TCP rule, even though it meets with a problem later. Please check the log to find what counteract FTP transfer.

    There is an official documentation introduces Windows firewall, it can help you understand.

    https://technet.microsoft.com/en-us/library/cc755604(v=ws.10).aspx#BKMK_architecture

    Best regards


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Monday, March 28, 2016 2:25 AM
    Moderator
  • The log does not give me any more information than what port was blocked. However, I did find the answer by a bit more experimentation. I found that this particular station was using the 64-bit version of FTP, not the 32-bit version as other stations.

    The default firewall rule allowed C:\Windows\System32\ftp.exe but not C:\windows\syswow64\ftp.exe. They are both listed as "Firewall Transfer Program", and it was only by looking at the details that I found the 32/64-bit difference. I allowed the 64-bit version, and the problem is solved.


    Monday, March 28, 2016 3:14 AM