Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
B_P
Collaborator

DNS VPN Link Selection Not Working

Jump to solution

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

Mix Public IP Mesh VPN Diagram.png

0 Kudos
1 Solution

Accepted Solutions
B_P
Collaborator

Got it figured out with the help of a SE.

A couple of notes:

  • The DNS-based VPN link selection works fine with the static host entries added in Gaia
  • Needed to redo the IPSec VPN certificates and add in both the public IP and FQDN of the firewalls
    • For example, GW-A's certificate I added gwa.test.com, gwa, gwa's privateip & gwa's publicip
    • Not 100% sure if they're all needed in there, maybe don't need just the host name by itself.
  • Related more so to managing a gateway via its public IP, I had to configure the built-in NAT settings on the check point host object for the management server.
    • I checked the "Add Automatic Address Translation rules", set to hide, tic "Hide behind IP address", enter in the local gateway's public IP, set the "Install on Gateway" firewall and check "Apply for Security Gateway control connections".
    • Without said setup, the GW-D would fail CRL checks during the VPN initialization. vpnd.elg logged fwFetchCRL_cb: "Fetch failed" and vpn1ValidateCertEvent had "Could not retrieve CRL." Not exactly sure why that specific NAT setup is needed since I was pushing policy and getting logs with a manual NAT config.
  • Needed to customize crypt.def to allow GW-D access to some networks over the VPN but not the others.

View solution in original post

0 Kudos
12 Replies
PhoneBoy
Admin
Admin

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.

0 Kudos
B_P
Collaborator

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.

0 Kudos
PhoneBoy
Admin
Admin

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...

0 Kudos
B_P
Collaborator

"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.

0 Kudos
PhoneBoy
Admin
Admin

I recommend engaging with the TAC to assist here.

0 Kudos
the_rock
Authority
Authority

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

0 Kudos
B_P
Collaborator

Thanks, but but no client access is involved, just site-to-site VPNs.

0 Kudos
the_rock
Authority
Authority

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.

0 Kudos
B_P
Collaborator

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

0 Kudos
the_rock
Authority
Authority

Looks okay to me...let me check this in the lab tomorrow morning and I will update the thread.

0 Kudos
B_P
Collaborator

Got it figured out with the help of a SE.

A couple of notes:

  • The DNS-based VPN link selection works fine with the static host entries added in Gaia
  • Needed to redo the IPSec VPN certificates and add in both the public IP and FQDN of the firewalls
    • For example, GW-A's certificate I added gwa.test.com, gwa, gwa's privateip & gwa's publicip
    • Not 100% sure if they're all needed in there, maybe don't need just the host name by itself.
  • Related more so to managing a gateway via its public IP, I had to configure the built-in NAT settings on the check point host object for the management server.
    • I checked the "Add Automatic Address Translation rules", set to hide, tic "Hide behind IP address", enter in the local gateway's public IP, set the "Install on Gateway" firewall and check "Apply for Security Gateway control connections".
    • Without said setup, the GW-D would fail CRL checks during the VPN initialization. vpnd.elg logged fwFetchCRL_cb: "Fetch failed" and vpn1ValidateCertEvent had "Could not retrieve CRL." Not exactly sure why that specific NAT setup is needed since I was pushing policy and getting logs with a manual NAT config.
  • Needed to customize crypt.def to allow GW-D access to some networks over the VPN but not the others.

View solution in original post

0 Kudos
PhoneBoy
Admin
Admin

Glad you got it figured it out.
And yes, the NAT for the management server is definitely needed.

0 Kudos