I have just succeeded in using Windows Sandbox with TinyWall. I allowed C:\Windows\System32\WindowsSandbox.exe but I had no internet access from inside the sandbox. I found out that adding C:\Windows\System32\svchost.exe for UDP and TCP out to local network only solved this. It appears to need this to set up the networking but not once everything is running.
Ultim, thank you very much for the time you have spent on this. I'll keep playing with it to see if I can figure it out, I don't expect you to spend any more time on it. I figured this was something I've done, I just don't know where to turn next. Any utilities you know of that could help me diagnose would be helpful. Under the special exceptions tab, for both recommended and optional, I have literally everything unchecked except for windows update and windows dhcp client. Is this a possibility ? Maybe I could try uninstalling the POP program and reinstalling it. Stranger things have fixed issues right? I do run an ancient HTTP filtering proxy program called Proxomitron. It's not that useful anymore with lack of HTTPS function, but it's a habit. Is it possible that could be it? I only allow port 80 on that program though. I've got some testing to do, thanks again.
Got rid of Proxomitron (it was time, man I loved that program) and ran Poppeeper outside the sandbox. No difference, connections still made.
Yes, actually the windows update rule was/is a prime suspect, but you said previously you already tried disabling that. Though if you didn't try that while everything else was disabled too, it might be worth a shot to try again. This issue of yours is a head scratcher for me as well. All I can think of right now is to try to eliminate every possible rule that might interfere with your intended setup. So what I'd do is create an export of your TinyWall settings (in the Maintenance tab) for backup, then delete all rules created by you except for POPPeeper, and disable all special exception except for ICMP, DNS and DHCP. If POPPeeper still manages to reach through 443, then while all the rules are still disabled (except for the aforementioned exceptions), execute "netsh wfp show state" in the command line and send me the xml output file.
Ok, I did all this and it still connected. I tried uploading the xml file and it would not allow the extension, saved it as txt and loaded up.
Is it possible you have a machine-wide custom (created by you) rule in TinyWall that allows all traffic on your machine? That's how I interpret the XML. A rule like the highlighted line in the attached screenshot. If you don't have one like it, please send me your exported TinyWall config for further inspection.
I do see a rule like that, but I'm pretty sure I didn't create it ? It says all applications, no restrictions. If this was true, couldn't anything connect regardless of any other rule? I know that doesn't happen, I see blocked apps per my rules. I thought svchost might be a culprit, but that one is necessary for almost everything to function. Here's my exception list, should I delete that global rule? I really appreciate this help.
Therein lies your problem. Mystery solved Go ahead and delete it. Normally, such a global rule - if created with "No restrictions" like in your case - would cause everything to be able to always connect, just as you suspect. The reason you still had functional blocking for some apps is because you have explicit blocking rules for those (the red lines), and blocking rules always take precedence in TinyWall. If you don't remember creating this rule on purpose, you probably created it by mistake, e.g. clicked "Add application", but then clicked OK instead of Cancel by mistake. I assure you TinyWall never invents rules on its own (except in auto-learn mode of course, but even in auto-learn mode, a global rule will never be inferred). Still, I will partly take the blame for this configuration error due to user-interface design. This case shows it is possible to relatively easily create a global allow rule by mistake, and I wasn't conscious of this - I just realized it now thanks to you. I'll do something about this in the next version to lessen the likelihood of such user errors.
Thank you so much for all your help. I can easily see how I would have done this now. User error as usual !
The System process is basically anything and everything running inside the OS kernel. The answer to your question depends on whether you trust MS and also all your installed drivers.
There are reports from other users too that whitelist rules for apps located on drives that aren't always connected don't always work (for example after a reboot for a removable drive, or after unlocking an encrypted partition). This is a homework for me to figure out and fix in a new release. But showing as a red X in the GUI even after reconnected is actually a completely separate issue (a purely GUI issue), which is new to me. I'll look into that as well.
I am a bit unsure about this. I am thinking it is not a good idea to set a rule to block System. I am on a 'stand alone computer'. System of course is connecting out to a few sites including the Amazon servers. What is recommended? TIA
I just switched over to TinyWall from WFC. I'm liking it so far but have run into an issue. I use ZeroTier on this computer. In my connection log I'm getting hundreds of blocks of the ZeroTier service even though I have it set to "No restrictions". I am making sure I press Apply after changing the rule. Any thoughts on what I need to do? Thanks
Don't know either, I can only say it is not due to the internal blocklists (those port numbers are not on the list). Maybe another firewall / rule from another firewall? That window shows blocked connections by any firewall on the computer, not just the ones blocked by TinyWall. Also, just to be sure, I'd recommend you open the Manage window and inspect zerotier-one_x64.exe's rules from the "Application exceptions" list, to make sure the one in effect is the one you intended.
Thanks for the quick response. I think I got it working just now. At first I had just right clicked and selected Unblock from the connection log. That created an entry in the Application Exception list but was listed with a red X and when I tried to modify the rule it showed as an "Unknown Application" and I couldn't make any modifications. I then noticed you could add a "service" as an exception which I then did as "zerotier-one_x64.exe" is run as a service. That seemed to create a valid entry in the App Exception list that was also modifiable. So I figured that would work but resulted in me still getting those blocks. I then noticed there was an option to run TinyWall UI with elevated privileges, which I did. I was still getting the blocks but proceeded to "Unblock" from the log which again created a rule in the App Exceptions. This time there was no red X and that rule was modifiable. The difference now is the rule "Type" is executable not service has I had setup. I removed the exception I made as "Type" service leaving only the one rule as "Type" executable. Now I have no more blocks in the log. So all seems well. What is the difference in rules created as type executable or type service? In this case it appears to only work as type executable not service even though "zerotier-one_x64.exe" is actually run as a service. Also why does it appear some rules must be created with elevated privileges and some don't?
In this case, both as type "Executable" and also as type "Service" would work. The reason the rule didn't take effect seems to be the red X, which means the executable was not found. The difference between Executable and Service type rules is that Executable applies to all processes that run using the specified executable file (in your case zerotier-one_x86.exe). Service type rules are only applied to the process which runs as the specified Windows service. A great example where this makes a huge difference is with svchost.exe. There are a lot of processes on any standard Windows system that run using svchost.exe, but most of them run as different services. Using Service type rules make it possible to define different firewall rules for each process, even though they are using the same executable.
Recommended is the minimum number of rules that make all *your* software work. On my computer, I have not allowed System to connect to anything and everything works fine. But in some cases kernel drivers need network access, such as with certain network printers or if you use WireShark. In these cases (and probably some others too) you have no choice but to whitelist System. IMHO unless you find by testing that whitelisting System solves a specific problem on your computer, I'd say leave it blocked.
OK..Thanks ultim...A few days ago I made a rule to block System and everything seems fine so I shall leave it. No network printers, WireShark or anything else that would require kernel drivers to connect. Thanks again helpful.
Thank you, I'll be looking forward to updates! No no, the red X is shown only when the files are actually inaccessible (e.g. drive disconnected), so I think the gui works correctly. It refreshes when I open the "manage" menu. My problem is that opening the manage menu is probably also the only way to "refresh" the rules, so i have to do it manually everytime I connect my removable drive.
Thanks, and I'm not sure if it played a role but it's just that everytime I would loose my connection I saw that outbound connections from system.exe were being blocked. Actually, even when I give "unrestricted access" to system.exe I see it's still being blocked from IGMP and ICMP traffic, is this normal? BTW, another thing that I totally forgot to ask, I noticed that TW blocks outbound connections from MsMpEng.exe, shouldn't this be allowed in the "Special Exceptions" section? Because I assume M$ needs it in order for Win Defender to contact the cloud. And finally, two comments about the GUI. It would be cool if when you clicked on Apply that the GUI wouldn't minimize. And if you double-click on the trayicon the main GUI should pop up in my opinion. Of course with only one click nothing should happen then, let me know what you think about it.
Yes, seeing ICMP and IGMP occasionally blocked is normal with TinyWall. Shouldn't cause any issues. There is a Windows Defender rule among the special exceptions, that should give MsMpEng outbound TCP access. Have you enabled it? I'm still indecisive on the Apply/OK/minimize front. I need to let it sink some more. About clicking on the icon: The single-click behavior will stay. I might add a feature where doubleclicking opens the settings window though.
OK I see. I must say that the last few weeks I almost never lose my connection with the Devolo powerline adapters, but I'm still not sure if system.exe had anything to do with it. It might as well have been "noise" on the electric wires. My bad, isn't it weird that you sometimes just don't see things? After allowing it, I see that Win Def is now correctly connecting to the cloud. BTW, what about a feature that let's you see the last 100 allowed and blocked connections? This is one of the reasons why I'm still using WFC. I will explain it, most apps in the tray, will show the context menu on right click and will show the main GUI on single-click or double-click. If you're too slow with the double-click, you might now see the context menu, that's why I suggested to scrap it, if you implement this feature. And about the "Apply" issue, the thing is that I often might want to make multiple changes, so it's annoying if the GUI closes. And most apps don't close when clicking on Apply.
Ultim, would it be possible in a future release in the show connections menu to list out the specific modules that are connected (or blocked) instead of the process svchost? I love sysinternals software and they have a utility called TCPView that does this. Thanks.
