Windows Updates Blocked Without Firewall Log

B_P · ‎2019-08-20

HTTPS Inspection logs an inspect

IPS logs a detect

Firewall logs nothing

Client gets a "couldn't connect" error

tcpdump & fwmon shows some communication

HTTPS Inspection has "Bypass HTTPS ... for software update services" checked

R80.30

?????

Maik · ‎2019-08-20

Well, maybe you should start by providing more information besides the things that you can't see.

Which rule does allow the connection to the Windows update servers? Which blades are being used?

In addition to that, if you really shouldn't see anything at all and for the case where you are sure that the traffic is actually reaching the gateway try "fw ctl zdebug + drop | grep <source_ip>".

B_P · ‎2019-08-20

@MaikApp & URL blades are active as well. As I mentioned earlier tcpdump and fwmon show traffic (reaching the gateway and even the destination internet server responding).

tcpdump does not show any drops for the traffic.

The firewall rule that allows it is a rule that allows http/https traffic.

Maik · ‎2019-08-20

Did you confirm whether...

> the rule actually gets hits when this traffic is initiated (maybe a different rule gets used) [verify with logging ...]?

> the inbound and outbound traffic, that you already captured, looks the same or if some parts are missing (maybe IPS is kicking in)?

> what does "fw ctl zdebug + drop | grep <src ip>" show? Can you confirm any drops, related to this traffic, at all?

B_P · ‎2019-08-21

@Maikthe problem is the logging -- there is none with the Firewall. Only the HTTPS Inspection and IPS Inspection show logs (IPS is detect only).

The inbound/outbound traffic looks fine but it doesn't show up in the log.

zdebug drop does not show any drops for the traffic.

Maik · ‎2019-08-21

Well I guess logging is enabled? Its quite hard to give any advice regarding an issue if no information about the config and only what does not work is present. Maybe you can share screenshots of related rules (obfuscated if required).

B_P · ‎2019-08-22

Yes, logging is enabled.

HTTPS Inspection shows "Untrusted Certificate" in the log. However, "Drop traffic from servers with: Untrusted server certificate" is unchecked under HTTPS Inspection > HTTPS Validation. But, it appears the HTTPS Inspection isn't actually doing that -- rather it is in fact dropping the traffic or not handling it properly.

In the end, it was resolved by updating the Trusted CAs that don't automatically update for some reason.

B_P · ‎2019-08-26

Can anyone explain why the firewall is behaving this way? HTTPS Inspection has "Drop traffic from servers with: Untrusted server certificate" unchecked. Why was it blocked and why was there not a log saying it was blocked?

HeikoAnkenbrand · ‎2019-08-26

After enabling HTTPS Inspection on the Security Gateway, some resources that use HTTPS protocol (like Microsoft Lync) fail to connect.

Cause

There are two main scenarios, which can cause this kind of problem:

Inspect Rule: In the HTTPS Inspection policy, there is a rule related to the application, which specifies that it should be inspected. In this case, the application might fail the connection because HTTPS Inspection presents its own certificate (instead of the original site's certificate), which is signed by a dedicated CA. For browsers like Google Chrome and Internet Explorer, it is possible to make them trust the Security Gateway's CA certificate, but for some user applications this is problematic, or even impossible.

Currently, there is no solution besides bypassing the application as described below in the Solution section.

Bypass Rule: In the HTTPS Inspection policy, there is a category-based rule related to the application, which specifies that it should be bypassed. Currently, in order to bypass a site, HTTPS Inspection must know, which IP address is used by the site, so it can decide whether to inspect it or not. The correlation between the site's URL and its IP address is done on the first connection. The bypass mechanism is based on inspecting the site once and saving the IP address in the cache for bypassing it the next time a connection is opened to the same destination. Some user applications may fail to connect the first time due to attempted HTTPS inspection. The application should connect on the second attempt once the HTTPS bypass is in place.

If an error occurs during the SSL handshake, the Bypass based on categories will not work, the site will not be saved as bypassed and it will continue to be inspected. In such case, the application will always fail the connection.

Are you a member of CheckMates?

Windows Updates Blocked Without Firewall Log