- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
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!
A public IP managed gateway is refusing to connect to the other gateways in a Mesh VPN (site-to-site) by their public IPs. Instead, it tries to connect to their internal (management) IPs. What's odd, it will do some initial connections via the public IP, then switch to the internal IP as evident in the logs with 'tunnel test' going to the internal IP. I'll also see the VPN show up briefly under the 'vpn tu' utility with the internal IPs. The internal gateways connect to each other just fine.
Gateway 'GW-D' is managed via its public IP. The other three gateways 'GW-A', 'GW-B' & 'GW-C' are all managed via their internal IPs.
I'm following the documentation here for DNS Resolving Link Selection. I have the gateway and FQDN of the gateways added to the Hosts at "Gaia Web > Network Management > Hosts and DNS > Hosts". I can ping the gateways via FQDN from the other gateways just fine. But, log continues to show GW-D trying to connect to GW-A via its internal management IP instead of the public IP as defined by Link Selection and the FQDN. I've tried both "Full hostname" and "Gateway's name and domain name" (with domain set in Global Properties) but neither work. What am I missing?
Not having any luck with VPN-Tunnel interfaces either.
Edit: diagram
Got it figured out with the help of a SE.
A couple of notes:
What precise version/JHF are all the gateways?
Are any of them configured as DAIP?
And are all the gateways managed by the same management?
Generally, resolving Link Selection via DNS only really applies when one endpoint is configured as a DAIP.
Is there a specific reason you're doing it this way?
And what IP is the hostname of GW-A associated with in the manual configuration?
If internal IP, you might need to change that.
What precise version/JHF are all the gateways? - R80.40 T120
Are any of them configured as DAIP? - No
And are all the gateways managed by the same management? - Yes
Is there a specific reason you're doing it this way? - No. I am not sure how else to tell GW-D that it needs to connect to GW-A via its public IP yet still let the other gateways connect to GW-A via its internal IP.
And what IP is the hostname of GW-A associated with in the manual configuration? - GW-D has the public IP of GW-A in its Gaia hosts including GW-A FQDN. Not 100% sure that's what you're referring to. The GW-A check point gateway object itself has an internal IP set which is how management connects to it.
The only way you can choose a different IP for a different peer is via routing.
Theoretically DNS will do that.
What is your Outgoing Route Selection settings?
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_SitetoSiteVPN_AdminGuide/htm...
"Operating system routing table" and under Setup, I have "Reply from the same interface". Under "Source IP address settings" I have "Automatic".
@PhoneBoy wrote:Theoretically DNS will do that.
Yep, need to find out why it's not adhering to the settings.
I recommend engaging with the TAC to assist here.
Have a look at below:
sk131612 Remote access VPN link selection with DNS resolving
sk103440 How to force Remote Access VPN Client to resolve DNS name of VPN Site at every connection
Thanks, but but no client access is involved, just site-to-site VPNs.
K, understood. I read your post carefully and here is my question. If you go to gw-d and run ip route get x.x.x.x (whatever public IP is of gw-a), do you see right output? Also, try it for internal IP of the gw-a and see what you get.
Yes, the output looks good. For reference:
#ip route get gw-a_public-ip
gw-a_pub-ip via gw-d_internet-next-hop-ip dev eth0 src gw-d_pub-ip
#ip route get gw-a_private-ip
gw-a_private-ip via gw-d_internet-next-hop-ip dev eth0 src gw-d_pub-ip
eth0 is internet interface on gw-d
Looks okay to me...let me check this in the lab tomorrow morning and I will update the thread.
Got it figured out with the help of a SE.
A couple of notes:
Glad you got it figured it out.
And yes, the NAT for the management server is definitely needed.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
18 | |
11 | |
6 | |
6 | |
6 | |
6 | |
6 | |
4 | |
3 | |
3 |
Tue 16 Sep 2025 @ 02:00 PM (EDT)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - AmericasWed 17 Sep 2025 @ 04:00 PM (AEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - APACWed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasTue 16 Sep 2025 @ 02:00 PM (EDT)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - AmericasWed 17 Sep 2025 @ 04:00 PM (AEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - APACWed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY