URL Filtering Issue via VPN

[Zee]

Hi, 
I was testing Web/URL Filter on test firewall but the response is very random in terms of website getting blocked. I am not using Https inspection for now as I wanted to make a use case without enabling Https inspection and if it can get the job done, then it will save a lot of hassle. Currently, I am testing in a setup where my test machine is connected to production firewall and traffic is routed via VPN to my test firewall where I am currently testing. I have used almost all regex syntax that I could find and I can see dropped packets but the website still gives a random response i.e. it gets blocked but it works as well randomly. This is the session which is accepting the traffic with akamai destination but test website shows some blocked sessions. Let me know if I can find related issue resolution before further troubleshooting as I am new to checkpoint and still exploring. I think VPN decryption is overriding  HTTPS inspection behavior but I am a bit confused about the solution.
One side note, if I use pre configured checkpoint applications like Facebook, I dont see this issue but when I block some https website for example nayatel.com or yahoo.com, I see these VPN decrypted packets in logs and yahoo does not blocked and ignored the  configured rule for it. My test firewall is R81.10 Jumbo Hotfix Take 130 as it was not being used previously for testing.  I am basically confused about attached packet and want to take advice if this is what causing the issue or it could be something else. Thank You.

[Zee]

In my production environment, we will have around 2000 users, so I used Jmeter to send concurrent requests, but CPU spiked to full utilization. Just wanted to know the method normally used for this. 🙂

[the_rock]

Can you see if speed is way different? Just use fast.com or speedtest.net

Andy

[Zee]

I did not find any anomaly there.

[PhoneBoy]

R82 has a Learning Mode for deploying HTTPS Inspection.
You can see what the actual impact is with real traffic versus using some sort of testing tool. 
It's also better at handling situations where HTTPS Inspection cannot be done (client certificates and/or certificate pinning).

[the_rock]

I really like that feature, its brilliant.

Andy

[Zee]

Yes, we intend to upgrade to R 82 and also to use this feature in production environment but for current testing, it somehow spiked when I used testing tool, that is why I wanted to know the best practice to test this feature in a testing environment where traffic is not alot.

[PhoneBoy]

Use real traffic from web browsers to test HTTPS Inspection functionality and get a baseline of what to expect.
Note that any performance tests should replicate AS CLOSELY AS POSSIBLE real, production traffic.
This include accounting for:

• IP addresses used to generate test traffic from as seen by the gateway (use multiple, not just a single one)
• The ciphers used on the client and server as part of the TLS session (this will impact performance)

Best to work with your local Check Point office on this.

[PhoneBoy]

Are you also EXPLICITLY blocking QUIC traffic?
Web browsers use this by default where the server supports it and we cannot perform web filtering on it until R82.
Also, the reports from customers suggest R82 is better at identifying sites without HTTPS Inspection than prior releases.

[Zee]

Hi, No I did not block QUIC traffic explicitly. but after JHF upgrade it somehow fixed it for now. I just wanted to learn for my understanding that why it was happing and why there were attached sessions.