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

DNS Redundancy for VPN Remote Access

Hello everyone!
I hope you can help me with a question I have for a project with a customer.

  • We currently have a lab environment where I have:
    • SMS - R81.20 JHF 98
    • FW1 - R81.20 JHF 99
    • FW2 - R81.20 JHF 99
  • Each Firewall (FW1 and FW2) has VPN Remote Access enabled and both are in the VPN community of “RemoteAccess”.
  • I have a domain name, which for this example I will call vpn.company.com
    Currently, the DNS record for that name is pointing to the public IP of firewall 1.

 

I would like to know how I could generate a DNS redundancy when I have the following scenario:
-When FW1 is down and inactive for some reason.
-Subsequently, we will modify the DNS name vpn.company.com so that it now points to the public IP of FW2
-However, we want to know if there is any configuration so that we do not have to reconfigure anything in the Remote Access VPN Client so that it can now resolve to the same vpn.company.com domain but now pointing to FW2

In other words:
-Remote Access VPN client I configure it only once with vpn.company.com
-And after making the necessary configurations in Check Point for this DNS redundancy.
-And there is an event where FW1 goes down and FW2 is now the primary.
-That VPN client, just by pointing to the vpn.company.com domain, is directed to FW2 without reconfiguring anything (without needing to recreate the VPN site).

is this possible?


Doing some research, I think the configuration we need is the following in the file $FWDIR/conf/trac_client_1.ttm

automatic mep.png

enable gw.png

mep mode.png
ips of gw.png

 

Is the information correct?
Do I need to configure anything else?

I hope you can help me.
Greetings!





0 Kudos
1 Solution

Accepted Solutions
the_rock
Legend
Legend

Hey @israelsc 

Im fairly positive this is the sk you need to follow. My colleague and I did this for a customer back in 2021 and works fine.

Andy

https://support.checkpoint.com/results/sk/sk103440

Also, not 100% certain if below is also required, though I believe we also did this one:

https://support.checkpoint.com/results/sk/sk131612

View solution in original post

0 Kudos
5 Replies
the_rock
Legend
Legend

Hey @israelsc 

Im fairly positive this is the sk you need to follow. My colleague and I did this for a customer back in 2021 and works fine.

Andy

https://support.checkpoint.com/results/sk/sk103440

Also, not 100% certain if below is also required, though I believe we also did this one:

https://support.checkpoint.com/results/sk/sk131612

0 Kudos
israelsc
Collaborator
Collaborator

Thank you very much @the_rock 

I have set this https://support.checkpoint.com/results/sk/sk103440 and tested on 2 different PCs, both automatically resolve the DNS as I change the A record in the DNS service.
In case for someone who is also testing this and VPN Endpoints not take change automatically, I leave a solution that TAC shared with us in a SR:

In theory, the VPN client should be able to automatically update to the new IP address without the need to delete and recreate the profile. However, there are several factors that can affect this behavior:

  1. DNS Resolution: By default, Remote Access VPN clients resolve the DNS name (FQDN) of the VPN site only once when the VPN site is created. This means that if the DNS entry for the VPN gateway changes, the client will not automatically resolve the new IP address unless it is configured to do so.
  2. Client Configuration: If the client is not configured to resolve the DNS name during each connection, it will continue to use the previously resolved IP address. This is why most clients still connect to the previous firewall after a DNS change.
  3. Roaming and Timeout: The client has a roaming feature that tries to reconnect if the main IP address changes. However, if the timeout period ends and the client fails to reconnect, it may not automatically update to the new IP address.

Solution to Make DNS Resolution Automatic and Transparent

To ensure that the VPN client automatically updates to the new IP address without user intervention, you can configure the client to resolve the DNS name at every connection. Here are the steps to achieve this:

  1. Configure DNS Resolution on Every Connection:
    • Follow the instructions in sk103440 to force the Remote Access VPN Client to resolve the DNS name of the VPN site at every connection.
  2. Client-Side Configuration:
    • Ensure that the client is configured to resolve the DNS name during each connection. This can be done by modifying the client configuration settings.
  3. Update Client Configuration:
    • If users are unable to remove and recreate the site, you can update the client configuration by stopping the Check Point VPN services, deleting the trac.config and trac.config.bak files, and then restarting the services. This will force the client to resolve the DNS name again.

Steps to Update Client Configuration 

Based on https://support.checkpoint.com/results/sk/sk167254

  1. On the Endpoint Connect icon, located on the taskbar at the bottom-right side of your screen, click "Exit" or "Shutdown Client".
  2. Open Windows Services by pressing WinKey + R and typing services.msc.
  3. Stop the Check Point VPN services "Check Point Endpoint Client Watchdog" and "Check Point Endpoint Security VPN".
  4. Go to %programfiles%\CheckPoint\Endpoint Connect and delete trac.config and trac.config.bak (On x64 bit environment: %programfiles(x86)%\CheckPoint\Endpoint).
  5. Restart the Check Point VPN services "Check Point Endpoint Client Watchdog" and "Check Point Endpoint Security VPN".
  6. Relaunch Endpoint Connect.



the_rock
Legend
Legend

Great job! Glad we can help.

Have a nice weekend.

Andy

Wolfgang
Authority
Authority

@israelsc  you want to have a redundant entry via remote access to your network. MultipleEntryPoint MEP is the feature you need. The client knows all entry points and can probe all of them. You can configure to have load balancing or active/backup for the connections from your remote clients.

see Multiple Entry Points for Remote Access VPNs 

the_rock
Legend
Legend

100% valid...I implemented that for a client couple of years back.

Andy

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events