You have. 'Blocked' in this case means 'Filtered'. 'Allowed' means that everything is allowed. Look at the rule, you have to allow it access to the gateway.
What?? What gateway are you talking about? 'Filtered', you mean, filtered from connecting to the internet? Cuz isn't that what blocking does? I honestly couldn't understand anything of what you're trying to say. In your previous post you say blocking System is blocking important stuff, and thus he shouldn't block it if he wants to have internet connection cuz it's essential, but now suddenly blocking is just filtering, aren't those the same things?
The application is 'filtered' if you have any of the rules ticked in the 'rules' context menu. If nothing is ticked then the app is blocked. I see that you have allowed everything to Chrome for instance which is not good. Chrome should be sitting among the blocked apps, with comms ticked to allow only what's needed.
You mean the right-click rules menu? If so, there's nothing in System: https://i.lensdump.com/i/Av6LsM.png Yeah you're right about chrome, but honestly, I've never had problems with this, been using simplewall for a looong time. So I'm just gonna add it to the list of "to do" stuff, right below the other hundreds of stuff waiting for me...
I can see how this rule mechanism can be unintuititve at first and does indeed require some knowledge to deal with. Regarding System, I have a tick for the gateway address (192.168.0.1) but the comms are not blocked when I disable it. It's possible that I was wrong above regarding ARP, but I'll look into that when I find some time, not today.
No, you just explained it ********* . It's pretty simple, you create your own rules in settings -> user rules, and then you can allow a blocked process the ability to connect a certain way as defined by the activated rules for that process. And you activate rules by right-clicking the process, choosing rules and then you can see all your rules and activate them for that process, which is shown by the tick on the left side of the rule, that means it's activated, only for that process though. Or for more if you selected multiple processes at once. Also rules can be created from the notifications. Essentially rules limit how a process can connect. See, it's actually pretty simple Also, the point of making rules, is so that a process (or "application", w/e) only connects to legit stuff. But how would I know that? For example, right now I made 3 rules for chrome, all Outbound-only, for ports 443, 1900 and 9229. But let's say, after some time, I get a new notification. How would I know whether it's legit or not? With anti-exe and processes, one of the ways I know a process is legit is depending on where it's placed, since a malware is not gonna suddenly appear in system32 folder if I haven't ran anything before it. But with a firewall, how do I know which applications notifications are "legit" and which are "bad"? This is the entire purpose of using rules, otherwise you just allow the entire application and you're like "peace mother*******". You said we only allow what's needed, but that's the thing, how do we know what's needed? Can we be sure that everything's working even behind-the-scenes? Obviously when the web page refuses to load, it's pretty obvious that that connection is needed, but otherwise?
I know, I often don't explain things very well. And have been reminded of that on a couple of occasions. You have to know which local/remote ports are standards for certain protocols. With advanced users, this is known by heart, and not considered an 'extra knowledge'. For example, browsing always uses ports 80 (http) and 443 (https), DHCP is 67 and 68 DNS 53 etc. If an application asks anything out of these standards, you will immediately know that this is a susupicious behavior. This is what henry was referring to when he said that you "have to know what ports/protocols/apps use". If I take your post as a practical example I see two regular connections for Chrome but I also see 9229 port, this immediately looks suspicious as browsers do not usualy use that.
Ok, so 80 is for http, 443 is for https, I googled 1900 and it says it's for Universal Plug and Play (UPnP), although after blocking it I could still load pages, so idk what's really causing it, but I'm also using a 3g usb modem now rather than ethernet cable connection, so who knows. Although port 1900 connection is only asked once every 30 seconds, while port 9229 connection is asked continuously until allowed or notification is disabled. I googled 9229 port and most links point to https://nodejs.org/en/docs/guides/debugging-getting-started/ , seems like it's related to that. But it's also weird cuz I'm not running anything related to nodejs right now, and I have allowed node.exe. Also, the source is ::1:5xxxx and the destination is ::1:9229, the source keeps increasing, it started from somewhere around 52000 and now it's already around 57000 10 mins later. I also googled ::1 and wikipedia says it's a loopback address, and something about localhost and IPv6, but I have IPv6 disabled so idk what that could be. They're all [tcp] as well. Is there any way to troubleshoot this stuff and to understand what's the cause?
Yes this is IPv6 address, but I am not aware of the fact that localhost (loopback) uses that port. I do not have IPv6 disabled and Chrome never asked for that connection. This may be a valid connection specific to your system, for example it may be caused by an extension you use. Nevertheless it looks highly unusual to me. You can try disabling extensions, this is the only thing I can think of atm, and see if that changes anything. If not, and this is a valid concern, you can consider opening a new thread for better exposure. [EDIT] Sorry, missed this - What is that?
I have VS Code and nodejs installed on my pc. Node.exe is the process that nodejs uses. But I said it's weird cuz chrome is trying to connect through port 9229 while I'm not running any processes or anything related to that. I opened a new private session with ctrl shift n, extensions are disabled in private session, then I closed my normal session but chrome still made those connections to ports 1900 and 9229. I guess I'll check how it's going when I get back home on my cable
Regarding port 1900, it's a 'feature' on Chrome called Chromecast which uses multicast address to query compatible devices. That's about as much as I know about it, but this can be easily checked online. As for this runtime you're using, I have no clue how it works. It's possible that it uses a service/driver to inject itself into Chrome process, but I dare not guess beyond that. According to the above link you gave, it should only make this connection when you remote debug it. In any case, this is not a concern now that you said that you have it installed. Though you also have no clue how exactly it works.
This is very likely, since this protocol is a part of IPSec and as such resides in the network layer. And this layer is tied to the System process (NT Kernel). Yes. But I actually have very little experience with VPNs and it shows, otherwise I would have known that.
Ok, so it seems like opening chrome's dev tools automatically tries to connect to the node inspector, until chrome is reopened (before, it still kept going). Opening chrome://inspect , and clicking Configure on network targets, we can see the localhost ports are 9222 and 9229 (idk if you have this), and there's also a dedicated dev tools link there. And then I get connection attempts for a random port around 5000-5100, this time on IPv4 localhost, followed by port 9222 and 9229 on IPv6 localhost. I don't care exactly how it works, only that it's legit. @__Nikopol why don't you try turning off your VPN with blocked System and see if you have internet connection
Alright, then everything is explained. Opening dev tools indeed opens localhost comms. I was not aware of this as I never use dev tools.
I don't understand why this isn't working: So, I have this rule enabled for chrome.exe https://i.lensdump.com/i/AvsnCZ.png You mentioned port 1900 (and address 239.255.255.255) is for chromecast, I did some googling and among other things I found this as well https://productforums.google.com/forum/#!topic/chromecast/WsbZQaDt9Q0, where the "moderator" or whoever (says google employee) recommended disabling the #media-router flag. However, I checked and this flag is now gone, as confirmed by this https://bugs.chromium.org/p/chromium/issues/detail?id=651255 "- Remove --media-router flag as this functionality has shipped". However, there's a new flag called #load-media-router-component-extension, I disabled it, restarted chrome (a few times), but I'm still getting this notification every 1 min or so https://i.lensdump.com/i/AvsLwm.png , which shows that chrome cast traffic supposedly can't be turned off, but more importantly, that simplewall keeps alerting me despite me having the block rule for 239.255.255.255:1900 activated on chrome.exe . I even tried excluding 'user rules' from the dropped packets notifications and restarting simplewall but I still keep getting this notification
He's right and your're doing it wrong. As I noted a couple of posts above (maybe I did not explain it in the best way) ticking a box next to the app indeed grants it full outbound and inbound access. You can check this - disable 443 rule for your browser, but leave the box next to it it checked. Then refresh Wilders. Does it work? Regarding your issue down there, have you tried enabling 'loopback to all' option in the settings? Floyd, I am aware that Chrome makes that connection, that's why I said above that this is valid. If you allow it, then Chrome will make another attempt at remote UDP port 5353 - this is multicast DNS, also in relations with this Chromec**p. But with my previous firewall, WFC, I was able to block this. I ran simplewall again to check and I see the same as you. Moreover, as I said, if you allow Chrome to connect to port 1900, it will make connections to 5353, but this time simplewall constantly asks for this no matter if you block or allow it. Have you tried this? Something is not right with simplewall regarding multicast comms. That's right. I investigated this a month or 2 ago, but I concluded exactly the same. The flags are there, but they do nothing.
Tell me about it, man... Today I changed ISPs (that's why I was using 3g) and the new "device" that they gave me has sooooo many options and stuff, 95% of which I don't understand. It's not a "router" for sure. I think it's an EPON ONU https://www.fiberoptictel.com/what-is-epon-olt-and-epon-onu-2/ , I got to that page by googling the weird device model and one of the first few links was for EPON ONU. I've made an album with some of the pages - https://imgur.com/a/yIz9FaF (start from the bottom) Each of the main tabs above has its own mini tabs below it, each of them has their own mini-tabs on the left side. And yesterday with the 3g I didn't have those connections attempts in the album, they came with the new device. I also got connections to 192.168.1.4 through port 5353 (forgot source), and to 127.0.0.1 through port 5901, but unsure if the latter was for chrome or system. I haven't had problems with reappearing connections if they have been allowed as a rule, unless they have also been blocked as a rule (either only blocked, or both allowed and blocked as a rule). So no, the port 5353 connection does not appear again if I allow it as a rule for chrome. Some of the connections in the album are inbound, not outbound, my first inbound connections ever. Asides from all those connections, I also get connection to riot games server when I run LoL (riot games is the company making LoL), which is the top-most connection in the album, the address ranges from .72.x to .79.x, but blocking it does not seem to do anything, as is for all the connections. Also I'm not quite sure what the " :8 " means after 192.168.1.4 in that connection
The notifications you see (all except the first one) are IGMP. This is the group messaging protocol, and is most likely used by your ISP to check availability of nodes in a LAN. But I have no experience with IGMP and do not know how it is exactly used. The first notification you show is ICMPv4 protocol. The address is that of your PC, and the number 8 signifies the Type 8 ICMP packet (echo), popular 'ping'. These are not unsolicited packets. The inbound you see was requested by the outbound (if you look carefully you will see that an outbound igmp packet preceedes each inbound). Since igmp protocol is by design stateless a firewall can't know what has been requested and needs an inbound rule to pass the packets. Different remote IPs are the way in which multicast messaging (igmp) works. I hope this was (kinda) clear. Both of those are for System. As I said 192.168.1.4 is your IP and the direction is outbound for both of them. 127.0.0.1 is a loopback address that your PC uses to communicate with itself, this is how certain services work. [EDIT] This is not true, 5353 certainly is from either svchost or chrome, but here I'm guessing svchost. This is strange as it does here. What happens when you block 5353? Does simplewall ask again?
This is very misleading. There is no indication that this checkbox would do that. Well, now I know, but other might make the same mistake.
I agree. We are wrestling with this multicast on Chrome and needed rules. A user's manual is needed, I am suspecting that many will just tick the box (as Floyd and you did), as at first glance that makes sense. [EDIT]... and basically allow everything for an app.
I finally did that and I do have internet when the VPN is disconnected and I block System. I don't know what the real issue is here. The VPN goes through IPSEC/IKEv2 which should be a service and indeed the VPN-traffic comes from svchost.exe. (Over port 4500 and 500) I also found that svchost.exe is sending DHCP requests over 255.255.255.255:67 and 68. This is a broadcast address, like 127.0.0.1. I do not use DHCP myself and it's not used inside the VPN. I found that the DHCP service was on, as well as Network List Service and Network Location Awareness. Something must have activated them again. You just don't have any control over your device... grrr
Yes, this is for ALL rules. If I block them, even as a rule, next time simplewall will ask again, even when the user rules are excluded from the dropped packets notifications. Also, the port 5353 connection seems to be both inbound and outbound https://i.imgur.com/gZtnvtx.png https://i.imgur.com/RpGGmhp.png. However, it seems like chrome only asks for these connections once at start-up, haven't tested it. Try setting the permissions for those services so that it won't randomly get changed again - https://michlstechblog.info/blog/windows-set-permissions-on-a-service/ though if it did, likely something needed it, and next time something that needs those services will fail, though maybe that's what you want
