Windows Advanced Firewall – adding Authorized Computers breaks rule

ipsecwindows 7windows-firewallwindows-server-2008

How can adding a 'only allow connections to these computers' setting in an an otherwise working IPSec rule break connectivity?

Background:

I'm setting up a basic set of client rules that restrict outbound SMB access to only go to certain servers. Assume starting from a blacklist and needing to whitelist the desired communication.

The server side is set up and functioning as it should without any problems what so ever. Set up was configured using the legacy IPSec interface server side and with the windows advanced firewall client side.

First authentication is set to Kerberos (Computer) or computer certificate. Both sides use 'request inbound and outbound' for their authentication mode.

Both sides use a 'request ipsec' model as there may be non IPSec traffic passing to other devices.

The Windows Advanced Firewall rule on the client functions perfectly until I define the 'only allow connections to these computers' option.

A wireshark capture shows ISAKMP and ESP traffic and I'm seeing main mode and quick mode associations in the security association list.

EDIT:

Per the MS documentation I've enabled the following logging to debug my connection issue. 

auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable
auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable
auditpol /set /subcategory:"IPsec Driver" /success:enable /failure:enable
auditpol /set /subcategory:"IPsec Main Mode" /success:enable /failure:enable
auditpol /set /subcategory:"IPsec Quick Mode" /success:enable /failure:enable
auditpol /set /subcategory:"IPsec Extended Mode" /success:enable /failure:enable

This only indicates the given service – I tried both SMB and RDP – being blocked. I'm not seeing any other blocked traffic.

EDIT:

It looks like there is absolutely no traffic being passed to the server in question when I enable the SMB or RDP rule. Wireshark shows nothing. Looks like there was a case like this a couple years ago here but no resolution.

It appears that the Windows Filtering Platform is incorrectly blocking this traffic when it should be allowing it. 

The Windows Filtering Platform has blocked a connection.

Application Information:
Process ID:     2468
Application Name:   \device\harddiskvolume1\windows\system32\mstsc.exe

Network Information:
Direction:      Outbound
Source Address:     192.168.20.54
Source Port:        49332
Destination Address:    192.168.100.50
Destination Port:       3389
Protocol:       6

Best Answer

just a few suggestions/questions for you (I have this same type of rule configuration working in my environment, so i'm curious to understand why it's not working)...

1) You mentioned that the client is using Windows Firewall with Advanced Security IPsec policy, but the server side is using legacy IPsec. Is the server running an older version of Windows or what was the reason for the legacy IPsec policy config? I'm not saying that this shouldn't work (as your trying to do machine auth, not user auth), but it may complicate things. Can the server also be configured with advanced security policy? Could you try against a server with advanced policy and Kerberos v5 computer auth to see what happens?

2) For your scenario to work, the IPsec connection MUST use a Kerberos V5 authentication (certificate authentications will not work!). You mentioned that your policy could allow certificate connections, so you might want to check your main mode security associations and ensure that they are really being established using Kerberos and not cert.

3) There are a few different ways to configure the 'only allow connections to these computers' setting on a firewall rule. The default requires your IPsec connection to be authenticated and integrity protected...whereas other settings allow you to ensure that it is also encrypted or that it is null encap (only authenticated, not integrity protected). If your client/server are Windows 7+ then you might want to try the null encapsulation option to see if that helps narrow the problem.

4) I'd usually recommend logs from WFP capture (netsh wfp capture start) to debug firewall dropped traffic, as that shows you the exact filter which dropped traffic. In this case though, the logs probably wont be very interesting as it's likely the default outbound block filter which is preventing your connection, due to the fact that you didn't match the secure allow rule (for some reason). The logs will show the connection being dropped, but won't explain why you didn't match the allow rule. Perhaps it's worth a try though... http://technet.microsoft.com/en-us/library/ff428146(v=ws.10).aspx

Related Topic