microsoft
Direct Support For Localhost Loopback
Is your feature request related to a problem? Please describe
Our native windows apps supports connecting to local devices (high accuracy bluetooth GPS) via TCP/IP. WSA is not able to connect localhost (Windows 11 hosting machine) unless you run a couple PowerShell commands to open the firewall. It would be preferred to have the localhost loopback capability enabled by default - or perhaps with a settings UI toggle.
Describe the solution you'd like
Localhost (127.0.0.1) loopback setting enabled out of the box would allow our app running in WSA to talk to the hosting Window 11 machine via TCP/IP.
Describe alternatives you've considered
The following powershell commands enable loopback*:
Set-NetFirewallHyperVVMSetting -VMCreatorId '{9E288F02-CE00-4D9E-BE2B-14CE463B0298}' -LoopbackEnabled True
New-NetFirewallHyperVRule -DisplayName LoopbackAllow -VMCreatorId '{9E288F02-CE00-4D9E-BE2B-14CE463B0298}' -Direction Inbound -Action Allow -LocalPorts 443
*Notes:
- min version of Windows 11 required HH2H
- Powershell must be ran as administrator
Please specify the version of Windows Subsystem for Android
2211.40000.11.0
Just a note - the above is related to a workaround for bluetooth support. #103
Dear @jake-brown-maps. I'm also having trouble with this problem. Are the commands that you mentioned working without the need for any change? I mean, are these VMCreatorIds the same for every device? If not, can you please let me know how can I get it for myself? Also, my PowerShell is not recognizing this command. Does that need another app? (I'm using Windows PowerShell provided with Windows)
Thank you for the information provided.
@matinmn87, did you try running powershell as administrator? I did not change the VMCreatorId; you may need to change the port depending on what port you're wanting to open up.
Yes, I did. But for both commands, I'm getting errors:
New-NetFirewallHyperVRule: The term 'New-NetFirewallHyperVRule' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Set-NetFirewallHyperVVMSetting: The term 'Set-NetFirewallHyperVVMSetting' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Shall I cd a special directory?
Thanks for your help
@matinmn87 No special directory to execute from as far as I can tell, and I have not see that error on my Windows 11 machines. Perhaps @timkur may have an idea.
Looking into the future roadmap - I do see that Local network access by default is included so that enhancement should eliminate the need for this workaround.
OK, thank you for your pieces of information, but still, my problem is not solved.
What version of Windows are you using? You'll want to be on 22H2 for these commands to work?
Tim
these commands not working for me, i'm using antivirus program norton 360, but wsa is "allowed" in norton 360 firewall settings
This is a different type of firewall than what norton would provide. We're still experimenting in this space, which is why we haven't enabled advanced networking by default yet.
found a workaround
suppose you are using adb, and want app to use localhost port 8080
after calling adb connect ip:port to wsa
call adb reverse tcp:8080 tcp:8080 afterwards
then app will be able to call localhost:8080
adb reverse expose a port on your Android device to a port on your computer.
Dear @agufagit! Thanks for your answer. It's working like a charm! Just another thing. Is it possible to make it listen to all ports? Because in my usage I can't know the exact port. Something like this: adb reverse tcp:* tcp:*
you can do multiple ports, but only 1 port at a time, etc. adb reverse tcp:80 tcp:80 adb reverse tcp:8080 tcp:8080 adb reverse --list
but port doesn't matter in development, you are just testing the service/server code that's running behind port
@timkur @agufagit
One of our users try to run
Set-NetFirewallHyperVVMSetting -VMCreatorId '{9E288F02-CE00-4D9E-BE2B-14CE463B0298}' -LoopbackEnabled True
Then he/she run into an error. Any idea? I have asked them to try the workaround following @agufagit comment too.
That workaround is mainly for developer for simple environment setup, but it doesn't work with docker. Docker will give "address already in use" error, whereas if you start the server from command line, it works. I ended up using Android studio emulator now.
I doubt that workaround will work in your case, unless the service you are trying to use doesn't throw "address already in use" error
@agufagit how can I tell this is a docket environment based on the error message? I am curious as I will need to know that and then I can help with other users.
not only docker, it's any service/server that checks if address is already in use before binding to that port.
There can't be any service/server listening to that port before calling adb reverse tcp:Port tcp:Port, or adb will throw an error
likewise, after calling adb reverse, adb is listening to that port, if you call any service/server that does port binding pre-check such like docker to bind to that port, it will throw an error "Address already in use"
Only service/server that doesn't do a port binding pre-check will work
@timkur - has the workaround approach to local loopback changed with build 2305.40000.2.0?
Hi there.
The screen shot shows "-PolicyStoreLoopbackEnabled' as one parameter. These are 2 different parameters: -PolicyStore, and -LoopbackEnabled. You'll need to specify them separately. (you don't need to set PolicyStore, you can just set -LoopbackEnabled).
Noticed that the advanced networking feature had been overhauled in 2306
Local networking (under Advanced settings - Experimental features) now replacing "Advanced networking". Android apps can connect to devices on the same network, on all versions of Windows, respect Windows firewall rules, and work with VPNs
Was there an update to local loopback settings? It appears that the above workaround is still needed
cc @timkur @keith-horton
Hey Jake,
With the advanced networking overhaul, you shouldn't need to set the Hyper-V firewall rules anymore. I'm guessing you're not seeing that?
Tim
Yeah I see the new rules, I have a screen shot below
BTW - I'm trying to connect to a device streaming on (127.0.0.1)port 20175, but not able to
Yeah I see the new rules, I have a screen shot below
BTW - I'm trying to connect to a device streaming on (127.0.0.1)port 20175, but not able to
Are you referring to the adb workaround above? The NetFirewallHyperVRules should not have any effect in 2306.
This might be related: w 2306 - Local network access does not seem to work for me - it gives me an IP on the local LAN, but the only device it can talk to is the network gateway router. Fire TV Remote does not work.
With local network access turned off, it gives me an IP on a different subnet, but I can talk to devices on the local LAN if I directly connect to them via IP. - Fire TV Remote works
Testing it out with various network scanners.
@nieubank
Are you referring to the adb workaround above? The NetFirewallHyperVRules should not have any effect in 2306.
yeah my guess was that was related, thanks for noting it should not be.
Any thoughts on why 2306 can't see device that's on port 20175? Let me know if I can provide any more detail
@nieubank
Are you referring to the adb workaround above? The NetFirewallHyperVRules should not have any effect in 2306.
yeah my guess was that was related, thanks for noting it should not be.
Any thoughts on why 2306 can't see device that's on port 20175? Let me know if I can provide any more detail
How are you trying to connect? Note that ICMP has limited if any support in the current preview of this new iteration of the feature so if you're trying to ping that will not work at the moment.
I am using a utility that converts a GPS NMEA string from a bluetooth GPS and serves it out over TCP/IP for our application (ArcGIS Field Maps) to consume. More details
@nieubank - just to clear up - we have not been using an adb workaround - we have been using the powershell commands provided by @timkur .
Set-NetFirewallHyperVVMSetting -VMCreatorId '{9E288F02-CE00-4D9E-BE2B-14CE463B0298}' -LoopbackEnabled True
New-NetFirewallHyperVRule -DisplayName LoopbackAllow -VMCreatorId '{9E288F02-CE00-4D9E-BE2B-14CE463B0298}' -Direction Inbound -Action Allow -LocalPorts 20175
As of 2306 these commands no longer allow our app running in WSA to connect to the local host - port 20175 (or any other port we define)
@nieubank - just to clear up - we have not been using an adb workaround - we have been using the powershell commands provided by @timkur .
Set-NetFirewallHyperVVMSetting -VMCreatorId '{9E288F02-CE00-4D9E-BE2B-14CE463B0298}' -LoopbackEnabled True New-NetFirewallHyperVRule -DisplayName LoopbackAllow -VMCreatorId '{9E288F02-CE00-4D9E-BE2B-14CE463B0298}' -Direction Inbound -Action Allow -LocalPorts 20175As of 2306 these commands no longer allow our app running in WSA to connect to the local host - port 20175 (or any other port we define)
We've done some investigation here and there is a gap in the new preview local host networking stack where connecting to a port on Windows fails. We're actively working on a solution and will keep you updated on its progress. The adb workaround may be the only option in the immediate term but that does require enabling developer mode.
Unfortunately, we can't make guarantees on these preview features, but we're actively pushing to get this feature rolled out more broadly and fix up these remaining gaps.