What I meant is, for programs that want to use the internet, in some way. You might want to have a XAMPP installation, for example. Web servers do not work without incoming connections. Same is true for a lot of other programs, some chat protocols, multimedia gaming servers and so on. svchost belongs to the category of "Special Exceptions" and TinyWall will not learn exceptions for it. TinyWall will not learn rules for programs that have special exceptions, so it will not automatically create inbound (or outbound) rules for svchost. Although I agree in theory, in the real world there are many programs that do not work without inbound connections. TinyWall must make sure that it is easily possible to use any kind of program. Torrent clients are also affected, even if they work when inbound connections are denied, you will usually get higher download speeds if you allow incoming connections. But many programs need incoming connections to even basically work. Anyway, a user can visit the list of exceptions after auto-learning and remove inbound rights and make rules tighter. This is still much more easier than creating the rules from scratch in the first place. It can register the new rule but it will be immediately removed by TinyWall after that. There are a few milliseconds of an open time-window before the new rule is removed.
The latest beta seems pretty good to me. I guess I can make the next release the final 2.0. There is just a single bug report to investigate.
The new version is running good. It seems the rules are to loose by allowing * Outbound. Why cant you have the tighter rules (Http (S)) by default, and the * Outbound as second choice? Now I have to delete everything found by TW and set tighter rules.
Just thought I'd jog your memory on this feature request. This will be a kind of holy grail I think, getting the best out of usability and security. Still planning to implement it?
I got a new connection. It has an USB stick connection that does not have a router. So I noticed it needed totally new rules than my former cable connection. Witn my new internet connection i have also a a new cable modem connection. And TW now shows "Current zone: Public" after i answered to some prompt. I am not knowing if the new cable modem is in a router mode or if it even has one. But if so, should the zone be private instead?
I'm looking for a firewall that blocks ads and malicious IP addresses but allows some configuration. Will this added to windows firewall do that?
I use PeerBlock to block "ads and malicious IP". Plus it can block some or all the countries that you want, with Tinywall it's a sweet combination.
that's the combo i'm running at present - runs real well on win server 2008. this is a nice little firewall
There seem to be an issue where the computer cannot connect to some WLANs if TinyWall is installed and the latest Windows updates are applied. I can reproduce the problem but I am unable to find what I need to whitelist. If I whitelist svchost.exe as whole it works fine again, but of course I want to find the specific service that is responsible for it (instead of having to whitelist basically all Windows services). Has anybody has any clues what needs to be whitelisted? This is a must-fix/figure-out before a release is made.
TinyWall will keep your hosts file automatically up-to-date (once I re-enable the update server when releasing v2), but PeerBlock is surely a much more sophisticated solution. PeerBlock is able to block more hosts because it works completely differently and it also allows you selectively use certain/multiple lists. Its lists are also updated more often. The hosts-based solution of TinyWall is a generic solution that will perform well without compromises, but for advanced users or security enthusiasts I definetely recommend PeerBlock. TinyWall and PeerBlock supplement each other very well.
I know you are busy, but I hope you release the new version soon. MVPS HOSTS has been [Updated May-23-2012].
i was testing/configuring multiple APs yesterday and encountered an issue where it would hang on "identifying", then classify the network as "public" and fail to grab an IP via DHCP - is this the same issue you're talking about?
If it works again correctly when TinyWall is in Disabled mode (grey icon), then yes, it seems to be the same issue. If you are not worried about Windows' own services accessing the internet, then the easy workaround for now is to whitelist svchost.exe.
I think this is solved now - couldn't sleep, so I played the WLAN/TinyWall/Services/Process Hacker juggling game. Short version: disconnect from WLAN (gets you to public profile management in TinyWall.) Create a new exception for TCP/IP NetBIOS Helper (lmhosts) and allow outgoing UDP and TCP traffic. Do not restrict it to local network. At least for me, I can now connect to my router and have the network identified immediately. Interesting part is that this rule is required even if you disable the lmhosts service. Longer version: Without the rule in place, the connection process stalls after attempting to talk netbios with the router: Code: Connection history ----- UDP 68 0.0.0.0 67 255.255.255.255 Out IGMP 0 192.168.1.2 0 224.0.0.22 In HOPOPT 0 224.0.0.22 0 192.168.1.2 In UDP [53533] 192.168.1.2 5355 224.0.0.252 In HOPOPT 5355 224.0.0.252 [53533] 192.168.1.2 In [port 53533 varies, is a dynamic port] UDP 137 192.168.1.2 137 192.168.1.1 In HOPOPT 137 192.168.1.1 137 192.168.1.2 In UDP 137 192.168.1.1 137 192.168.1.2 In HOPOPT 137 192.168.1.2 137 192.168.1.1 In ...zZz... then finally DHCP offer comes through! UDP 68 192.168.1.2 67 255.255.255.255 Out If you disable lmhosts, the system process seems to take on the port 137 communication process, but you still need the lmhosts exception. I tried a rule that allowed in/out TCP/UDP traffic for lmhosts only on port 137 with no success, though I'm not sure why it didn't work. Someone else want to try adding the exception to their public TinyWall ruleset and see if that helps? Edit: whoops, didn't think the attachments would be inline. Connection list without the rule in place Rule added, lmhosts service set to Automatic Rule added, lmhosts service disabled Working exception config Failed rule attempt #1 Failed rule attempt #2
Wow, that really seems to be it. I can confirm (that at least on my laptop) this solves the issue. I'd never have thought that it is because of this service (even after seeing port 137) because NetBIOS over TCP is disabled on my computer - not the service itself, but in the TCP/IP adapter configuration dialog. Anyway, this seems to work. TECHNICAL RANT: As a side note, you mention that it does not work if you only allow outgoing. For me, it already works if I allow *only* UDP outgoing packet. Which is strange enough alone, because I can hardly imagine that UDP packets are usefull (in this scenario) without being able to receive any replies. But wait, it gets stranger! I started cross-referencing the default exceptions of the factory-default Windows Firewall, and the lmhosts service is not whitelisted anywhere. Port 137 is whitelisted, but for "System", not for any service specifically. WTF? And here's a second, even bigger WTF! lmhosts really must not be restricted to the local network, so it obviously is not needed to talk to your router (which is on the local net). So what is it for? Also of note, that this problem/issue only seems to exist since the Windows Updates of last month, so this is some newly introduced behavior. And, as noted both by sysinfo and me, it even exists if the service is disabled, either shut down completely or in configuration. END OF RANT Either way, although I'm pretty convinced that MS has done some messy things in their last updates, I cannot do anything but live with it and make a default special rule in TinyWall for it. The only thing left to figure out is the minimum amount of privileges needed. For me it works if I give it UDP out only, but sysinfo reports that more is needed. Could you make some more tests maybe?
Ok, now I think it's fixed - here's hoping. I hadn't tried "*" for UDP out, and that does work. I did some tests with different port ranges, and you have to allow Out UDP on port 67 for the lmhosts service. "But that's a DHCP port!" (well, that's what I said anyway.) And yes, it is but it's what lmhosts needs. I had only tried port 137 before since that's the netbios talk port. Why it works this way, I have no idea. Also, I think that maybe it needs to not be restricted to the local network because at the start of the connection process, you have no IP so the firewall sees the DHCP connections as 0.0.0.0 talking to 255.255.255.255? Whatever the case, the rule below works now for me and seems to be the least privileged exception. LMhosts UDP rule Edit: maybe found the cause of the change as well: Microsoft KB2688338 from May 8th, changed how Windows Firewall handles outbound broadcast packets. (CVE entry)
Is it possible for you to make a rule/option to block all Internet traffic unless you are connected to your VPN? This link shows instructions: http://practicalrambler.blogspot.com/2011/05/how-to-block-all-internet-traffic.html
Hi sysinfo, When I wrote earlier about MS having done some messy things in their recent updates, I have to take that back, because now it makes perfect sense. I should have figured this one out by myself, but I didn't put enough time into investigating it. Instead you invested your time and I am very thankful to you for that.
I think this is the same idea that we discussed a month or two ago: Did you mean, it's not possible in the current version, or not actually possible/feasible to implement at all? I am really hanging out for something with this feature
I meant it is not possible in the current version. Technically it sure is possible, but don't hold your breath. Now that TinyWall only creates inbound rules when necessary, this is not high on my todo-list right now.
