UVM WSH configuration seems wrong, leading to services unaccessible in Hyper-V isolation mode

[gpotter2]

Hi everyone !

I have been troubleshooting why some services of a windows container (windows server image) aren't reachable from the host when the container is running in Hyper-V isolation mode, most notably the EventLog which is not reachable from the network. (This can be verified pretty quickly by running pktmon in the UVM, which shows the 'Syn' packets getting dropped).

My analysis

When running in Hyper-V isolation mode, I believe that the firewall of the UVM has an invalid configuration of the Windows Services Hardening keys (https://learn.microsoft.com/en-us/windows/win32/api/netfw/nn-netfw-inetfwservicerestriction).

Here's the rule that's supposed to allow the running EventLog service to be reached (in the UVM):

reg query "HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System" /v "Eventlog Allow RPC over TCP"

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System
    Eventlog Allow RPC over TCP    REG_SZ    V2.0|Action=Allow|Dir=In|LPort=RPC|Protocol=6|App=%SystemRoot%\system32\svchost.exe|Svc=EventLog|Name=Allow RPC/TCP traffic to EventLog|

Running netsh wfp show filters in the UVM shows that this was expanded to the following :

Extract from filters.xml

<item>
	<filterKey>{d1bfb869-9a7b-41c4-9cfa-e0613617a8ed}</filterKey>
	<displayData>
		<name>Allow RPC/TCP traffic to EventLog</name>
		<description/>
	</displayData>
	<flags numItems="1">
		<item>FWPM_FILTER_FLAG_INDEXED</item>
	</flags>
	<providerKey>FWPM_PROVIDER_MPSSVC_WSH</providerKey>
	<providerData>
		<data>3700000000000000</data>
		<asString>7.......</asString>
	</providerData>
	<layerKey>FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4</layerKey>
	<subLayerKey>FWPM_SUBLAYER_MPSSVC_WSH</subLayerKey>
	<weight>
		<type>FWP_EMPTY</type>
	</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>5c006400650076006900630065005c0068006100720064006400690073006b0076006f006c0075006d00650032005c00770069006e0064006f00770073005c00730079007300740065006d00330032005c0073007600630068006f00730074002e006500780065000000</data>
					<asString>\device\harddiskvolume2\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-880578595-1860270145-482643319-2788375705-1540778122)</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_ALE_SIO_FIREWALL_SYSTEM_PORT</fieldKey>
			<matchType>FWP_MATCH_EQUAL</matchType>
			<conditionValue>
				<type>FWP_UINT32</type>
				<uint32>1</uint32>
			</conditionValue>
		</item>
	</filterCondition>
	<action>
		<type>FWP_ACTION_PERMIT</type>
		<filterType/>
	</action>
	<rawContext>0</rawContext>
	<reserved/>
	<filterId>66495</filterId>
	<effectiveWeight>
		<type>FWP_UINT64</type>
		<uint64>1689691673853952</uint64>
	</effectiveWeight>
</item>

Note that the path is \device\harddiskvolume2\windows\system32\svchost.exe. However, a WFP capture trying to reach the EventLog port shows the following:

Extract from wfpdiag.xml

<netEvent>
	<header>
		<timeStamp>2025-09-15T16:09:39.033Z</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>100.64.0.1</localAddrV4>
		<remoteAddrV4>100.64.0.254</remoteAddrV4>
		<localPort>49154</localPort>
		<remotePort>59438</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-19</userId>
		<addressFamily>FWP_AF_INET</addressFamily>
		<packageSid>S-1-0-0</packageSid>
		<enterpriseId/>
		<policyFlags>0</policyFlags>
		<effectiveName/>
	</header>
	<type>FWPM_NET_EVENT_TYPE_PUBLIC_CLASSIFY_DROP</type>
	<classifyDrop>
		<filterId>66518</filterId>
		<layerId>44</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>
	<internalFields>
		<internalFlags numItems="2">
			<item>FWPM_NET_EVENT_INTERNAL_FLAG_FILTER_ORIGIN_SET</item>
			<item>00000008</item>
		</internalFlags>
		<capabilities/>
		<fqbnVersion>0</fqbnVersion>
		<fqbnName/>
		<terminatingFiltersInfo numItems="3">
			<item>
				<filterId>66549</filterId>
				<subLayer>FWPP_SUBLAYER_INTERNAL_FIREWALL_QUARANTINE</subLayer>
				<actionType>FWP_ACTION_PERMIT</actionType>
			</item>
			<item>
				<filterId>66518</filterId>
				<subLayer>FWPP_SUBLAYER_INTERNAL_FIREWALL_WSH</subLayer>
				<actionType>FWP_ACTION_BLOCK</actionType>
			</item>
			<item>
				<filterId>66532</filterId>
				<subLayer>FWPP_SUBLAYER_INTERNAL_FIREWALL_WF</subLayer>
				<actionType>FWP_ACTION_PERMIT</actionType>
			</item>
		</terminatingFiltersInfo>
		<filterOrigin>WSH Default</filterOrigin>
		<interfaceLuid>1689399632855040</interfaceLuid>
		<policyAppId/>
		<compartmentId>2</compartmentId>
		<processId>1532</processId>
		<serviceSids>S-1-5-80-2078495744-2416903469-4072184685-3943858305-976987417,S-1-5-80-2940520708-3855866260-481812779-327648279-1710889582,S-1-5-80-880578595-1860270145-482643319-2788375705-1540778122,S-1-5-80-172094073-716411664-54255058-185476446-2329512179,S-1-5-80-2381253463-2694003897-3435975801-3559003598-683041300,S-1-5-80-410965207-2550896871-1717734767-2321332215-3755966139,S-1-5-80-3557709225-3446934100-2592608561-3401846376-4273827271,S-1-5-80-3098585136-2538892366-1097114017-2832417424-2016953023</serviceSids>
	</internalFields>
</netEvent>

The packet is dropped by the "WSH Default" WSH rule (documented here), which means the rule I mentionned earlier doesn't seem to have matched (which looks like a bug to me). I suspect that it's because the binary that received the packet was seen as \device\harddiskvolume4\windows\system32\svchost.exe (!= \device\harddiskvolume2\windows\system32\svchost.exe).

This looks like a bug caused by the expansion of %SystemRoot% in a wrong place :/ I would really appreciate if anyone could confirm that this analysis sounds sane.

Current workaround

I currently patch the SYSTEM hive of the UVM with the following:

HKLM\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System

This is super hacky but at least it works (EventLog is properly reachable from outside the container).

All in all, this feels like something that might want to be fixed. Thanks a lot for the incredible work and any help. Cheers

Additional informations

• Edition: Windows 11
• Base Image being used: Windows Server
• Container engine: docker

[github-actions]

Thank you for creating an Issue. Please note that GitHub is not an official channel for Microsoft support requests. To create an official support request, please open a ticket here. Microsoft and the GitHub Community strive to provide a best effort in answering questions and supporting Issues on GitHub.

[microsoft-github-policy-service]

This issue has been open for 30 days with no updates.
no assignees, please provide an update or close this issue.

[gpotter2]

It's still definitely an issue.

[microsoft-github-policy-service]

This issue has been open for 30 days with no updates.
no assignees, please provide an update or close this issue.

[gpotter2]

Still open :)

[microsoft-github-policy-service]

This issue has been open for 30 days with no updates.
no assignees, please provide an update or close this issue.

[gpotter2]

An update.