I have the port 3389 incoming rule setup, but I cannot RD from a box in the public zone.  My machine is not actually public (it is on my internal LAN), but it is recognized by Windows 2012 R2 as public.

I have the standard Remote Desktop (TCP-In) incoming rule setup.  I can remote desktop fine if I only turn on the firewall for Private and Domain.  If I make the Public firewall zone active (i.e., ON), I immediately drop my RD connection.

I've tried to troubleshoot with no luck.  The target box is a VMware VM but I don't know why that would matter.

Thanks!

I turned on auditing and found that the firewall is blocking and the source is my RD client (over port 3389).  But, my Incoming rule says to allow 3389.  The "Specify profiles to which this applies" has Domain, Private and Public all checked.......  here is the event log (security):

The Windows Filtering Platform has blocked a packet.

Application Information
 Process ID  1592
 Application Name deviceharddiskvolume2windowssystem32svchost.exe

Network Information
 Direction  Inbound
 Source Address  10.160.30.144
 Source Port  58518
 Destination Address 10.160.128.229
 Destination Port  3389
 Protocol  17

Filter Information
 Filter Run-Time ID 0
 Layer Name  ReceiveAccept
 Layer Run-Time ID 44

• Edited by bamboozlethegreat Wednesday, November 06, 2013 2:24 AM

OK.. the above message says I am connecting over UDP, but the default rule is for TCP only.  So, I went and added a UDP incoming rule for 3389, restarted the firewall, but alas still no joy.  I thought that would do it.

Are you still seeing the dropped packet in the logs?

Protocol 6 - back to TCP.  I have it open as far as I know.  Any ideas?

The Windows Filtering Platform has blocked a packet.

Application Information:
 Process ID:  1592
 Application Name: \device\harddiskvolume2\windows\system32\svchost.exe

Network Information:
 Direction:  Inbound
 Source Address:  10.160.30.144
 Source Port:  36306
 Destination Address: 10.160.128.229
 Destination Port:  3389
 Protocol:  6

Filter Information:
 Filter Run-Time ID: 79339
 Layer Name:  Receive/Accept
 Layer Run-Time ID: 44
The Windows Filtering Platform has blocked a connection.

Application Information:
 Process ID:  1592
 Application Name: \device\harddiskvolume2\windows\system32\svchost.exe

Network Information:
 Direction:  Inbound
 Source Address:  10.160.128.229
 Source Port:  3389
 Destination Address: 10.160.30.144
 Destination Port:  36306
 Protocol:  6

Filter Information:
 Filter Run-Time ID: 79339
 Layer Name:  Receive/Accept
 Layer Run-Time ID: 44

• Edited by bamboozlethegreat Wednesday, November 06, 2013 5:43 PM

Hi,

To assist with this, we need to trace the issue.

"NetSh.exe WFP capture start"

Reproduce the scenario "NetSh.exe WFP capture stop"

You can then obtain the wfpdiag.cab file under "C:\Windows\System32\.

 

You can search for the net event for the block, and correlate it with the actual filter id. This should give you an indication of why the traffic was blocked.

Hope this helps.

I think this is it... I pulled this from the log on the Windows 2012 server.  It is from the wfpdiag.xml file.  Not sure what this means.  Thanks.

<netEvent>
   <header>
    <timeStamp>2013-11-07T21:24:50.523Z</timeStamp>
    <flags numItems="11">
     <item>FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET</item>
     <item>FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET</item>
     <item>FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET</item>
     <item>FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET</item>
     <item>FWPM_NET_EVENT_FLAG_REMOTE_PORT_SET</item>
     <item>FWPM_NET_EVENT_FLAG_APP_ID_SET</item>
     <item>FWPM_NET_EVENT_FLAG_USER_ID_SET</item>
     <item>FWPM_NET_EVENT_FLAG_SCOPE_ID_SET</item>
     <item>FWPM_NET_EVENT_FLAG_IP_VERSION_SET</item>
     <item>FWPM_NET_EVENT_FLAG_REAUTH_REASON_SET</item>
     <item>FWPM_NET_EVENT_FLAG_PACKAGE_ID_SET</item>
    </flags>
    <ipVersion>FWP_IP_VERSION_V4</ipVersion>
    <ipProtocol>6</ipProtocol>
    <localAddrV4>10.160.128.229</localAddrV4>
    <remoteAddrV4>10.160.30.144</remoteAddrV4>
    <localPort>3389</localPort>
    <remotePort>55887</remotePort>
    <scopeId>3758096385</scopeId>
    <appId>
     <data>5c006400650076006900630065005c0068006100720064006400690073006b0076006f006c0075006d00650032005c00770069006e0064006f00770073005c00730079007300740065006d00330032005c0073007600630068006f00730074002e006500780065000000</data>
     <asString>\.d.e.v.i.c.e.\.h.a.r.d.d.i.s.k.v.o.l.u.m.e.2.\.w.i.n.d.o.w.s.\.s.y.s.t.e.m.3.2.\.s.v.c.h.o.s.t...e.x.e...</asString>
    </appId>
    <userId>S-1-5-20</userId>
    <addressFamily>FWP_AF_INET</addressFamily>
    <packageSid>S-1-0-0</packageSid>
   </header>
   <type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>
   <classifyDrop>
    <filterId>85888</filterId>
    <layerId>44</layerId>
    <reauthReason>3</reauthReason>
    <originalProfile>1</originalProfile>
    <currentProfile>1</currentProfile>
    <msFwpDirection>MS_FWP_DIRECTION_IN</msFwpDirection>
    <isLoopback>false</isLoopback>
    <vSwitchId/>
    <vSwitchSourcePort>0</vSwitchSourcePort>
    <vSwitchDestinationPort>0</vSwitchDestinationPort>
   </classifyDrop>
  </netEvent>

Just got off the phone with an MS rep and he fixed the problem.  He deleted the Incoming UDP port 3389 rule I created and then re-add the same rule and it worked. 

The original port 3389 UDP rule I made was created from a copy of the port 3389 TCP rule.  Even though I edited the rule and it showed as changed, it apparently did not really change.  This is apparently a bug.

• Edited by bamboozlethegreat Friday, November 08, 2013 11:49 PM
• Marked as answer by Jeremy_WuMicrosoft contingent staff, Moderator Monday, November 11, 2013 8:06 AM

Hi,

Thanks for the update. And I am glad to hear that the issue has been resolved.

Cheers.

I faced similar problem today for a standalone Windows 2012 R2 system. My objective was to block all incoming connection and allow only incoming RDP to the system. Hence I created a New Incoming rule for blocking all traffic which worked as it should. Then I enabled the existing rule for RDP but couldnt connect even when all other settings are correct.
Then after lots of failed attempts as suggested by many, I created two Incoming block rules i.e. first rule for TCP 0-3388 and second rule for TCP 3390-65535, thus only allowing port 3389 and this solved the problem.

This is definitely a Bug which do not allow any rule to bypass Block All rule base. This needs to be fixed.