- Products
- Learn
- Local User Groups
- Partners
- More
What's New in R82.10?
Watch HereWhen the Agents Attack
A Live Look at Agentic Exposure Validation
AI Security Masters E8:
Claude Mythos: New Era in Cyber Security
CheckMates Go:
CheckMates Fest
Hello everyone,
I am reaching out regarding an issue with Remote Access VPN connectivity and I would appreciate any insights.
When I try to create a new site connection using the Endpoint Security VPN client from a public network (such as home WiFi or mobile internet), the connection fails with the error: “Site creation failed. Failed to create the new site. Site is not responding.”
However, when I perform the same test from a DMZ network, the VPN connection works without any issues. I am able to connect successfully using the VIP IP address and everything functions as expected. Additionally, the Site-to-Site VPN tunnel is up and running correctly on the same interface (that is VIP IP).
In terms of configuration, I have two gateways configured in a ClusterXL setup and the VIP address is used for VPN communication (Remote access for clients and Site2Site VPN). Now, I am on product version Check Point Gaia R81.20.
My questions are the following:
what could be the reasons why Remote Access VPN does not work from a public network, while it works from internal or DMZ networks?
Also, is it possible to assign a separate IP address for the Site-to-Site IPsec tunnel instead of using the VIP address, in order to separate it from other VPN services?
Thank you in advance!
Hello
could you try to share any screenshot you can about the VPN configuration?
Did you try to catpure traffic on external interface of the firewall, to see if your traffic for site creation is arriving?
Thanks.
I solved this problem but I posted this question that I don't get any response.
Could you please give me more information about this: is it possible to assign a separate IP address for the Site-to-Site IPsec tunnel instead of using the VIP address, in order to separate it from other VPN services? This address must be subject of device failover, not only physical interface address.
Thank you in advance!
For what I know, you can only use IP addresses (VIP) configured on the firewall ... so the right answer is no you can't, unless you have two differente Internet connections .. and in any case it add complexity in my opinion; if you have only one internet connection there is no real reason and advantage to separate vpn service (and as I told you, is not possible).
Thank you for your quick response.
Everything is working fine now. I just wanted to ask for clarification for future reference in case I need to introduce additional services or make changes to the setup later.
Check out these settings. Second screenshot have impact also for normal site to site tunnels!
Second check traffic logs if https port is allowed. This is needed to setup the client VPN.
Thank you for your suggestion.
I have already reviewed and applied these settings and the current setup matches what you described. I also checked the traffic logs and verified that ports (UDP 500, UDP 4500, HTTPS 443) are allowed.
If possible could you please share a screenshot from the Network Management / Topology section (interfaces view)?
I would like to compare the interface configuration and topology settings to see if there are any differences that might explain the issue.
I have also created a simple diagram to illustrate my setup:
My side is a Check Point ClusterXL using a VIP address for VPN communication
Remote Access clients connect through the same VIP
There is also a Site-to-Site VPN tunnel to a 3rd-party (non-Check Point) device
Both Remote Access and Site-to-Site are working internally, but Remote Access fails from public networks.
Do you think this setup looks correct or is there something obvious I might be missing?
Thank you in advance.
I would like to inform you that the issue has been resolved.
The problem was related to the Link Selection configuration. In IPsec VPN > Link Selection, I changed the setting from “Selected address from topology table” to “Statically NATed IP” and specified peer address.
After this change, Remote Access VPN works from public networks and the Site-to-Site VPN is also functioning correctly.
Thank you all for your help.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 13 | |
| 12 | |
| 9 | |
| 7 | |
| 7 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 3 |
Thu 02 Jul 2026 @ 06:00 PM (CST)
Revolucionando la Seguridad con IA Generativa: Prevención Inteligente en Tiempo RealThu 09 Jul 2026 @ 10:00 AM (CEST)
Schutz souveräner Workloads: Check Point & die AWS European Sovereign CloudThu 09 Jul 2026 @ 11:00 AM (CEST)
The Cloud Architects Series: Check Point Edge Protection SD-WAN & SASETue 14 Jul 2026 @ 10:00 AM (PDT)
AI Security Masters E11: READY OR NOT: Securing the AI Enterprise 3/5 - AI Workforce SecurityThu 30 Jul 2026 @ 10:00 AM (PDT)
AI Security Masters E12: READY OR NOT: Securing the AI Enterprise 4/5 - AI GatewayThu 20 Aug 2026 @ 10:00 AM (PDT)
AI Security Masters E13: READY OR NOT: Securing the AI Ent 5/5 - AI Research & Threat LandscapeTue 14 Jul 2026 @ 10:00 AM (PDT)
AI Security Masters E11: READY OR NOT: Securing the AI Enterprise 3/5 - AI Workforce SecurityThu 30 Jul 2026 @ 10:00 AM (PDT)
AI Security Masters E12: READY OR NOT: Securing the AI Enterprise 4/5 - AI GatewayThu 20 Aug 2026 @ 10:00 AM (PDT)
AI Security Masters E13: READY OR NOT: Securing the AI Ent 5/5 - AI Research & Threat LandscapeThu 02 Jul 2026 @ 06:00 PM (CST)
Revolucionando la Seguridad con IA Generativa: Prevención Inteligente en Tiempo RealAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY