R81.20 "HTTP parsing error occurred" / body filter failed in response

[Romaryo]

Hello everyone!
We’ve encountered the following phenomenon: many websites don’t fully load when opened (for example, Reddit, GitHub, etc.). In the logs, we see the following events (see attached screenshots). At the same time, we notice HTTP parser errors, and despite the fact that we have the Allow Fail-Open mode enabled and the traffic is allowed, the sites still don’t work. In the browser’s debug console, we can see that connections for fetching *.js files are being reset.
Does anyone have any ideas about this?
Thanks in advance!

[Lesley]

I suspect based on screenshot you are running https inspection. I assume if you bypass problematic website, it works. What Jumbo take do you run? You blocked quic already? -> https://support.checkpoint.com/results/sk/sk111754

[Romaryo]

Hi! Yes, we are blocking QUIC. We had the same effect with JHF105 and also with JHF118 (currently).

[the_rock]

Are you doing bypass?

[Romaryo]

Sure, if we set up an HTTPS inspection bypass for the affected sites, the problem is solved. But we can't bypass everything — otherwise, what's the point of having full Threat Prevention?

[the_rock]

Not saying bypass everything, but certain things may need to be bypassed.

[the_rock]

One thing I would suggest is maybe going through below.

https://support.checkpoint.com/results/sk/sk112066

[the_rock]

I second all the points @Lesley had made.

[PhoneBoy]

Other than the fact the gateway can see the underlying HTTP connection as a result of HTTPS Inspection being applied, it's not relevant to HTTPS Inspection.
There is an Inspection Setting called Non-Compliant HTTP that can be disabled or exceptions can be set for.
This is set in Security Policies > Shared Policies > Inspection Settings and requires an Access Policy install to take effect.

There are other instances where this occurs where TAC may need to be involved.

[Romaryo]

Colleagues, during the process we discovered another very interesting phenomenon — for example, there is a specific link https://www.gesetze-im-internet.de/kaeano/KAEAnO.pdf : when accessing it through a browser, the connection gets "ERR_CONNECTION_RESET",

but when using curl or wget, everything works as expected 

wget https://www.gesetze-im-internet.de/kaeano/KAEAnO.pdf

StatusCode : 200
StatusDescription : OK
Content : {37, 80, 68, 70...}
RawContent : HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
X-Frame-Options: sameorigin
X-XSS-Protection: 1; mode=block
Keep-Alive: timeout=5, max=59
Connection: Keep-Alive
Content-Disposition: inline; file...
Headers : {[X-Content-Type-Options, nosniff], [X-Frame-Options, sameorigin], [X-XSS-Protection, 1;
mode=block], [Keep-Alive, timeout=5, max=59]...}
RawContentLength : 132767

[the_rock]

Do you have an extended log you could attach?

[the_rock]

Works like a charm in my lab.

PS C:\Windows\system32> wget

cmdlet Invoke-WebRequest at command pipeline position 1
Supply values for the following parameters:
Uri: https://www.gesetze-im-internet.de/kaeano/KAEAnO.pdf

StatusCode : 200
StatusDescription : OK
Content : {37, 80, 68, 70...}
RawContent : HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
X-Frame-Options: sameorigin
X-XSS-Protection: 1; mode=block
Keep-Alive: timeout=5, max=68
Connection: Keep-Alive
Accept-Ranges: bytes
Content-Len...
Headers : {[X-Content-Type-Options, nosniff], [X-Frame-Options, sameorigin], [X-XSS-Protection, 1;
mode=block], [Keep-Alive, timeout=5, max=68]...}
RawContentLength : 56456

PS C:\Windows\system32>

[Romaryo]

Right, everything works the same for me through wget (the file downloads and the correct TP policy matches), but on the same machine the connection is reset... when using a browser

[the_rock]

In my lab, bith R81.20 and R82, same machine works for the browser as well. Does any log show this is inspected by the blade?

[PhoneBoy]

I suspect this will require a TAC case to investigate, especially given you can reproduce the issue consistently.

[Romaryo]

What is particularly interesting is that everything works perfectly if the user is connected through the remote VPN access client. Also, there is no parser error and all websites are displayed normally. The internal network and the VPN network are both included in the role. Up to L4 everything works identically. If the VPN client connects to the internal company network, the issues start again. I just can’t figure out how to debug this…

[the_rock]

https://support.checkpoint.com/results/sk/sk105559

[Romaryo]

If I make a request through the browser, then I see the event log like in picture . If I make the request using wget, then it looks like in picture (wget). Pay attention to the interfaces… how can this be explained? bond4.509 is ext. Interface. 

[the_rock]

Let me try it in my lab. I thought wget would work on Gaia by default, but guess not.

[Romaryo]

Thanks!

[Lesley]

Saw this one solved today in latest take:

PRJ-62472, PMTR-117312

IPS

UPDATE: HTTP/1.1 requests missing host headers are now processed by the non-compliant HTTP Protection feature (Strict Parsing option). Previously, such requests were dropped immediately.

[the_rock]

Worth trying...not sure it may fix the issue, but does not hurt to give it a go.

[PhoneBoy]

The entry mentioning bond4.509 looks like a Threat Emulation log based on the icon here.
If you're not using an on-premise Threat Emulation appliance, it would explain the difference and why the external interface is used.

[Romaryo]

wir haben on-premise TE2000N. 

Unfortunately, English is not my strong side 😉 but I will try once again to describe the issue we are facing. We have three different network segments where client machines are located and they all need access to the Internet. These segments are: x.x.x.x (LAN), y.y.y.y (Wi-Fi), and VPN Remote Access Clients z.z.z.z. All three networks share the same Access Layer for Internet access, as well as the same HTTPS Inspection role. All three networks are included in the Protection Scope in the Custom Threat Prevention Role.
The problem is that clients have no issues downloading files or accessing websites when they are connected through a VPN tunnel (i.e. outside the company). In the logs we can see that the correct roles are applied and everything works as expected. However, as soon as the clients connect to the internal LAN or Wi-Fi, they start having problems loading websites and downloading files. At the same time, the traffic still goes through the correct Access Rules.
The most interesting part is that if we use curl instead of a browser on the affected machine, everything works…
From what I can see in Take 119, there are quite a lot of fixes related to TP and IPS — but I am not sure if they will help us.

[the_rock]

Wait, is this split or full tunnel?

[Romaryo]

full.

[the_rock]

So is this only site with the issue or they have problems with random websites?

[Romaryo]

rundom websites. Here are the logs. I use the site because it's very easy to reproduce the problem, but sites like reddit.com, hub.docker.com, and so on also have problems.

[the_rock]

Its very hard for me to say why that happens without doing remote sesison. Is it new issue or has been there for some time? Did you open TAC case already?

[Romaryo]

No, a TAC case has not been opened yet. It’s not clear when exactly this issue first appeared. Previously, we were using an explicit web proxy, but now we want to move away from it in favor of direct Internet access through the Check Point gateway and we want to make a PoC