Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
B_P
Advisor

Windows Updates Blocked Without Firewall Log

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

?????

0 Kudos
10 Replies
Maik
Advisor

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>".

0 Kudos
B_P
Advisor

@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.

 

0 Kudos
Maik
Advisor

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?

 

 

0 Kudos
B_P
Advisor

@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.

0 Kudos
Maik
Advisor

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).

0 Kudos
B_P
Advisor

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.

0 Kudos
B_P
Advisor

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?

0 Kudos
HeikoAnkenbrand
Champion Champion
Champion

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.

More read here:

Best Practices - HTTPS Inspection

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
0 Kudos
HeikoAnkenbrand
Champion Champion
Champion

Several HTTPS web sites and applications might not work properly when HTTPS Inspection is enabled on Security Gateway.

More read here: sk112214

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
0 Kudos
B_P
Advisor

Heiko, I'm not seeing how your responses or the doc pertain to my questions.

To be more specific: why, when I had "Drop traffic from servers with: Untrusted server certificate" unchecked, was the traffic being blocked (without a block log) when machines tried to access Windows Updates without updated "Trusted CAs"?

This is not due to applications "certificate pinning" as after updating the Trusted CAs in Check Point, everything started working as expected.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events