- CheckMates
- :
- Products
- :
- Quantum
- :
- Remote Access VPN
- :
- DNS Redundancy for VPN Remote Access
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Is the information correct?
Do I need to configure anything else?
I hope you can help me.
Greetings!
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- 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.
- 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.
- 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:
- 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.
- 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.
- 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
- On the Endpoint Connect icon, located on the taskbar at the bottom-right side of your screen, click "Exit" or "Shutdown Client".
- Open Windows Services by pressing WinKey + R and typing services.msc.
- Stop the Check Point VPN services "Check Point Endpoint Client Watchdog" and "Check Point Endpoint Security VPN".
- Go to %programfiles%\CheckPoint\Endpoint Connect and delete trac.config and trac.config.bak (On x64 bit environment: %programfiles(x86)%\CheckPoint\Endpoint).
- Restart the Check Point VPN services "Check Point Endpoint Client Watchdog" and "Check Point Endpoint Security VPN".
- Relaunch Endpoint Connect.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Great job! Glad we can help.
Have a nice weekend.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
100% valid...I implemented that for a client couple of years back.
Andy
