Google Searches Odd Behavior

[jberg712]

I wanted to reach out to see if anyone has been experiencing similar issues.  We've had several users indicate to us that when they do Google searches and attempt to click on a link, it just hangs and spins.  You can click the address bar and hit enter a couple of times or re-click the link a few times and it finally goes to the link.  I can take the system out from behind the firewall and everything works seamlessly.  I've even put a troubleshooting rule to allow all outbound for myself to test and I still experience the same issue.  Strangely enough, if I use firefox, I don't experience the issue.  It's in Edge and Chrome which led me to believe a recent update occurred to created a problem.  But again, when I take the system out from behind the firewall, everything works fine.  So I don't know if there's a component in Chrome/Edge that CheckPoint is struggling with parsing or what.  Again, even adding a rule that allows all outbound access doesn't change the behavior.  Has anyone else come across this behavior?

[the_rock]

Mine shows 8.45 am, but probably cause im in EST, but yes, thats it, date is the same.

Andy

[PhoneBoy]

It seems there is an issue when URLs that are longer than 4096 bytes are encountered, according to TAC cases that mention a similar error.
Not sure this limit can be increased without a code change, which will definitely require TAC.

[jberg712]

Is this something fairly new that's been happening?  Has there been an SK or bulletin posted referring to this yet?

[PhoneBoy]

It appears this is recent from the limited number of TAC cases that mention this error.

[Lesley]

Regarding this error that has been posted before.

[ERROR]: rad_kernel_urlf_request_serialize: string len =4288 bigger than max 4096;

You say you see TAC cases with these error. Are the cases also related to issues to access Google services with HTTPS inspection? Or this error is related to any websites not Google specific?

[PhoneBoy]

The only way to see the full URL with most traffic is HTTPS Inspection.
It's not clear from the TAC cases if Google Services were involved in this or not.

[the_rock]

Just curious, are you blocking quic protocol or not?

Andy

[jberg712]

Yes we are blocking QUIC.  We actually disable it through Group Policy.  I did test with it on and the google searches with QUIC are doing better but that's probably because it's not being inspected.

[the_rock]

100% true...I tested it many times and blocking quic literally does nothing if proper bypass is not in place. Honestly, I would open TAC case and provide the debug.

Andy

[Lesley]

Can you try to whitelist *gstatic.com instead of the Google services in the bypass?

How is for example maps.google running after this?

[Lesley]

@jberg712 Hi, any news about this topic? Could you maybe share what debug you performed to get the RAD error message? 

[jberg712]

Hi @Lesley ,

So, I ran the APPI and NRB debug.  

fw ctl debug -buf 32000
fw ctl debug -m APPI all
fw ctl debug -m NRB all
fw ctl kdebug -T -f > /var/log/debug_kernel.txt

This generated a lot of data.  But it was in this debug that the rad_kernel_string_length error was found.

The latest update on my TAC case with this is that they are preparing a fix.

[the_rock]

Just word of caution...IF its custom fix, you install it on top of current jumbo, so IF you wish to install latest jumbo at some point, you will need to uninstall custom fix, reboot, then ask TAC to port to new jumbo.

Andy

[jberg712]

Thanks for that info Andy.  Yeah, i've enountered that a few times before and always ask if the fix will be included in the next JHA.  I generally prefer not to have a custom fix inhibit from updating my environment when needed.

It would be nice if they could come up with a method that a JH can go on top of a custom fix.  But I understand this is a linux environment and that can become cumbersome and create more issues/headaches.

[the_rock]

Sounds good!