Some sites not working with HTTPS Inspection enabled

[AndrewSkull]

Good day!

I've got some strange problem, that started about a month ago (maybe after installing take 127). 

We have R81.20 Take 146 Gateway. And some sites (e.g. learn[.]microsoft[.]com) not working (do not open, browser debug shows nothing). Or some sites stop loading with 403 error on some scripts (www[.]ceair[.]com).  

I've tried to add theese sites to HTTPS bypass (by IP or by custom application) with no luck, although I see in log that bypass rule applies. But when I've added source computer to the rule that bypasses all traffic to Internet, sites started to work as expected. 

How can I find the source of the problem?

[simonemantovani]

Hello

could you explain better which kind of bypass you've configured (both working and not working rule)?

Did you check the content of file wstlsd.elg?

If you wish to perform a debug about HTTPS inspection you could refer to this SK: https://support.checkpoint.com/results/sk/sk105559

[AndrewSkull]

Hello!

Rules tried but didn't work:

1. HTTPS Inpection bypass rule by destination (IP of the hosts)

2. HTTPS Inpection bypass rule by Category/Custom Application (URL in RegEx)

I can see in log, that rule is applied and blade is bypassed.

The rule, that solves the problem is when I add my PC to the rule that bypasses HTTPS Inpection by source. But of couse it's not the option.

[simonemantovani]

To bettere understand, the rule that worked was configured setting you PC in source filed, and letting ANY in destination field?

[AndrewSkull]

Yes, you are right.

[jorgeluiznim]

Hi @AndrewSkull ,

Building on @simonemantovani's suggestion (the wstlsd.elg + sk105559 debug is exactly where I'd start too), I think the most important clue is in your own test:

You added the sites to the HTTPS Inspection bypass, the log confirms the bypass rule matched, yet the sites stayed broken — but bypassing the source host from all inspection fixed it.

That strongly suggests the breakage is not the TLS decryption / certificate re-signing itself. If it were, the HTTPS Inspection bypass would have fixed it. So something that still processes the traffic after HTTPS Inspection is bypassed is dropping it — most likely IPS/Threat Prevention, Content Awareness, or the server-certificate validation step. The full source bypass "works" only because it removes the traffic from every layer at once, which is why it doesn't reveal the root cause. The goal now is to isolate the exact blade.

The ceair.com screenshot ("The Requested URL could not be retrieved / Invalid Request") is a gateway-generated error page, so the connection is being actively rejected by a blade — not failing on the client side. learn.microsoft.com showing nothing in the browser points to a TCP/TLS reset earlier in the handshake. These may well be two different mechanisms.

A structured way to find it:

1. Identify which blade generates the block. In SmartConsole, open the drop/reject log for one failing ceair.com connection and check the Blade and Action/Reason fields. HTTPS Inspection, IPS, Application Control, Threat Prevention or Content Awareness? That one field usually points straight at the culprit.

2. Isolate by layer (temporarily, on a test host):

• Keep HTTPS Inspection enabled but set the Threat Prevention profile to Detect-only (or exclude the test host) → if it starts working, it's IPS/TP.
• Check the HTTPS Inspection fail mode and certificate validation (Gateway > HTTPS Inspection > Additional Settings😞 the "Drop traffic if the server certificate is not trusted / cannot validate revocation (OCSP/CRL)" options. If the gateway can't reach the OCSP/CRL responder, it drops the site silently — a common cause right after a Jumbo take (updated CA bundle), and it matches learn.microsoft.com failing with no browser error.
• Test whether it's HTTP/2 related — both sites are HTTP/2-heavy.

3. Debug. Following sk105559, enable the WSTLSD debug and reproduce, capturing traffic with both tcpdump and fw monitor at the same time:

# enable
for PROC in $(pidof wstlsd) ; do fw debug $PROC on TDERROR_ALL_ALL=6 ; done
# reproduce the issue, then disable
for PROC in $(pidof wstlsd) ; do fw debug $PROC off TDERROR_ALL_ALL=0 ; done
# logs:
$FWDIR/log/wstlsd.elg*

In parallel, fw ctl zdebug + drop | grep <client-ip> while reproducing will show if/where packets are dropped and the reason. sk108202 (Best Practices - HTTPS Inspection) is the canonical reference for the validation/exception settings.

4. Since it started ~a month ago after a Jumbo take: compare your current Take 146 against the known-issues, and if feasible test the latest recommended Take — HTTPS Inspection / TLS 1.3 / HTTP2 regressions do occasionally appear and get fixed across takes. If you can pin it to a specific take, that's strong evidence for a TAC case.

To narrow it down (and to answer @simonemantovani  question), could you share:

• The exact bypass rules — the one that "applied but didn't work" vs. the full-source one that did. Bypass by IP, Site Category, or Custom Application?
• The Blade / Action / Reason from the drop log of one failing connection.
• Whether IPS and Threat Prevention are active on that traffic.

With those we can tell fairly quickly whether it's certificate validation, an IPS protection, or an HTTP/2 / TLS handling issue in the current take.

Best regards,
Jorge Dias Junior

[AndrewSkull]

Hello! Thank you.

1. There are no any drops in log. The only record is Accept for firewall and Inpect/Bypass for HTTPS Inpection. If any other blade would drop - there should be records in log. I try to log everything to resolve issues with sites users can't open
2. Tried to add my PC to global exclusions. Nothing changed.
3. Enabled debug.

fw ctl zdebug + drop shows no packets dropped

captured traffic with tcpdump and fw monitor. Tcpdump shows TLS 1.3, fw monitor logs lots of Previous segment(s) not captured (common at capture start)

I’m not expert, but I didn’t find anything that could direct me to the answer

[simonemantovani]

You shouldn't find dropped packets; the bypass rule configured by adding the destination IP address of the site should work, unless the site you're connecting is performing any redirect to any other FQDN, or is trying to load some component from different site, and in this case, the SSL inspection is impacting the access to this resources that is not the main site you're requesting.

Maybe in this case, using the developer tools of the browser should give some information about the site/resources requested.

[AndrewSkull]

Debug in browser was ther first place I've started. Looking at Console it tries to load scripts from the same URL I have added to bypass rule. And from the same IPs.

[simonemantovani]

checking DNS resolution for your site I found this:

Nome: www.ceair.com.wswebcdn.com
Address: 157.185.129.11
Aliases: www.ceair.com

This was the IP address configured in destination field for the bypass rule?

If yes, there is no reason to explain why in your case, bypass worked only configuring the rule with your PC in source field; what if, you add the IP address of the site in the destination field in the working rule? Is it matched? Is it working?

[AndrewSkull]

This is the third IP. Looks like they have a DNS loadbalancer. From our location it is resolved to 163.171.142.80 and 163.171.157.54

This is my rule:

This is log:

And it doesn't help.

And I've done some testing. If I put this rule, that bypasses traffic to theese IPs before the rule, that bypasses traffic to specific URLs (Custom Application) - the site is working.

[simonemantovani]

And how did you configured the rule that is using Custom Application? Maybe there something that can be adjusted in the custom aplpication (maybe)

[AndrewSkull]

It's pretty simple and contains about 30 custom applications each consists of URLs in RegExp

I've managed to fix learn[.]microsoft[.]com by adding it as Domain object to the rule above the rule with Applications.

The problem is that several more sites completely don't work even when I bypass all traffic from my PC. I've tested on VM that has direct access to Internet with IP from the same subnet and sites work well. All these sites are in Akamai cloud so I can't just create static route for them to go past Check Point

[simonemantovani]

At the moment, for me it's inexplicable, and at the moment I can't test it on my side.

Could you also provide the regexp for the site you want to reach? Just for curiosity.

[AndrewSkull]

Something like microsoft\.com, teams\.microsoft\.com and so on.

[AndrewSkull]

And about sites in Akamai. Seems I've flooded them with requests and they banned me. I've changed NAT IP and this fixed it. So to conclude:

some sites get invalid request from the rule that bypasses traffic by URL. If I put the rule to bypass IP/Domain before the rule they start to work. I feel the problem is in bypass probe. Maybe sites use WAF that blocks wrong requests?

[simonemantovani]

I agree with you, it could also something like WAF, or similar that we don't know.