@askmark @ultim Thanks for the information. I've never used TinyWall in the past, so let me say/ask a few things: If i only want to allow outgoing traffic i need to pick the 3rd option "Allow outgoing UDP and TCP traffic" option for each application, correct? What does the "Restrict to local network" mean? The "Show Connections" don't support F5 refresh The "Application Exceptions" don't support delete key The "Special Exceptions" checkboxes seem clunky. Need two clicks in order to tick checkbox. Clicking in white space check/uncheck the checkbox. See example: https://gfycat.com/impracticallivelygreyhounddog
Well, I downloaded Tinywall 2.1.11 and it still have problems with network discovery. It's the same problem since version 2.1.8. Every time I revert to 2.1.7 it works. So is back to 2.1.7. I'm in windows 8.1 64 pro. Does anyone have version 2.1.8 and above working with network discovery? If so please tell me how. I have tried everything, maybe is something obvious that I have missed. (Obvious, sometimes tend to hide from view.) Thanks in advance.
Yes, for most. For some applications like VPN clients or traffic analyzers like Wireshark you might need to choose the unrestricted option though. It means the app (in addition to other restrictions like port numbers you set) will only be able to communicate with devices in your home, but not with the internet. Thanks for the feedback. I'll evaluate each idea.
Hi, for you I recommend to wait for the next beta build and try that. Until then please keep using 2.1.7 if that is what works for you.
ultim, will do, thanks. I was curious if the latest had it fix. I love your creation. I had it in window 7 and now in windows 8.1. I'm planing to move to windows 10 in 2023 when windows 8.1 goes off the edge. I love 8.1 because it has worked perfectly in every computer I installed it. For me win 8.1 and Linux is a great combo. Win 10, not so much. I figure maybe windows 10 might get out of Beta in 4 years. (Doubtful) Some people can deal with the mess, I can't. Most of the people that I know is still in 7,8.1 or Linux. The people that I know that have 10 it seems to me are in perpetual Beta. MS pushes an update and their computer goes bonkers. I love the idea of blocking anything coming in and going out until I say otherwise.
@ultim 1- Tinywall's blocklist function prevent Adguard For Windows to connect to its service and load properly. The connection is shown as Blocked in Show Connections but unblocking it has no effect as well as making Adguard.exe or AdguardSvc.exe an exception. Disabling Blocklist is the only way. 2- TW blocks MS Edge dev (the new edge based on Chromium) to update, its process (microsoftedgeupdate.exe) stay blocked despite unblocking it. Blocklist was disabled.
Back in the day, when I was young, to Beta test, Tiny Firewall {which was so innovative}...until CA bought tnem. If I, configure it wrong, I cannot even log in—we did it here on Wilder's and DSL Reports. But, that's...'When the World was Young' I run MS Edge in 'Application Guard'. I mean no disrespect, Robert
Hi, that was not TinyWall though. TinyWall is a totally and completely different product from Tiny Firewall. They ended up with a similar name by pure chance, but have not a single line of code or developer in common.
@ultim A problem similar to guest has with Adguard: Tinywall with "Port-based malware blocklist" option enabled prevents SABnzbd (sabnzbd.exe) from starting up and listening on tcp 8080. This is even with Tinywall's firewall mode set to 'disabled'.
To be honest, I don't really like to test software, unless they are already bugfree for the most part. OK, then I guess I misunderstood. But I just read that the new TinyWall is not simply a front-end for the Win Firewall. Why did you make this change?
even though i have ICMP traffic enabled in TW, ipv6-test.com tells me that my ICMPv6 traffic is being filtered. also, ipv6.google.com is unreachable in chrome. i have disabled Windows Firewall and chrome is one of my whitelisted executables. this is the newest beta, downloaded and installed today.
TinyWall is a firewall and will stay a firewall. What changes with TW3 is that it is no longer just a GUI for the built-in firewall for Windows, but TW is now going to be responsible for communicating with the kernel and creating the kernel filters directly. Why? Because this allows me to ignore the idiosyncrasies of Windows Firewall and not be bound by its limitations anymore. In turn some long-standing issues with TW are solved, like incompatibility with MS services and spontaneous network disconnections, to name just a few, but there are more.
Define "soon" I was on holiday for the most part in the past week, but I just finished a hotfix (2.1.12, already available) for the stable release. The next beta will come when I've incorporate the feedback from the current testing round, and also I want to get its auto-update function up and running again before making a new beta available.
I see there was a dispute on the topic, in relation to the pop-up "feature".I ve used WFC for some years and told others how to use it, without the pop-up feature.WFC was usable without the feature.As long as the log shows what was blocked, to solve some strange connectivity issues when needed, there is no problem whatsoever to not have the dialogs poping up. Alexandru managed to block the infamous annoying rules auto-creation, "disease" that resides within the build in Windows firewall. The problem that I ve observed with the new firewalls, since the W7 inception, is the inability to block completely connections at start-up, at every start-up.. I ve found version 2 buggy in the past. I will install beta 3 version to see how it goes, for the fun of it..
If one of your goals with testing TW3 is to find out if it blocks connections at startup, I suggest you wait a bit more. The beta of TW3 does not yet support boot-time filters, but it is coming (just a fair warning). So if you're gunning for that feature you should wait for a later build. Otherwise I am happy for any and all feedback and am looking forward to your opinion too.
Alright but Persistent filters which are stored persistently in the BFE service (in the registry) and applied while the BFE is running are indeed filtering connections at start up as per user created rules in this beta version, correct? I don't want some applications to connect neither at startup nor at anytime during using my machine.
It was only while updating to Windows 10 1903 that I discovered TinyWall development was active again and so reinstalled it (so much simpler than anything else I've ever used). But I have run into difficulties that I think are probably the result of TinyWall reloading the Firewall rules when something outside TinyWall changes them. For example at midday today I see the follow message in an event log from TinyWall v2.1.11. Reloading firewall configuration because C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.1907.4-0\MsMpEng.exe has modified it. The timing coincides with the dropout of a network connection to that machine (a large file held open for writing on a share on that machine lost some data because the connection reset very briefly). Later in the evening a connection to a different machine (this an ordinary TCP/IP rather than a network share) dropped out very briefly, and the timing coincides with the same event log message (7 hours later on a different machine). I don't recall having this problem the last time I was using TinyWall (v2.1.7), but maybe Windows wasn't updating the firewall so much back then. Whatever, it does lead to a few questions: Does what I describe make sense? (It seems logical but I'm not really sure what TinyWall does during a reload. Perhaps I should be looking elsewhere, but the message in the event log seems only thing I can find that corresponds to the dropout problems - and it has matched to about 8 occurrences so far.) Is it something I can work around by defining explicit rules instead of relying on "Unblock LAN Traffic"? (All the problems so far have been dependent on the "Unblock LAN Traffic" option being ticked. The File and Printer Sharing exception might fix the share dropout, but will not fix the other one. I am wondering if maybe explicit rules are left untouched by the reload process. I guess I can experiment with this for myself.) Is this reloading of the rules something that TW3 can avoid? (Is it worth me trying it out on the various machines I have here? I'd just jump in but these are work machines and I'm a bit nervous about running a beta on them.)
OK cool. The reason I asked is because I was just getting used to simply using the Win Firewall for protection. And if I install the new TW, can I keep WFC installed? I guess I can put it in "low filter" mode and "Secure Rules" can stay enabled, since TW isn't adding any rules to the Win Firewall. Will blocked and allowed connections by TW show up in the WFC log?