This project has moved. For the latest updates, please go here.


Unable to allow skype app (metro)


Running Win10 14393.969 with WFN 2.0 A12 and having a relatively minor issue, but I expect it should be seen by others.

Which is for now I'm not able to have the firewall allowing the skype app, this is the metro version which starts automatically with windows and always triggers a WFN notification at every boot or when you're trying to use the app.

What happens is this type of security events get generated:

The Windows Filtering Platform has blocked a connection.

Application Information:
Process ID:     4964
Application Name:   \device\harddiskvolume1\program files\windowsapps\microsoft.skypeapp_11.13.133.0_x64__kzf8qxf38zg5c\skypehost.exe
Network Information:
Direction:      Outbound
Source Address:
Source Port:        62250
Destination Address:
Destination Port:       1900
Protocol:       17
Filter Information:
Filter Run-Time ID: 88848
Layer Name:     Connect
Layer Run-Time ID:  48

which trigger WFN notifications.
And neither the rule created by WFN (with just the "program" configured and all the other parameters set to "any"), nor the additional outbound rule I created based on the application package (while again everything else is "any", including the program) actually manage to allow skypehost.exe.

All the other rules for all the other programs seem to work fine though.

I noticed you are already aware of some issues related to rules for Store Apps which are planned to be fixed in beta. Question would be is this related to these issues or it's something else ? If yes is there a way I can manually configure the rule to have the skypehost.exe allowed? Thanks!
Closed May 22 at 4:34 PM by DanielPharos
Issue confirmed fixed with V2.0 beta 1.


DanielPharos wrote Apr 11 at 3:50 PM

This is indeed caused by WFN not handling App-rules correctly. :(

Ger0nim0 wrote Apr 12 at 2:42 PM

Thank you for the fast reply!

Normally the only thing WFN would need to do about it is just to properly create the rule, the rest should be Windows Firewall's task but I guess I'm missing something. So not exactly sure what you mean by handling App-rules correctly, the rule was created just as well as one would do it manually. You mean there's more to do for this particular case or it's that the rule should be created differently ?

Anyways since this was the only rule I had for a program in C:\Program Files\WindowsApps folder I tried few more apps until I found another one requiring to be allowed for outbound. This was Xbox and the same story happened, the WFN created rule was ignored resulting in duplicated notifications/rules (although the app was running fine otherwise, so it did have at least partial internet access...)

This pretty much confirms what you said, it seems outbound rules won't work for programs in WindowsApps folder, while appearing to work for everything else. Can you give us a hint about why this is happening, could this be because of WSH ? Because I do see WSH rules listed in WFN, including outbound blocking rules for both apps in question...
Finally and most importantly is there anything we can do about it until beta version ? If there's too much to explain some suggested documentation where we could learn how to overcome the issue would be greatly appreciated. Thanks!

DanielPharos wrote Apr 12 at 8:26 PM

the rest should be Windows Firewall's task
The Windows Firewall doesn't make a distinction between a connection blocked due to a rule, or "by default". Meaning WFN needs to parse all the rules and apply them, to see if a rule blocked a connection, so it can then not show up. Otherwise, every blocked connection would still create prompts (which indeed is what has been happening with App-related rules!).
this be because of WSH ?
I can't rule it out, but the latest version of WFN should be handling those rules as well as other "normal" rules. I'm not aware of trouble with these, but we'll see what happens when WFN starts handling App-rules properly.
Finally and most importantly is there anything we can do about it until beta version ?
Unfortunately, there's no good workaround (that I'm aware of), and building one into WFN is probably the same amount of work as fixing the problem in the first place. So sorry, we'll all have to wait until I have enough time to really fix this.

Speaking of which, I've just today added the infrastructure to handle App's! It's not working correctly just yet (WFN uses the wrong App-name, so the rule currently doesn't work), but it won't be long now! :)

Ger0nim0 wrote Apr 13 at 5:34 PM

First thanks for the explanations, they really helped as it seems I was getting things wrong. My security log is normally flooded with a lot of filtering events caused by the UPnP service on my router (inbound) and looking through all that I was not able to locate any outbound event. So I've assumed events matching a rule are already filtered in the log (hence WFN won't need to process rules) but as you have pointed out this was obviously wrong.

However the current issue does not seem to be related to that because what I am trying to do is to allow skype not block it. Therefore the new rule should cause Audit Failure events to become Audit Success and obviously WFN won't issue notifications for those regardless on how it processes rules. So what seems to happen is the rule is ignored by Windows Firewall which keeps blocking the app and this is my main problem.
So at this point I'm just assuming neither WFN nor I are able to just create the rule properly, and was just wondering if you already know what could be the problem.

And glad to hear there is progress for handling App's. Although the more annoying part for me now is the unwanted notifications my "fight" seems to be more with Windows Firewall, but if necessary I can certainly wait until beta as I don't use Windows Apps much. I could also try a bit harder to disable skype from autostarting, the problem is this does not look like the proper measure because on my system I don't seem to be able to have proper internet access for App's if the outbound firewall is enabled (regardless on WFN presence), and this really needs to be fixed.

Thanks again for the fast reply !

DanielPharos wrote May 20 at 8:58 AM

I've just released a new version of WFN, which includes App-rule handling! See:

Ger0nim0 wrote May 22 at 1:04 PM

Thanks for letting me know, after updating to Beta1 it seems to be working fine now ... finally got rid of the skypehost.exe notification when rebooting.

The skype blocking events generated on OS boot are also gone (as seen in the security log) while those generated when launching the app (or others, such as xbox) are now correctly ignored by WFN. Despite the blocking events generated on some apps they actually appear to be working normally, so as far as I can tell everything works fine in this regard now.

So this problem is solved and by my needs I'd say WFN is quite usable at this point!
Made a small donation now and will donate more on future releases.
Thanks again for the support and for making this app!!!

DanielPharos wrote May 22 at 4:34 PM

So this problem is solved and by my needs I'd say WFN is quite usable at this point!
Glad to hear that! :)
Made a small donation now and will donate more on future releases.
Thank you!

wrote May 22 at 4:34 PM

wrote May 22 at 4:34 PM