Messages

Misconfiguration of multi-WAN is not unheard of (especially the finer details towards the end).
How about switching to failover as a test?

Personally, I'd use the Ubuntu over HTTP as a test case.
I suspect once you get that to work, MS updates will also work.

Not seeing anything blocking is not good enough.
There comes a point where you should enable logging of default FW rules and see the request in on LAN and out on WAN.
For the replies, you have to deal with network captures (can be pretty targeted with the Ubuntu update use case).

The Loadbalancing configuration works fine, it is not a failover setup but active/active - and I have already tested to reconfigure it to a single ISP setup with the same results.

I also collected packet captures and analyzed them in Wireshark, but that did not bring anything that jumped to my eye.

What I will do next is to capture packets with and with https for a Linux box, and compare those. And after that, totally uninstall Zenarmor as well, to see if that does anything.

My Windows updates work fine, so it is not a problem per se. What makes me think is this:

I had the same problem with apt-get on a Linux system in that test setup, I found that the standard config on Ubuntu uses http instead of https for the update URLs, once that was fixed in the Ubuntu config, updates worked fine.

Are you saying that you could not reach the Ubuntu http servers unencrypted over port 80, like, you cannot reach e.g. http://ubuntu.anexia.at/ubuntu-releases/ (do not try with your browser, it will immediately redirect to https)?

If so, then clearly, something is blocking your unencrypted http traffic, which might break Microsoft updates as well. You seem sure that there is no proxy involved. Maybe disabling Zenarmor is not enough, I would try to temporarily uninstall it. Then again, there can be many misconfigurations causing this.

Yes, that is exactly what I am saying, by default after installing, Ubuntu in the ubuntu.sources file have the sources as http URLs (not sure why they still have this) - as soon as I edited that file, to https, all was good.

And yes, that is why i was thinking of either http/https is causing it (Microsoft DOES use a lot of http calls in their updates, saw this in the packet capture) or certificate related.

I have not changed much in configs, in OPNsense, so there is not much room for misconfiguration, and I have not configured any Proxy as well and removed all DNSBL-relevant services but the behavior is still the same.

I may try to uninstall Zenarmor now as a next step, what is strange is, in none of any log files, be it on OPNsense or Zenarmor, can I find anything being blocked in regards to Microsoft updates.

Edit: Of course the other thing i tried is to just connect to a VPN (NordVPN) from one of the windows hosts, and as expected, that also fixes it, but as soon as I disconnect, the connection to updates times out again.

[remove]

What will happen, if you remove load balancing and stay with one ISP?
I'd suggest to check that.

I tried that too with the same result.

I am using Quad9 for DNS and I have considered if this may be the problem, but it is not. The testing I have done here is

1. Used Google DNS - same
2. Used Cloudflare DNS = same
3. Used ISP DNS - same

Also, the same DNS setup on my main setup (not via OPNSense) causes no problem.

I have looked for a few days now, and found some suggestions, but, none worked. So I am trying my luck here.

I am testing an OPNSense Setup, and generally, all works fine, except for Windows and Office Updates.

Some info about the setup:

OPNSense 24.7.12-amd64 with 2 ISP configured as load-balancing

The test setup is simple so no VLAN or anything, and FW rules of OPNSense for this test setup are left as they come in default.

Added Zenarmor and configured it - works fine, blocking of Windows updates does not happen there as updates are not working even when Zenarmor is in bypass mode

Checked Firewall logs and found no blocking for windows related sites

I tried disabling IDS/IPS - still the same result

No Proxy in use, and no TLS/SSL inspection in use

I had the same problem with apt-get on a Linux system in that test setup, I found that the standard config on Ubuntu uses http instead of https for the update URLs, once that was fixed in the Ubuntu config, updates worked fine.

I know that Microsoft uses a lot of http during their update instead of https, so I thought this might be the cause, but of course, Microsoft found no simple way to force all update traffic to go via https instead of http.

I saw a post that has the pretty much same problem described, but it had no replies was from 2020, and is now archived: https://forum.opnsense.org/index.php?topic=19253.0

Many other posts I found were around proxy and TLS inspection, which does not apply to me, as I am not using any proxy.

In short, my hunch is its either the http request that Microsoft uses for updates or a certificate-related thing.

Just wondering if anybody has the same scenario and found the root cause and a solution?

Thank's in advance!