[Discussion] UWP App networking fails due to Windows built-in AppContainerLoopback security

[Kein]

This covers root issue of #1250 as well as some duplicates. Since this is not an actual DNScrypt issue, I'm denoting it as a discussion for community's purposes.

Long answer: https://googleprojectzero.blogspot.com/2021/08/understanding-network-access-windows-app.html

Short answer:

One of the specific restrictions imposed on AppContainer applications is blocking access to localhost. The purpose of this is it makes it more difficult to exploit local network services which might not correctly handle AppContainer callers creating a sandbox escape. Let's test the behavior out and try to connect to a localhost service.

I dont know if this an acquired issue of the Windows (in the poccess of its life/usage) or comes with default installation, but for 99% of UWP ("MS store apps") apps, access to loopback outside of its own SID is blocked.

I've noticed this issue trying to figure out why Xbox App would randomly fail and saw packet drops matching dnscrypt-proxy:

The Windows Filtering Platform has blocked a packet.
Application Information:
	Process ID:		8068
	Application Name:	\device\harddiskvolume1\programs\dnscrypt\dnscrypt-proxy.exe
Network Information:
	Direction:		Inbound
	Source Address:		127.0.0.1
	Source Port:		52408
	Destination Address:	127.0.0.1
	Destination Port:		53
	Protocol:		17
Filter Information:
	Filter Run-Time ID:	126355
	Layer Name:		Receive/Accept
	Layer Run-Time ID:	44

This made no sense to me, as I have blanked allowance for dnscrypt-proxy.exe as well as no rules that would block any packets to 53 on any of the addresses, both remote and local, globally. I dug deeper to find out what the filterid is about:

<item>
	<filterKey>{0740183e-bc32-4cac-b9a7-584c568a1823}</filterKey>
	<displayData>
		<name>AppContainerLoopback</name>
		<description>AppContainerLoopback</description>
	</displayData>
	<flags/>
	<providerKey>FWPM_PROVIDER_MPSSVC_WF</providerKey>
	<providerData>
		<data>ffffffffffffffff</data>
		<asString>........</asString>
	</providerData>
	<layerKey>FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4</layerKey>
	<subLayerKey>FWPM_SUBLAYER_MPSSVC_WSH</subLayerKey>
	<weight>
		<type>FWP_UINT64</type>
		<uint64>18446744073709551614</uint64>
	</weight>
	<filterCondition numItems="2">
		<item>
			<fieldKey>FWPM_CONDITION_FLAGS</fieldKey>
			<matchType>FWP_MATCH_FLAGS_ALL_SET</matchType>
			<conditionValue>
				<type>FWP_UINT32</type>
				<uint32>1</uint32>
			</conditionValue>
		</item>
		<item>
			<fieldKey>FWPM_CONDITION_ALE_USER_ID</fieldKey>
			<matchType>FWP_MATCH_EQUAL</matchType>
			<conditionValue>
				<type>FWP_SECURITY_DESCRIPTOR_TYPE</type>
				<sd>O:LSD:(A;;CC;;;AC)(A;;CC;;;S-1-15-3-1)(A;;CC;;;S-1-15-3-2)(A;;CC;;;S-1-15-3-3)(A;;CC;;;S-1-15-3-4214768333-1334025770-122408079-3919188833)(A;;CC;;;WD)(A;;CC;;;AN)</sd>
			</conditionValue>
		</item>
	</filterCondition>
	<action>
		<type>FWP_ACTION_BLOCK</type>
		<filterType/>
	</action>
	<rawContext>0</rawContext>
	<reserved/>
	<filterId>126355</filterId>
	<effectiveWeight>
		<type>FWP_UINT64</type>
		<uint64>18446744073709551614</uint64>
	</effectiveWeight>
</item>

It matches the aforementioned description of global blanket block for AppContainer to access loopback.

At his moment I'm not aware of any solutions and fixes.

[github-actions]

This issue was automatically closed because it did not follow the issue template. We use the issue tracker exclusively for bug reports and feature additions that have been previously discussed. However, this issue appears to be a support request. Please use the discussion forums for support requests.