- Products
- Learn
- Local User Groups
- Partners
- More
Check Point Jump-Start Online Training
Now Available on CheckMates for Beginners!
Why do Hackers Love IoT Devices so Much?
Join our TechTalk on Aug 17, at 5PM CET | 11AM EST
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
The SMB Cyber Master
Boost your knowledge on Quantum Spark SMB gateways!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
Can Anybody PLease help me on this How to configure Check Point Security Gateway as HTTP/HTTPS Proxy
Thanks In advance
This is documented here:
How to configure Check Point Security Gateway as HTTP/HTTPS Proxy
hello Peter,
from sk "...Transparent - All HTTP traffic on specified ports and interfaces is intercepted and sent to a proxy..."
"
This means a process runs on the Check Point gateway that acts as a proxy. No 3rd party proxy would be required.
Thanks peter this was a great help....
and excellent work Sergei Shir and the SecureKnowledge Team!
they updated that sk110013!
"...and processed by the Proxy code in the Security Gateway..."
Thank You,
--
ak.
yes but i am not able to view it as m getting this pop up
As a picture typically says more than a thousand words:
Thanks Peter , do i also need to configure any outbound or inbound policy against this..
By checking the box, implied rules are put in place. You need to create rules as you usually would (internal lan > internet > http+https > accept). Take into account that the gateway creates the outbound (proxied) connection from the gateway and requires a DNS to resolve against.
Hi peter
Bothering u again.. When creating a rule shud i select service as http 80, https 443 or http+https proxy 8080
SAT
http/https only should be sufficient.
The http-proxy service would allow access to other proxies, which I assume you don't want
what is the diffrence in transparent and non transparent proxy how they behave???
In non-transparent mode, you must explicitly define the gateway as a proxy in the browser (directly or with a proxy.pac file stored on a different webserver). Transparent mode intercepts HTTP traffic on the specified ports and interfaces and sends it through the proxy without explicit configuration on the client side.
Hi Dameon,
in non-transparent mode, the security gateway will break the http/https connection (meaning 2 connections, from client to security gateway, security gateway to http/https web server).
1. my understanding is, in order to intercept the web traffic, the security gateway should listen to tcp/8080. when i login to the gaia os cli expert level, i did not see a listening port at tcp/8080 (netstat -an) or is there other commands to view this?
2. using http/https proxy, the gateway show spawn off a httpd process to intercept web request at tcp/8080. so may i know what is the process name and how to view this process from gaia os cli expert level?
Thank You
TH
netstat doesn't show it because it's not a process that is listening on that port.
The firewall kernel intercepts the traffic and "folds" it to fwd, which listens on a number of ports (not tcp/8080).
Thanks Dameon for the clarification.
If we can not test anything through netstat, how can we verify that the proxy works correctly? And how correctly to troubleshoot it?
In our case, we see logs, there are no deny actions, but the user does not have access to the Internet. On the test environment, I see this line:
[Expert@GW]# netstat | grep 8080
unix 2 [ ] DGRAM 8080 /tmp/pmsock
But in another environment I don't see it, and proxy doesn't work.
The most obvious first step would be to telnet to the firewall on port 8080 and see if it answers.
If it doesn't answer, then it might be a configuration issue or it might be something else.
Worth engaging the TAC in any case.
Hi Dameon,
I have a quick question; I'd like to configure the Gateway as a proxy as stated on this thread. However, in my case, I am using public ip addresses for internal resources. The reason, is that in this enviromnent (Azure), customer has overlapping vNETS.
Is it possible to have Gateway work with public ip addresses for internal resources while using proxy mode? I can't get it to work in this scenario sadly.
Whether the IP addresses are public or private shouldn't matter from our point of view.
Where you're going to have problems is if the IP addresses between public and private overlap in any way.
It's routing 101: how do I know which a.b.c.d address you're referring to?
This is generally solved with NAT rules that translate both the source and destination.
Thanks Dameon, yes we are handling the NAT rules as well. I've got it to work. Time to make this work in a multi Azure VNET as we have a limitation that we cannot peer them VNETS for internal BS, hence this approach with the public IPs.
I am a bit puzzled by the behavior of Transparent Proxy:
And yet, I could not verify that the proxy is working.
There are no log entries signifying its utilization and online proxy checkers do not indicate that the proxy is being used:
I have enabled the headers for explicit purpose of identifying that the proxy is working, but do not see any confirmations to that effect.
Is App Control enabled in this situation?
The blade is enabled, but the rule governing egress traffic from this host/network is a basic net--to--any--allow--log:
You probably need to set the log to Detailed or Extended Log (versus log) which will activate App Control for that rule.
I do not want to activate app control for that rule: the proxy function is unrelated to App Control/URLF, I simply want to verify that it is, in fact, working.
According to the external proxy tests, no proxy headers are being attached, which is not an expected behavior.
The feature requires App Control/URLF to the best of my knowledge.
Let's suppose it does, for the sake of argument. It is licensed and enabled on that gateway:
Right, but it's not enabled for the rule that's being matched.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY