- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Hi everyone,
Recently we deployed the Checkpoint Endpoint Security server on the Gaia OS hosted on Hypervisor. The endpoint server has 2 network interfaces one for management and the other is connected to the production network.
We exported the Client package with the MEPP security blade and installed it on a Windows Client machine. But the connection state shows disconnected.
The client is attempting to connect to the server on the management IP address of the server. Is there a configuration which will tell the client to communicate with the server on the production IP address.
There is also a proxy in-between, and the Client must go through it to connect to the server. The below log shows 407 which Indicates that the proxy server requires authentication before it will allow the client to connect. Where do I configure this proxy authentication settings? Is it on the checkpoint client or the server and how?
From cpda.elg:
2023-05-05 13:39:29.072 t:5548 root [debug] Sent request duration 250ms, URL: https://10.212.X.X:443/cp/connectionPoint/regep [CHTTPCall_curl::sendReq_internal]
2023-05-05 13:39:29.072 t:5548 root [error] Failed curl_perform, error: 56 (== Failure when receiving data from the peer), description 'Received HTTP code 407 from proxy after CONNECT' [CHTTPCall_curl::sendReq_internal]
2023-05-05 13:39:29.072 t:5548 root [debug] No server HTTP response code has been received, checking proxy response code if used [CHTTPCall_curl::sendReq_internal]
2023-05-05 13:39:29.072 t:5548 root [debug] CurlGetInfo, Proxy connect response code received: 407 [CHTTPCall_curl::sendReq_internal]
2023-05-05 13:39:29.073 t:5548 root [debug] tid: 5548 info, was deleted from map [CCertificateStore::reset]
2023-05-05 13:39:29.073 t:5548 root [debug] No through Direct, nor through proxy succeeded, setting return value to server error [CHTTPCall_curl::sendReq]
2023-05-05 13:39:29.073 t:5548 root [error] Failed to send request (or problem with response) [CCPPeer::sendReq]
2023-05-05 13:39:29.073 t:5548 root [error] Failed to send request (or problem with response) [CCPPeer::sendRaw]
2023-05-05 13:39:29.073 t:5548 root [error] Failed to send RegisterEndpoint message (or problem with response) [CDAProtocol::sendRegisterEndpoint]
2023-05-05 13:39:29.073 t:5548 root [error] Startup: Failed to register or update register endpoint [CDA::doRegister]
2023-05-05 13:39:29.073 t:5548 root [debug] Num of servers responding with the current ceCert.txt: 1 [CServerList::getNumServersCacertSuited]
2023-05-05 13:39:29.073 t:5548 root [info ] CurrentCP: CP selected or changed, cp: 10.212.X.X. Updating UI [CDA::CurrentCPChanged]
2023-05-05 13:39:29.073 t:5548 root [info ] Startup: All CPs tried, giving up for a while - registering/updating registration endpoint [CDA::doRegister]
2023-05-05 13:39:29.073 t:7324 root [debug] Update requested [CTrayProxy::runSink]
2023-05-05 13:39:29.073 t:5548 root [debug] Set DA error code to: 9 [CDAProxy::setDaErrorCode]
2023-05-05 13:39:29.073 t:5548 root [debug] ActiveCpSet: NONE [CDA::setActiveCPAvailability]
2023-05-05 13:39:29.073 t:5548 root [debug] Num of servers responding with the current ceCert.txt: 1 [CServerList::getNumServersCacertSuited]
2023-05-05 13:39:29.073 t:5548 root [info ] ConnectionState: Client is in DISCONNECTED state [CDA::updateClientConnectionState]
Thank you!
Hi Everyone,
I had to do the following to address the issues that we were facing:
Thank you for all your responses.
I would suggest to contact TAC to get this resolved asap !
Thank you.
We have opened the ticket couple of days ago. Checkpoint TAC are also actively working on it. Thought it would be helpful to post it on the community as well.
You can control what Endpoint Server addresses the client communicates with here:
SmartEndpoint > File Menu > Manage > Endpoint Servers
Authenticated proxy settings are accessible here:
HEP Web UI > Policy > Client Settings > Capabilities & Exclusions > General > Authenticated Proxy
Thank you for the response.
You can control what Endpoint Server addresses the client communicates with here:
SmartEndpoint > File Menu > Manage > Endpoint Server
This setting will allow you to add Endpoint Policy Servers to reduce the load on the management server, right? And the configuration is greyed out.
By default, the management server has the capability of a policy server, and it is assigned with management IP address.
Can we detach this capability and assign it to different interface on the same machine?
Authenticated proxy settings are accessible here:
HEP Web UI > Policy > Client Settings > Capabilities & Exclusions > General > Authenticated Proxy
This is not Harmony Endpoint. Endpoint Security blade is enabled on Gaia. I have enabled Endpoint Server Web Console as well but there is not "Client Settings" under Policy.
Which version of GAiA OS are you using?
R81.10 JHF Take 94
Harmony is the current portfolio name for most all things Endpoint related.
Starting E86.10 and above Harmony Endpoint Blades can access the Internet from an authenticated NTLM proxy with a logged-in user's credentials. This does not require any changes in configuration (client reads proxy settings from OS).
For other scenarios the credentials can be supplied/configured as above and I'm checking the Management requirements for the same.
UPDATE:
As a last resort, Checkpoint TAC recommended to reinstall to Gaia OS for Management server with only 1 network interface for both management and client to server communication.
That's a bit extreme I'd say.
Here's what I suggest you try assuming this is still a brand new config & you've only got a single agent attached.
Open SmartConsole, open your EPM server object and move to the NAT section. Tick the "Automatic NAT" option and select "Hide behind IP address", typing in your other interfaces IP.
This will add the other address to your "$UEPMDIR/conf/server_list.xml" file and cause Endpoints to try connecting to both IPs.
If you attempt this, make sure to re-export the client installation file, so it comes with an up to date server list. Clients which already successfully communicate with the server should receive the new IP through policy pull.
If you're already set on re-installing, this could be a quick thing to try.
Thank you for this. Will definitely try it and update here soon.
Nope. This did not add any IP addresses to the XML file.
The same thing I tried it in my home lab setup on VMware Workstation. It worked and the following IP that I configured in "Hide behind IP address" was added.
<valid_ipaddr>XX.XX.XX.XX</valid_ipaddr>
<valid_ipaddr6/>
But didn't work on our customer endpoint server. What must have gone wrong?
Thank you.
Could you post the steps you've taken?
I forgot to mention, but I believe the step "Install Database" needs to be performed.
Yes, installed the database multiple times. I even did uepm_stop & upem_start, cpstop & cpstart - didn't work. It was added only after rebooting the endpoint server.
Steps followed:
<valid_ipaddr>XX.XX.XX.XX</valid_ipaddr>
<valid_ipaddr6/>"
Still the status on the endpoint client shows "Disconnected" - I've attached the screenshot.
Did the change also reflect in the cpda.log file on the Endpoint?
It's unclear in the forum thread if the Proxy Authentication related issues got resolved or not.
My general recommendation (and the recommendation we give to customers) is to whitelist Endpoint server IPs in their proxy server configuration from HTTPS inspection & Authentication requirements.
There's also the added question of the proxy being able to even access the Endpoint server on the other IP address.
Generally speaking, I would suggest first "simplifying" the topology and bypassing the proxy entirely while you get to a known-working state on the Endpoint server.
Did they do any debugs that proved that was only option left? As @Swiftyyyy said, definitely sounds bit extreme in my opinion as well.
Andy
Yes, The TAC troubleshooted for 3-4 days. Collected CPInfo from both the server and client machine and concluded that we need to reinstall it.
As @Swiftyyyy suggested, I tried the NAT configuration in my lab environment, it worked. But not in our customer environment.
K, thats fair, if they did lots of troubleshooting and concluded reinstall is needed, thats acceptable.
Hope that fixes the problem...keep us posted.
Andy
Checkpoint TAC suggested for re-installation. But I have posted the solution that resolves the issue.
Hi Everyone,
I had to do the following to address the issues that we were facing:
Thank you for all your responses.
Awesome, thanks a lot for sharing.
Andy
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
5 | |
3 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Thu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY