Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
D_TK
Advisor
Jump to solution

check point mobile site question

Hi - we are changing colocation facilities so the gateway that my RA users connect to is changing.  All of the sites on their client app were created by FQDN.  I have modified the DNS for that FQDN, my test users have flushed their dns cache, but yet they're still connecting to the old location.  when they ping the FQDN, it resolves to the new IP, but yet CPM is connecting to the legacy site.

Does CPM do something internally to tie the name to an IP?  If not, any ideas?

thanks.

 

 

0 Kudos
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin

We resolve the DNS name to an IP on first connection.
The site IP is what is written to the local client configuration.
The only way to change this currently is to delete and re-add the site.

View solution in original post

7 Replies
PhoneBoy
Admin
Admin

We resolve the DNS name to an IP on first connection.
The site IP is what is written to the local client configuration.
The only way to change this currently is to delete and re-add the site.

D_TK
Advisor

Thanks D, that's unfortunate.....i have hundreds of these.  any way to automate by changing a reg key or the like?

0 Kudos
PhoneBoy
Admin
Admin

It’s not a registry key, it’s the trac.config file that would need to be replaced.
You’d also have to stop/start the relevant services in the process.

0 Kudos
Norbert_Bohusch
Advisor

It will not help in your case, as your clients already changed it to the IP which they resolved.

But to don't run into the same issue again, you can enable the following in "trac_client_1.ttm" on gateways with RemoteAccess:

 

:enable_gw_resolving (
        :gateway (
                :default (true)
        )
)
:mep_mode (
        :gateway (
                :map (
                        :dns_based (dns_based)
                        :first_to_respond (first_to_respond)
                        :primary_backup (primary_backup)
                        :load_sharing (load_sharing)
                        :client_decide (client_decide)
                )
                :default (dns_based)
        )
)
:automatic_mep_topology (
        :gateway (
                :map (
                        :false (false)
                        :true (true)
                        :client_decide (client_decide)
                )
                :default (false)
        )
)

 

 

This is documented here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Heath_H
Contributor

Unfortunately, that doesn't help if you are using MEP in first_to_respond mode as I am.  We have multiple VPN entry points around the globe and use FTR so that the users go to the most responsive one based on their local network connectivity.  We don't use multi-tunnel currently due to routing issues with a full-mesh MPLS backhaul network that makes that hard to configure and support.

 

h

0 Kudos
Norbert_Bohusch
Advisor

Shouldn't then, if you change the IP of one VPN endpoint, the client be able to connect to other endpoint and by that aquire new list of gateways?

0 Kudos
Heath_H
Contributor

The docs really aren't that clear, but my understanding is that, if you use "dns_based", that you have to provide some form of DNS load balancing and direction outside of Check Point.

So you are technically correct, that MEP will hand out all IPs to the client in the trac_client.ttm file.  But then you have to update the ttm file on all gateways to reflect the new IP address and install policy on each of them.

 

Is there a way to configure DNS resolution _and_ MEP?  And before anyone says that it's a security risk because "you can't trust DNS", isn't that the whole point behind the fingerprint verification that the client does?  The client doesn't trust the IP address either.  I already have DNS entries and public trusted certificates on my gateways for MAB.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events