Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Wednesday, January 16, 2019 12:03 PM
Hi,
my default setting for the firewall is to block all traffic. Exceptions are added if necessary. For instance, two exceptions enable DNS and DHCP. This works well. However, another one is svchost, service="Cryptographic services" (CryptSvc). It does not work. This means, the firewall still blocks these packets. I have verified my rule multiple times, even removed it and added it again. I know that packets are blocked by enabling logging dropped packets via group policies. In addition, I wrote a little program for live observation of these log entries. From the logged process ID I see which service is running in that instance:
The firewall rule exactly matches this case. Consequently, the packet should not be blocked. The rule is: Allow, Outgoing, program=svchost, service=CryptSvc, all profiles, all local ports, all IPs, protocol TCP, remote ports 80 and 443.
So my question is: Why does the firewall block packets even if a rule allows them? (There is no other rule denying it)
Win 10 x64 Pro.
Thanks
Armin
All replies (16)
Thursday, January 17, 2019 5:41 PM ✅Answered | 1 vote
Hallo Armin,
I having been learning as I write. At the time that I wrote "It might be worth exploring what aspect of your permit rule definition caused this condition to be added to the WFP/BFE filter", I did not appreciate that creating a rule with a service name condition caused two conditions to be added to the filter: the service executable name (the generic name "svchost" in this case) and the service SID.
My guess is that the service SID just has to be one of the SIDs in the token of the thread performing the connect and not necessarily the primary SID. The userId in the drop event is probably the primary SID of the thread.
Since the drop event only records the userId (primary SID) and not all of the SIDs, we can't be sure that this is the reason that the rule is not being applied - but it is a good candidate.
Since a service can manipulate its token, perhaps by impersonating a client, I don't think that "service name" rules can be guaranteed to work (it will depend on how the service is designed/coded).
The TechNet thread https://social.msdn.microsoft.com/Forums/en-US/998db81e-96a0-41e6-8e1b-4b4cd19ff6ee/filtering-by-service-name?forum=WFP (marked as answered) says:
- Block by service name uses Service SID as filtering condition. There are cases when a service impersonates when it binds to the socket. In such cases, traffic is sent in context of user and SID that is being examined by WFP is the user's SID and not the service SID. Hence block by service name doesnt work. May be this happens in case of spooler svc. For wuauserv, it doesnot impersonate so the rule by service name seems to work.
Gary
Thursday, January 17, 2019 8:44 AM
Hi,
Thanks for your question.
Have you check this in firewall log?
Please check whether the traffic has been dropped by firewall.
For your reference:
https://www.maketecheasier.com/track-internet-activity-windows-firewall-log/
Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.
Best Regards,
Eric
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Thursday, January 17, 2019 1:44 PM
Have you check this in firewall log?
Please check whether the traffic has been dropped by firewall.
Yes, that's what I wrote in my first post. I've enabled logging dropped pakets in the event log via group policies. From the process ID I was able to determine the service running within that instance of svchost. It was CryptSvc.
Armin
Thursday, January 17, 2019 2:38 PM | 1 vote
Hallo Armin,
One approach that you could consider is to capture a more detailed log of the packet drop and use the information to find the detailed firewall rule that triggered the packet drop.
The command "netsh wfp show netevents" shows recent events including packet drops - this would be the easiest source of the detailed information.
There are at least two other options to get the necessary detailed information:
- The Microsoft-Windows-WFP ETW provider gives the necessary information. It can be enabled/disabled individually, using tools/commands such as logman.exe (e.g. "logman start foo -ets -p Microsoft-Windows-WFP -o bar.etl" (and "logman stop foo -ets"). Various commands/tools can view the collected data (e.g. wevtutil.exe, Message Analyzer).
- The provider can also be enabled in the Event Viewer, by enabling the "Analytic" channel, and the events viewed there.
The FilterId value in the event with ID 1001 is the most useful information.The next step is to dump the current WFP (Windows Filtering Platform) filters. This can be done with the command "netsh wfp show filters verbose=on". The output is a large XML file (my more-or-less out-of-the-box filters create a 2.5 MB XML file). The FilterId from the WFP event can be used to find the filter definition in the XML file.
The Windows Filtering Platform documentation (https://docs.microsoft.com/en-us/windows/desktop/fwp/windows-filtering-platform-start-page) might be helpful in understanding the XML.
The XML of a drop event can look like this:
<item>
<header>
<timeStamp>2019-01-17T14:07:28.714Z</timeStamp>
<flags numItems="6">
<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_IP_VERSION_SET</item>
</flags>
<ipVersion>FWP_IP_VERSION_V4</ipVersion>
<ipProtocol>6</ipProtocol>
<localAddrV4>192.168.0.7</localAddrV4>
<remoteAddrV4>192.168.0.3</remoteAddrV4>
<localPort>7680</localPort>
<remotePort>56050</remotePort>
<scopeId>0</scopeId>
<appId/>
<userId/>
<addressFamily>FWP_AF_INET</addressFamily>
<packageSid/>
<enterpriseId/>
<policyFlags>0</policyFlags>
<effectiveName/>
</header>
<type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>
<classifyDrop>
<filterId>96350</filterId>
<layerId>13</layerId>
<reauthReason>0</reauthReason>
<originalProfile>0</originalProfile>
<currentProfile>0</currentProfile>
<msFwpDirection>MS_FWP_DIRECTION_IN</msFwpDirection>
<isLoopback>false</isLoopback>
<vSwitchId/>
<vSwitchSourcePort>0</vSwitchSourcePort>
<vSwitchDestinationPort>0</vSwitchDestinationPort>
</classifyDrop>
</item>
The filter definition matching this filterId looks like this:
<item>
<filterKey>{57cd5c79-929d-4696-ac15-da26d284802a}</filterKey>
<displayData>
<name>Port Scanning Prevention Filter</name>
<description>This filter prevents port scanning. This many times means there are no listeners. If debugging ensure your scenario has one.</description>
</displayData>
<flags/>
<providerKey>{decc16ca-3f33-4346-be1e-8fb4ae0f3d62}</providerKey>
<providerData>
<data>ffffffffffffffff</data>
<asString>........</asString>
</providerData>
<layerKey>FWPM_LAYER_INBOUND_TRANSPORT_V4_DISCARD</layerKey>
<subLayerKey>{b3cdd441-af90-41ba-a745-7c6008ff2301}</subLayerKey>
<weight>
<type>FWP_UINT8</type>
<uint8>12</uint8>
</weight>
<filterCondition numItems="1">
<item>
<fieldKey>FWPM_CONDITION_FLAGS</fieldKey>
<matchType>FWP_MATCH_FLAGS_NONE_SET</matchType>
<conditionValue>
<type>FWP_UINT32</type>
<uint32>3</uint32>
</conditionValue>
</item>
</filterCondition>
<action>
<type>FWP_ACTION_CALLOUT_TERMINATING</type>
<filterType>FWPM_CALLOUT_WFP_TRANSPORT_LAYER_V4_SILENT_DROP</filterType>
</action>
<rawContext>0</rawContext>
<reserved/>
<filterId>96350</filterId>
<effectiveWeight>
<type>FWP_UINT64</type>
<uint64>13835058055349272576</uint64>
</effectiveWeight>
</item>
The filter description alone might be help enough.
If this approach looks promising to you but you need further help then just ask.
Gary
Thursday, January 17, 2019 3:51 PM
Gary,
thanks a lot for taking the time. A while ago, I already found out that it is the global default setting to drop these packets. However, this default setting should be overwritten by the specific rule added. Thanks for the other helpful hints, too. This gives me more means to find things out.
I'll report what........oh, luckily it just happened again. So this is pretty fresh data.
netevents.xml reveals filterid = 367788 was responsible for dropping the packet:
<header>
<timeStamp>2019-01-17T15:00:35.213Z</timeStamp>
<flags numItems="9">
<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_IP_VERSION_SET</item>
<item>FWPM_NET_EVENT_FLAG_PACKAGE_ID_SET</item>
</flags>
<ipVersion>FWP_IP_VERSION_V4</ipVersion>
<ipProtocol>6</ipProtocol>
<localAddrV4>192.168.178.2</localAddrV4>
<remoteAddrV4>23.214.196.178</remoteAddrV4>
<localPort>53313</localPort>
<remotePort>80</remotePort>
<scopeId>0</scopeId>
<appId>
<data>5c006400650076006900630065005c0068006100720064006400690073006b0076006f006c0075006d00650034005c00770069006e0064006f00770073005c00730079007300740065006d00330032005c0073007600630068006f00730074002e006500780065000000</data>
<asString>\.d.e.v.i.c.e.\.h.a.r.d.d.i.s.k.v.o.l.u.m.e.4.\.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-18</userId>
<addressFamily>FWP_AF_INET</addressFamily>
<packageSid>S-1-0-0</packageSid>
<enterpriseId/>
<policyFlags>0</policyFlags>
<effectiveName/>
</header>
<type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>
<classifyDrop>
<filterId>367788</filterId>
<layerId>48</layerId>
<reauthReason>0</reauthReason>
<originalProfile>2</originalProfile>
<currentProfile>2</currentProfile>
<msFwpDirection>MS_FWP_DIRECTION_OUT</msFwpDirection>
<isLoopback>false</isLoopback>
<vSwitchId/>
<vSwitchSourcePort>0</vSwitchSourcePort>
<vSwitchDestinationPort>0</vSwitchDestinationPort>
</classifyDrop>
Using netsh wfp show filters, I dumped all filters to filters.xml. Looking up filterID = 367788 shows that the "Default Outbound" filter dropped the packet - as already mentioned at the top of this post:
<item>
<filterKey>{fa5040ef-63a6-4dec-a592-627ca627f414}</filterKey>
<displayData>
<name>Default Outbound</name>
<description>Default Outbound</description>
</displayData>
<flags/>
<providerKey>{decc16ca-3f33-4346-be1e-8fb4ae0f3d62}</providerKey>
<providerData>
<data>e102000000000000</data>
<asString>........</asString>
</providerData>
<layerKey>FWPM_LAYER_ALE_AUTH_CONNECT_V4</layerKey>
<subLayerKey>{b3cdd441-af90-41ba-a745-7c6008ff2301}</subLayerKey>
<weight>
<type>FWP_UINT8</type>
<uint8>8</uint8>
</weight>
<filterCondition numItems="1">
<item>
<fieldKey>FWPM_CONDITION_ORIGINAL_PROFILE_ID</fieldKey>
<matchType>FWP_MATCH_EQUAL</matchType>
<conditionValue>
<type>FWP_UINT32</type>
<uint32>2</uint32>
</conditionValue>
</item>
</filterCondition>
<action>
<type>FWP_ACTION_BLOCK</type>
<filterType/>
</action>
<rawContext>0</rawContext>
<reserved/>
<filterId>367788</filterId>
<effectiveWeight>
<type>FWP_UINT64</type>
<uint64>9223372036854791168</uint64>
</effectiveWeight>
</item>
So, the question is (still), why my own rule does not overrule the default setting. This is my rule:
<item>
<filterKey>{3449eb65-dd9a-4401-9aa5-8c269f1b7db3}</filterKey>
<displayData>
<name>AZ: Dienst Kryptografiedienst</name>
<description/>
</displayData>
<flags numItems="1">
<item>FWPM_FILTER_FLAG_INDEXED</item>
</flags>
<providerKey>{decc16ca-3f33-4346-be1e-8fb4ae0f3d62}</providerKey>
<providerData>
<data>1504000000000000</data>
<asString>........</asString>
</providerData>
<layerKey>FWPM_LAYER_ALE_AUTH_CONNECT_V4</layerKey>
<subLayerKey>{b3cdd441-af90-41ba-a745-7c6008ff2301}</subLayerKey>
<weight>
<type>FWP_UINT8</type>
<uint8>9</uint8>
</weight>
<filterCondition numItems="4">
<item>
<fieldKey>FWPM_CONDITION_ALE_APP_ID</fieldKey>
<matchType>FWP_MATCH_EQUAL</matchType>
<conditionValue>
<type>FWP_BYTE_BLOB_TYPE</type>
<byteBlob>
<data>5c006400650076006900630065005c0068006100720064006400690073006b0076006f006c0075006d00650034005c00770069006e0064006f00770073005c00730079007300740065006d00330032005c0073007600630068006f00730074002e006500780065000000</data>
<asString>\device\harddiskvolume4\windows\system32\svchost.exe</asString>
</byteBlob>
</conditionValue>
</item>
<item>
<fieldKey>FWPM_CONDITION_ALE_USER_ID</fieldKey>
<matchType>FWP_MATCH_EQUAL</matchType>
<conditionValue>
<type>FWP_SECURITY_DESCRIPTOR_TYPE</type>
<sd>O:SYG:SYD:(A;;CCRC;;;S-1-5-80-242729624-280608522-2219052887-3187409060-2225943459)</sd>
</conditionValue>
</item>
<item>
<fieldKey>FWPM_CONDITION_IP_PROTOCOL</fieldKey>
<matchType>FWP_MATCH_EQUAL</matchType>
<conditionValue>
<type>FWP_UINT8</type>
<uint8>6</uint8>
</conditionValue>
</item>
<item>
<fieldKey>FWPM_CONDITION_IP_REMOTE_PORT</fieldKey>
<matchType>FWP_MATCH_EQUAL</matchType>
<conditionValue>
<type>FWP_UINT16</type>
<uint16>443</uint16>
</conditionValue>
</item>
</filterCondition>
<action>
<type>FWP_ACTION_PERMIT</type>
<filterType/>
</action>
<rawContext>0</rawContext>
<reserved/>
<filterId>368909</filterId>
<effectiveWeight>
<type>FWP_UINT64</type>
<uint64>10377146487606870016</uint64>
</effectiveWeight>
</item>
Actually, my own rule that is visible only once in the firewall GUI, is contained four times within filters.xml:
ipv4/dest port 80
ipv6/dest port 80
ipv4/dest port 443
ipv6/dest port 443
This is plausible.
The decrypted "<data>" value is also just "\device\....]\svchost.exe"
Alternatively, using netsh advfirewall firewall show rule "AZ: Dienst Kryptografiedienst" the output is:
Aktiviert: Ja
Richtung: Aus
Profile: Domäne,Privat,Öffentlich
Gruppierung:
Lokales IP: Beliebig
Remote-IP: Beliebig
Protokoll: TCP
Lokaler Port: Beliebig
Remoteport: 80,443
Edgeausnahme: Nein
Aktion: Zulassen
I do not know why this rule does not prevent the packet from being dropped.
Armin
Thursday, January 17, 2019 4:17 PM
My guess, why these rules referring to services sometimes do not work:
If you double-click on an svchost instance in Process Explorer and switch to the "Threads" tab, there is the "service" column. This column is sometimes empty. This is probably because they are worker threads that do not have a correlation to a certain service. If these worker threads perform the network I/O, the firewall is not able to see this correlation, too, and consequently, it does not match the rule.
Armin
Thursday, January 17, 2019 4:32 PM
Hallo Armin,
As you probably guessed, multiple "filters" for a single "rule" is common - that is how to map (potentially implied) "OR" clauses in a rule to WFP/BFE filters.
Your permit filter includes an FWPM_CONDITION_ALE_USER_ID condition with the SID S-1-5-80-242729624-280608522-2219052887-3187409060-2225943459 whereas the packet drop event records a userId SID of S-1-5-18.
It might be worth exploring what aspect of your permit rule definition caused this condition to be added to the WFP/BFE filter.
Gary
Thursday, January 17, 2019 4:48 PM
Hallo Armin,
I think that a combination of our last two messages is possibly the answer - the SID in the filter is probably the service SID shown by the command "sc showsid cryptsvc":
NAME: cryptsvc
SERVICE SID: S-1-5-80-242729624-280608522-2219052887-3187409060-2225943459
STATUS: Active
This SID might be missing from the token of the receiving thread...
Gary
Thursday, January 17, 2019 5:06 PM
Hallo Gary,
S-1-5-80-242729624-280608522-2219052887-3187409060-2225943459 means "NT Service\CryptSvc", and S-1-5-18 is "NT-AUTORITÄT\SYSTEM".
.....I just see, your newest message says the same.
I'm not sure about the meaning of the "<userId>" inside netevents.xml. Do the two SIDs have to match to make the rule work?
The svchost.exe instance is running under the account "NT-AUTORITÄT\Netzwerkdienst" = S-1-5-20
EDIT: What do you mean by
"It might be worth exploring what aspect of your permit rule definition caused this condition to be added to the WFP/BFE filter. "
?
Armin
Thursday, January 17, 2019 10:12 PM | 1 vote
Hallo Armin,
When nothing interesting is happening in the CryptSvc process, none of the threads are impersonating (i.e. they are all using the process token) and the process token looks like this:
TS Session ID: 0
User: S-1-5-20 (Well Known Group: NT AUTHORITY\NETWORK SERVICE)
User Groups:
00 S-1-16-16384 (Label: Mandatory Label\System Mandatory Level)
Attributes - GroupIntegrity GroupIntegrityEnabled
01 S-1-1-0 (Well Known Group: localhost\Everyone)
Attributes - Mandatory Default Enabled
02 S-1-5-32-545 (Alias: BUILTIN\Users)
Attributes - Mandatory Default Enabled
03 S-1-5-6 (Well Known Group: NT AUTHORITY\SERVICE)
Attributes - Mandatory Default Enabled
04 S-1-2-1 (Well Known Group: localhost\CONSOLE LOGON)
Attributes - Mandatory Default Enabled
05 S-1-5-11 (Well Known Group: NT AUTHORITY\Authenticated Users)
Attributes - Mandatory Default Enabled
06 S-1-5-15 (Well Known Group: NT AUTHORITY\This Organization)
Attributes - Mandatory Default Enabled
07 S-1-5-80-242729624-280608522-2219052887-3187409060-2225943459 (Well Known Group: NT SERVICE\CryptSvc)
Attributes - Default Enabled Owner
08 S-1-5-5-0-557232 Unrecognized SID Attributes - Mandatory Default Enabled Owner LogonId
09 S-1-2-0 (Well Known Group: localhost\LOCAL)
Attributes - Mandatory Default Enabled
Primary Group: S-1-5-20 (Well Known Group: NT AUTHORITY\NETWORK SERVICE)
Privs:
00 0x000000017 SeChangeNotifyPrivilege Attributes - Enabled Default
01 0x00000001d SeImpersonatePrivilege Attributes - Enabled Default
02 0x00000001e SeCreateGlobalPrivilege Attributes - Enabled Default
Auth ID: 0:3e4
Impersonation Level: Anonymous
TokenType: Primary
Is restricted token: no.
SandBoxInert: 0
Elevation Type: 1 (Default)
Mandatory Policy: TOKEN_MANDATORY_POLICY_VALID_MASK
Integrity Level: S-1-16-16384
Process Trust Level: (null)
Token Virtualized: Disabled
UIAccess: 0
IsAppContainer: 0
Security Attributes Information:
00 Attribute Name: TSA://ProcUnique
Value Type : TOKEN_SECURITY_ATTRIBUTE_TYPE_UINT64
Value[0] : 131
Value[1] : 557833
Device Groups:
The service SID is present in the groups collection and the primary SID is S-1-5-20. That adds to my belief that the service is impersonating a client (with primary SID S-1-5-18) when it makes the HTTP connection. I tried setting debugger breakpoints in the CryptSvc process on routines that might be used to create a connection (so that I could examine the thread's token and call-stack at that time) but there has been no network activity since then...
Gary
Thursday, January 17, 2019 10:29 PM
Hallo Gary,
again, thanks for your time.
"My guess is that the service SID just has to be one of the SIDs in the token of the thread performing the connect and not necessarily the primary SID. "
Within Process Explorer, the "Permissions" button on the Threads tab reveals some entries that could be helpful. However, with svchost, I do not have the permission to open the permissions ("Die angeforderten Sicherheitsinformationen sind nicht verfügbar oder können nicht angezeigt werden"). Anyway, I second your theory about the possible cause. The quoted reason makes sense, too.
So... It seems I do not have a chance. This is bad, as I can not use any other criterion, and opening svchost completely was ridiculous. I can not specify a target host name, either. If I'd open wide IP ranges, I could disable the FW completely as well.
Look again at which services really need network access, it's just DNS and the Time service. These could be easily filtered by port and maybe even by destination IP. CryptSvc seems to be the only exception that is hard to handle as I guess it's recommended to grant access to ocsp.digicert.com (and others?) to the service.
Armin
Thursday, January 17, 2019 11:26 PM
The service SID is present in the groups collection and the primary SID is S-1-5-20. That adds to my belief that the service is impersonating a client (with primary SID S-1-5-18) when it makes the HTTP connection. I tried setting debugger breakpoints in the CryptSvc process on routines that might be used to create a connection (so that I could examine the thread's token and call-stack at that time) but there has been no network activity since then...
Sorry, I didn't see this post of yours yet while I was typing mine.
Thanks again for the work, but I think I'll simply reconsider which services really need to be running, then decide what needs to be done.
EDIT: I'm not deep into the security topic in particular yet, so I'll first have to visit docs.microsft.com. ;)
Armin
Friday, January 18, 2019 8:25 AM
Hi,
Thanks for your reply.
It's really a strange issue if everything has been configured well.
Have you check the rules you configured? Have you enabled the rule?
Please make sure that there is a 
in front of your rules.
Best Regards,
Eric
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Friday, January 18, 2019 9:30 AM
Hallo Armin,
One (slightly wider) criteria that you could use (in place of, or as well as, the service name) is a "Local User" of "LocalSystem" (S-1-5-18). This may well be the SID of the only "client" of CryptSvc (would need to be tested).
As you probably know, target host "name" information is not available in the context where rules/filters are evaluated, we don't necessarily know all host names that might be used and those that are used are probably served by a Content Delivery Network (lots of IP addresses).
A "one-off" (unmaintainable) approach might be to make a copy of svchost.exe under a different name and update the service definition to use the new file. For example:
SERVICE_NAME: CryptSvc
TYPE : 20 WIN32_SHARE_PROCESS
START_TYPE : 2 AUTO_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : C:\WINDOWS\system32\svchostXXX.exe -k NetworkService -p
LOAD_ORDER_GROUP :
TAG : 0
DISPLAY_NAME : Cryptographic Services
DEPENDENCIES : RpcSs
SERVICE_START_NAME : NT Authority\NetworkService
One could then filter by the executable name.
In any event, I think that we have a common understanding of the issues and you are well placed to balance the effort/effectiveness of any putative solution.
Gary
Friday, January 18, 2019 10:20 AM
Gary,
the day after.. Sorted things out a bit. One could wonder, why not first think about services really required before caring about their network traffic? Right, but it was about CryptSvc that I do not intend to disable.
I agree regarding difficulties finding other criterions for the reasons given. A different Exe name would be an impudent hack. ;)
Once more thank you for the time and good explanations.
Herzlichen Dank
Armin
Friday, January 18, 2019 10:32 AM
Have you check the rules you configured? Have you enabled the rule?
Eric,
yes, the rule is enabled. Simply put, it actually has to do with the SID under which the network traffic is going on. It's not "under the hood" of CryptSvc itself, hence my rule doesn't match.
This probably hits the spot:
Conclusion: With the current design of the particular service, it is impossible to create service specific rules. I consider it a flaw as it just does not work as one can expect.
Armin