The beta uses only dynamic filters, which are in place as soon as the service starts. Note TW runs as a service, so this is much sooner than user login. That being said, there is a delay between BFE and TW startup. I left it out from the first test version on purpose because persistent filters would completely cut your network in case of some bugs and a normal user wouldn't be able to recover at all. Now that I'm positive that things are working well, this will come soon (and obviously before TW3 final is released).
Yes, this is a pretty accurate analysis, with the exception that older versions of TW had exactly the same behavior. It seems there is now some other software (or a newer version of it) on your computer that triggers the reload much more often. TW3 (or its current beta) does not have this problem anymore. The biggest bug in the current beta is that it does not disable Windows Firewall on startup, so you either need to disable Windows Firewall yourself, or inbound whitelisting will not work. The next build will solve that. Otherwise I think it has been shown the beta is more than OK, so I suggest you wait for the next build and use that. I'll try to hurry.
To clarify, I just wanted to give TW a test-drive, so it would be handy if I can still keep WFC installed. From a technical point of view they should be able to work if you disable certain features in WFC. Especially now that TW isn't depending on the Win Firewall anymore, no?
Yes, TW3 does not depend on Windows Firewall (WF). But this only means that TW does not need or use WF, and it does not mean that when both are enabled there won't be conflicts. Specifically, if WF is found running on the local computer, TW3 will add a special rule to WF starting with the next build to resolve said conflict. You should be able to keep WFC installed with the right options (disable rule security I think?), but it will certainly change the way WF (and thus in turn WFC) behaves while TW is running.
To this I will add that the default Windows Firewall uses boot-time filters. So if you are worried about this, just leave WF enabled and then startup / boot-time protection is just as good as with TW2, WF, or WFC. Of course, for the case when WF is completely disabled, this will be implemented by TW3 itself shortly.
Don't want to sound pushy and ungrateful but I need this feature urgently. Thank you. And btw and tbh I thought TW beta 3 was protecting me at boot time since I installed it.
Port 8080 is not in the blocklist, so I am skeptical it is the cause. Isn't the default Windows Firewall policy for inbound connections the problem? If my hunch is correct, the next build will solve your issue.
Yep, problem found. Fixed in next beta. Thx. Note though that ipv6-test.com wants to ping you as part of the test, so you'll only get full score if you enable pings under special exceptions. There is another similar site https://test-ipv6.com which does not depend on pings.
Hi everybody, I've just uploaded a new test version. As I said earlier, I focused on incorporating your feedback in this round. TinyWall users are the best! Here's the changelog compared to the previous beta: - Fix manual import of settings from version 2.1 - Fix user may not get notified of updates for a very long time (port from 2.1) - Fix inbound whitelisting does not work if Windows Firewall is running - Fix ICMPv6 filters for IPv6 connectivity - Improved handling of batch whitelisting in Connections and Processes windows - Don't forget blocked apps list when Connections window is closed - Enable single-click toggling of special exceptions - Sort Connections list by timestamp by default - Support F5-refresh in Connections window - Support Delete key for application exceptions list - Eliminate flicker when updating Connections and Application lists - Restore auto-update functionality - Optimize blocked connection buffer handling - Add work-in-progress Korean localization - Add SmartScreen to app database I'll wait a bit for feedback, and if things seem to be round, I'll move on to new features again.
Hi, use the new beta I just published and don't disable Windows Firewall. Then you have the same startup/boot protection that you are accustomed to. The only case I need to implement it in TinyWall is for when WF is disabled. Will come in one of the next builds. Until then, with WF enabled, there is no compromise in security.
Windows Firewall is turned off. Only by turning off 'port' blocklist does the process start and listen on port 8080. I can recreate this problem at will. Latest beta has same problem. Update: Tried listening on a different port (16384) same problem.
It's too soon to tell whether the change from v2.1.11 to v2.99.8 has resolved the problems I posted about earlier, but thought I'd mention that the upgrade slipped very smoothly into three different machines here, automatically picking up settings from the old v2 installation (from "Program Files (x86)"), removing that installation and installing and starting up v3 (in "Program Files"). Very nice to see. These were all Windows 10 x64 1903 installations, two VMware guests and one physical machine (host to the other two). So far everything seems to be working fairly smoothly ... although the timestamp column in the "Show Connections" dialog is a bit of a mystery. Older connections keep updating to the latest time with every refresh. So what exactly does this column mean? Some of the reported blocked connections seem to be hanging around in the list longer than 2 min - seems to be 5 minutes - it doesn't worry me, 5 minutes is fine with me, just saying. Edited to Add one thing I did notice: In the v2.1 ticking "Unblock LAN Traffic" meant that the File and Printer Sharing option didn't matter much (it all worked because it was all local traffic). In this version v2.99.8 I do actually have to have a tick in File and Printer Sharing for sharing to work. The change is not a problem, if fact it is probably a good thing. Just thought I would mention it.
I currently use SpyShelter (SS) and it's also able to block outbound connections, but I can keep the Win Firewall enabled, so that's why I'm guessing I can do the same with TW. On the other hand, SS is not really a full fledged firewall. Perhaps people who are running WFC can post what happens when you put WFC in low filtering mode, and keep Secure Rules enabled.
The timestamp for "Blocked" type entries is when the block of the packet happened, because it is an event. The other kinds of entries (for example established or listening sockets) are more like current state than an event that happened, so the timestamp displayed there is the time when that state was recorded, which is basically when you clicked the Refresh button (or opened the window). I'm not even sure I could get time information for those other entries, but I can look into it. Do you think it would make more sense to display a different timestamp (assuming it is technically possible to retrieve that information)? Yes, this is an accurate observation. It used to be 2 minutes, but I changed it to 5 in version TW3, and I have forgotten to update the checkbox text in the window. I'll check this. Actually if so, the old behavior is what I want. If LAN traffic is unblocked, you shouldn't need to extra enable File and Printer Sharing, assuming your other devices are in the same subnet as your PC. Note that LAN in "Unblock LAN" in this case is defined as being on the same subnet as your computer (which is not 100% accurate, but is more easily understood for most people).
Is Secure Rules the option that prevents other apps from modifying the firewall rules? Then you should 100% disable it if you install TinyWall in parallel, because as I said, TinyWall will need to add a rule to WF if WF is running, and the Secure Rule option would prevent that. The general advice is, however, you shouldn't install multiple firewalls at the same time, even if you can. If you do, at least make sure that only one is ever active.
On the not-blocked connections I think a timestamp of when they were first established, or when they last passed traffic, might be interesting - but it's not a big issue for me. If you can't (easily) find a meaningful timestamp for active connections I would be inclined to leave that column blank for them rather than always updating to latest - because always updating gives the impression that something has changed when it has not. (Not sure how this effects your default sorting by timestamp - although blank could still sort to the top or bottom and make sense, I think.) I just tried clearing the tick now, while the system was still running, and all the sharing connections remained active. However, when I cleared the "File and Printer Sharing" exception tick (leaving "Unblock LAN Traffic" ticked), and then rebooted the system, the shares did not get reconnected on startup. I then put the tick back in and rebooted the machine again and still the shares did not get connected. I had to untick and then tick "Unblock LAN Traffic" to make things come back to working again. Something strange is going on, as now I have to untick and tick "Unblock LAN Traffic" after every reboot even with both options ticked, before the mapped drives will reconnect. I am (relatively) sure the connections were coming up properly after a reboot before. I just rebooted yet again (about the 6th or 7th time) - with both options ticked - and the connections came up on their own. A timing problem of some sort, perhaps?
Windows caches the availability status of the connection, I've seen this happen myself multiple times. For example, if you try accessing your shares while blocked, then you unblock File and Printer Sharing, and then you try accessing the shares again, it will still report the shares as inaccessible for a few minutes. At this point you either need to wait until windows decides to actively try the connection again, or you can reboot. It also caches the other way around too: if you list a share's contents, then you block the share, you'll still be able to list the same share folders for a few minutes (but you won't be able to list new folders not yet cached). This caching from Microsoft might interfere with your testing. I think this is what happened with you too.
I don't think it is a caching issue - I have seen that in the past. But in this case, after the reboot I see the mapped drive is showing disconnected and I click on it which would normally refresh its status, but instead it takes several seconds before it comes back and says the drive was not reconnected. So it was definitely retrying and not finding the share.
Hi. I came here searching for this exact issue and found this thread. It does this to me to, so I decided to register and tell you. The only way to enable file sharing or to connect with a mapped drive is to uninstall tinywall. I have done everything this guy tried and more. Other then that I love the program good work. Its so good i'm still running it and waiting eagerly for a fix. It should be noted I ran both the installer on the main site as well as the test version here that I found by searching. Gotta love google.
Something else I just noticed is if you have custom IPS in your /etc/hosts file on windows, when you enable blocklists they arent added to the new host file and essentially disable your custom IPS.
Why does TW add a rule to WF? But yes, I guess I can disable the Win Firewall when I install TW. The plan is to keep WFC installed in case TW is not ready for prime time yet. Also, does TW prevent apps from adding rules to WF, just like WFC does?
The reason is, when multiple firewalls are present that directly or indirectly use WFP (and WF is such a firewall), then a connection is blocked if it is blocked by any of the installed firewalls. So as a result, if WF is enabled, TinyWall wouldn't be able to unblock anything as long as it is still blocked by WF. This is especially critical for inbound connections, since the standard WF policy is to block everything inbound, which in turn makes it impossible for TinyWall to allow any inbound connections on a standard installation. So to solve this, TinyWall adds allow rules to WF. This does not mean though that things are allowed by default now, since all connections are still blocked by TinyWall. This is only to make TinyWall able to whitelist things when the user asks so. As a logical consequence of all the above, it is not necessary to prevent apps from adding rules to WF, because even if they do so, everything is still blocked by Tinywall (unless the user created an exception in TinyWall itself).
I still don't fully understand. If WF is disabled, then you would think that TinyWall doesn't have to worry about the Win Firewall anymore? No matter if it involves inbound or outbound rules. Yes, but what if you disable TW and enable WF again. Then you might have all kind of unwanted rules. That's why I wanted to keep WFC installed.
