Microsoft Updates Not Progressing
-
@stephenw10 Yeah I am starting to wonder if I have a DNS setup issue cause nothing seems to be work correct. Its not really blocking sites, even adult sites should be blocked regardless of pfblockerng because I am using cloudflares malware and adult site DNS values but they all still go thru. I followed so many different tutorials on DNS over TLS and making sure the devices only get their DNS form pfsense starting to question it.
-
If you have just entered cloudflare DNS in System > General Setup that will only do anything for clients if Unbound is set in forwarding mode. Otherwise it resolves dircetly and ignore those settings.
-
@stephenw10 Like this you mean.
-
@stormgate But I don't have this checked.
-
Yup, like that. In forwarding mode you should usually disable DNSSec also.
You don't need to have Unbound respond to DoT queries internally.
-
@stephenw10 Thanks yes DNSsec is unchecked.
-
@stephenw10 And these are the rules I was told to setup to make this all happen.
-
@stormgate said in Microsoft Updates Not Progressing:
@stormgate But I don't have this checked.
@stormgate said in Microsoft Updates Not Progressing:
@stormgate But I don't have this checked.
Windows 11 Pro might handle DNS over TLS port 853.
Windows 10 : no-go (but you could install an add-in utility).Btw : You only need to encrypt your own local DNS traffic if you do not trust your own wiring ;)
This :
only works if you set up each LAN client individually.
It's TLS - so you can't use a an IP, you need a fqdn, and this fqdn must be part of he certificate unbound uses to initiate the TLS traffic.
Like https..... (which is http over tls). -
Those rules are on LAN I assume?
That will prevent clients using external DNS and DNSoverTLS servers.
A rule with destination 127.0.0.1 can never match anything. Localhost like that is only valid on the host itself. Unless you have already added a port forward to redirect.
Those rules don't block DNSoverHTTPS so clients that use that will get real results.
You are ofetn better off redirecting DNS traffic to pfSense. That way anything hard coded with an external server, like 8.8.8.8, will still be able to resolve:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.htmlSteve
-
@stephenw10 Headed to work and will have a look, too me it didn't look right but not being an expert I took the recommendations on the rules. What is the best method on this device to take when it comes to up a secure DNS environment that works and allows the categories to be blocked correctly. I'll look at that link.
-
@stephenw10 I think I may see the issue, I do have the DNS over TLS NAT rule but I guess I need one for each VLAN, its only only setup on the Default Vlan. But maybe the rules themselves need some work also.
-
@stormgate
Why would you want to use DNS over TLS on the pfSense LAN side & VLAN side ?
You will be one of the first to do so among the pfSense user base, over 100 000 (this is very IMHO).
Again : you will have to configure every LAN/VLAN device ! See [https://en.wikipedia.org/wiki/DNS_over_TLS](https://en.wikipedia.org/wiki/DNS_over_TLS.It can be done of course.
I've installed a Windows 10 Pro DNS-over-TLS client just a couple of days ago.If you want to make your traffic invisible, go for the much simpler VPN tunnel.
Or do you really want to MITM with pfSense ? ;)
-
@gertjan Only because I thought DNS over TLS was a better secure setup, but I have no other reason. I would be prefer to set it up so its reliable and works for everything and yet secure. Would you simply recommend setting up DNS (53) with a some rules? This system is going to be thousands of kms away so I have no margin for error, so the most recommended setup is what I will adhere too. Thanks
-
Category based DNS filtering on the firewall can only be done via pfBlocker like that.
You can block DoH using IP lists in pfBlocker. Obviously that's not 100%
Firefox will look for a specific domain locally and not use DoH if it finds it. But users can still force it to use DoH.
https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-httpsSteve
-
@stephenw10 @Gertjan So much help you are giving me, ok I have cleaned up my rules and set everything as DNS(53), cleaned it all up. So DNS over TLS is no longer. Firewall was probably so confused with my rules.
-
@stormgate said in Microsoft Updates Not Progressing:
This system is going to be thousands of kms away so I have no margin for error
So DNS over TLS, locally ( not to be mistaken with DNS over TLS, used by unbound when it is in forwarding mode) is out of the question, as every device that connects to your local networks has to be setup correctly.
It can be done, but you need to be there. -
@gertjan Thanks, yeah I have moved everything back to the conventional DNS and now filtering works pretty good, rules look much better now. Still struggling with this Windows Update issue, they eventually download but it can take days and several retries, I'm at a loss where what exactly is causing the issue. This is a complete stand alone simulated network and everything is brand new. Running 2 stacked Aruba 1960's, the uplink to the Pfsense is using a 10GB connection, the stacks connections are fiber, and when I run a speed test over the internet I get the full speeds according to the package so that all seems right. All PC's are affected whether they are plugged in or over their respective SSID. I wish I had tried this prior to installing any packages like pfblockerng or snort but unfortunately I did not. I am not seeing anything like microsoft.update or anything, alot of IP's are being blocked but nothing I have looked into refers to Microsoft in anyway.
-
So it does seem Snort is the culprit, I actually think my one Windows 11 PC didn't have the issue with updates, however after really disabling and leaving for a bit it does appear that Snort is causing this windows update issue. I removed the package and reinstalled, and setup back up. I'll check it when I get home if updates are now ok. It doesn't seem to be throwing up nearly as many alerts.
-
@stormgate said in Microsoft Updates Not Progressing:
I removed the package and reinstalled,
That's a no operation.
@stormgate said in Microsoft Updates Not Progressing:
and setup back up.
That's where things go wrong.
You are using snort : you activated 'rules' or something like that (I never used snort) and one of the rules matches on the Windows Update traffic ....
Snorts logs ? If so, you can find 'what' to modify or what rule ( ? ) to disable and done. -
@stormgate said in Microsoft Updates Not Progressing:
So it does seem Snort is the culprit, I actually think my one Windows 11 PC didn't have the issue with updates, however after really disabling and leaving for a bit it does appear that Snort is causing this windows update issue. I removed the package and reinstalled, and setup back up. I'll check it when I get home if updates are now ok. It doesn't seem to be throwing up nearly as many alerts.
Unless you modify the Snort rules you have selected, you can expect the same issue to keep recurring.
I do not know your skill level with an IDS/IPS, so for the sake of simplicity I am going to assume you are new with such packages.
The admin MUST really understand the various types of rules used in an IDS/IPS and also be fully aware of the potential exposures (security vulnerabilities) present in their protected network(s) in order to properly select the Snort rules to use. This same level of knowledge is also needed to interpret resulting alerts from those selected rules to weed out actual "threats" from "false positives".
In reference to the paragraph above, I have seen many new IDS/IPS users install Snort or Suricata, go through and enable everything (or almost everything) without regard to the actual vulnerabilities in their network. Then they start getting a lot of alerts (blocks), stuff stops working they want to work, and they come here posting for help ...
.So how should you do it? First, choose the rules or rule categories that you enable carefully. Many rules are designed for things you may not even have present on your network. Two prime examples are mail servers and web servers (meaning public-facing servers). Another is a public-facing DNS server. So right away that means you don't need any of the rules enabled associated with those types of exposure. Another example is some categories of rules that are meant to be information only rules. The ET-INFO category is one of these. They will alert on things simply to let the admin know certain traffic is happening. You may be perfectly fine with that traffic, though, and don't want it blocked. For example, there are ET-INFO rules that can detect a DLL or EXE file being transferred. That rule would certainly alert (and block when Legacy Blocking Mode is enabled) with any Windows Update traffic. But you want that traffic to proceed, so why does such a rule even exist? Consider that you are a corporation and have an on-premises WSUS arrangement where you want internal clients to ONLY use WSUS for their updates. In that case, you might want the ET-INFO rules enabled on your WAN to make sure local clients don't go out directly to Microsoft for their updates and grab them instead from your WSUS. But for most home setups, you would not want to even enable the ET-INFO rules category.
Now the most important part!!
Select your rules and then run with them for several days or even weeks with blocking turned off. Regularly visit the ALERTS tab in Snort and investigate every alert you see, because once you turn on blocking mode each of those alerts represent blocked traffic. You want to determine if the alert is a false positive in your environment. If it is, you want to either disable that rule (best option) or suppress that alert (can be done on a per-IP basis if needed) to prevent those alerts and subsequent blocks. After running this way for a while you will have a tuned ruleset for your environment. Only then should you enable blocking.Note once again, this is not meant as a dig against you personally -- I'm just giving some background info and also leaving a message for anyone in the future that stumbles upon this thread when investigating a similar issue.
