Windows Advanced Firewall - adding Authorized Computers breaks rule

Question

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

Answer 1

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

Answer 2

After a 13+ month trouble ticket with MS we finally came up with a 'solution' for this 'expected behavior'.

---

Select the action that Windows Firewall with Advanced Security will take for network packets that match the firewall rule criteria. When you have multiple firewall rules defined, the order in which they are evaluated for a match depends on the action specified in the rule. Firewall rules are evaluated in the following order:

1. Allow if secure with Override block rules selected in the Customize Allow if Secure Settings dialog box.
2. Block the connection.
3. Allow the connection.
4. Default profile behavior (allow or block as specified on the applicable Profile tab of the Windows Firewall with Advanced Security Properties dialog box).

Within each category, rules are evaluated from the most specific to the least specific. A rule that specifies four criteria is selected over a rule that specifies only three criteria.

As soon as a network packet matches a rule, its action is triggered, and it is not compared to any additional rules.

In other words, even if a network packet matches more than one rule, only the matching rule that is evaluated against the packet first is applied to the packet.

As per them if there is any matching rule which has allow in the firewall rule that the traffic will pass unencrypted.

What needs to be done is make sure that by default there is a block rule and then create a Secure rule with the Option Override Block rules to make the things work.

Please refer http://technet.microsoft.com/en-us/library/cc730690.aspx for more information.