RPC Connection Filtered with no Firewalls

I have a workstation (PC1) that cannot communicate with a domain controller over RPC (TCP/135).

C:\PortQryV2> portqry.exe -n 192.168.1.1 -p tcp -o 135
Querying target system called: 192.168.1.1
Attempting to resolve IP address to a name...
IP address resolved to dc.domain.local
querying...
TCP port 135 <epmap service>: FILTERED

Executing the same command on another workstation (PC2) in the same subnet and VLAN shows LISTENING along with all of the server's RPC endpoints.

C:\>netsh int ipv4 show dynamicport tcp
Protocol tcp Dynamic Port Range
---------------------------------
Start Port : 49152
Number of Ports : 16384

The dynamic port range is the same on both PC1 and PC2.

Both PC1 and PC2 are running Windows 7 Enterprise SP1.

McAfee Host Intrusion Prevention (HIPS) software used to be installed on PC1 but was removed during the troubleshooting process. It remains installed on PC2. Both PC1 and PC2 used the same HIPS policy.

Windows firewall is currently disabled on PC1.

C:\>netsh advfirewall show allprofiles
Domain Profile Settings:
----------------------------------------------------------------------
State OFF
Firewall Policy AllowInbound,AllowOutbound
LocalFirewallRules N/A (GPO-store only)
LocalConSecRules N/A (GPO-store only)
InboundUserNotification Enable
RemoteManagement Disable
UnicastResponseToMulticast Enable
Logging:
LogAllowedConnections Disable
LogDroppedConnections Disable
FileName %systemroot%\system32\LogFiles\Firewall\pfirewall.log
MaxFileSize 4096
Private Profile Settings:
----------------------------------------------------------------------
State OFF
Firewall Policy AllowInbound,AllowOutbound
LocalFirewallRules N/A (GPO-store only)
LocalConSecRules N/A (GPO-store only)
InboundUserNotification Enable
RemoteManagement Disable
UnicastResponseToMulticast Enable
Logging:
LogAllowedConnections Disable
LogDroppedConnections Disable
FileName %systemroot%\system32\LogFiles\Firewall\pfirewall.log
MaxFileSize 4096
Public Profile Settings:
----------------------------------------------------------------------
State OFF
Firewall Policy AllowInbound,AllowOutbound
LocalFirewallRules N/A (GPO-store only)
LocalConSecRules N/A (GPO-store only)
InboundUserNotification Enable
RemoteManagement Disable
UnicastResponseToMulticast Enable
Logging:
LogAllowedConnections Disable
LogDroppedConnections Disable
FileName %systemroot%\system32\LogFiles\Firewall\pfirewall.log
MaxFileSize 4096
Ok.

I captured the RPC connection from portqry.exe using Wireshark and found that the TCP SYN DPU was sent, but no ACK ever received. The TCP SYN was sent twice more, displaying in Wireshark as [TCP Retransmission]. Later, I captured the same RPC communication on the domain controller using Wireshark. I saw the incoming TCP SYN but saw no SYN ACK reply. It's as though the domain controller is arbitrarily ignoring just this computer on just this port. Note that querying Kerberos (UDP/88) works just fine from PC1.

I also tried rebuilding the TCP/IP stack on PC1, to no avail.

Any ideas on what could be preventing this communication?

7

1 Answer

After a lot of troubleshooting, I was able to determine that there was a Windows firewall rule enabled that would only allow connections from PC1 over TCP/135 and TCP/1027 if the connection is secure. In Windows Firewall with Advanced Security -> Inbound Rules, I went into the suspect rule properties. On the General tab, under Action, Allow the connection if it is secure was selected. On the Customize screen, Allow the connection if it is authenticated and integrity-protected was highlighted. The description for that item is as follows:

Allow only connections that are both authenticated and integrity-protected
by using IPsec. Compatible with Windows Vista and later.

enter image description here

Somehow this rule was established through a group policy on the domain. More than likely an administrator created this rule; however, it is possible that the software used on PC1 that requires this communication could have created the rule if it was installed using a domain admin account.

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password

Post as a guest

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

You Might Also Like