topic Re: Remote Access VPN via FQDN in Firewall & Security Management

Remote Access VPN via FQDN

RPawar — Wed, 23 Sep 2026 15:20:28 GMT

Hello All,

We are planning to migrate from Cisco ASA to Check Point 3970 appliance R82.10 below is the scenario.

Cisco has 2 ISP public IP as external interfaces, there is a route based SLA configured which says that default route priority is from ISP2 & and then ISP1.

The current remote vpn users connect via anyconnect app with remote vpn gateway as fqdn "exampl.win.co.in" as checked publicly the fqdn resolves on both the Public IP addresses which are configured on the interfaces for ISP1 & ISP2.

Now we are planning to migrate to check point so what configuration needs to be done with reference to above scenario in check point, The users will use endpoint security vpn client which will be managed from smart endpoint running on the same management server.

Do i have to explicitly configure a CA signed certificate so that my users connect to the remote vpn, or since publicly the fqdn is getting resolved then certificate is not required and we can use the ICA that check point provides?

What settings do i have to do in my link selection page for remote access vpn to make sure that client is able to connect properly?

Any suggestions would be very helpful!!

Thanks.

Re: Remote Access VPN via FQDN

the_rock — Wed, 23 Sep 2026 15:23:34 GMT

The key point is that DNS resolution and the VPN gateway certificate solve two different problems.

For your migration from Cisco ASA to Check Point R82.10, you should plan the Remote Access VPN around the FQDN + certificate + Link Selection relationship.

Recommended design

With your existing setup:

ISP1 → Public IP 1
ISP2 → Public IP 2
exampl.win.co.in → Public IP 1 and Public IP 2
Cisco currently prefers ISP2 for the default route, with ISP1 as backup.
Users connect using the FQDN rather than directly to an IP.

On Check Point, you can preserve essentially the same user experience:

                    Internet
                  /           \
             ISP1               ISP2
          Public IP1         Public IP2
               \                /
                \              /
                 Check Point 3970
                       |
                  Internal LAN
                       |
              Management Server
                       |
                 SmartConsole
                       |
              Endpoint Security VPN

1. Use the FQDN as the VPN gateway name

Keep:

exampl.win.co.in

resolving to both public IP addresses.

However, DNS alone does not eliminate the need for a certificate.

The certificate is used to establish the TLS/SSL identity of the VPN gateway and to allow the client to verify that it is actually connecting to exampl.win.co.in.

For a production deployment, I would use a public CA-signed certificate whose certificate name/SAN contains:

exampl.win.co.in

Do not rely on the ICA certificate simply because the DNS name resolves publicly.

The important distinction is:

DNS tells the client where to connect. The certificate tells the client who it is connecting to.

2. Configure the certificate on the Check Point gateway

In SmartConsole, configure the gateway's VPN certificate appropriately and make sure the certificate contains the FQDN that the Endpoint Security VPN client will use.

For example:

Certificate:
    Subject/SAN: exampl.win.co.in

DNS:
    exampl.win.co.in
          ├── Public IP 1
          └── Public IP 2

The certificate should also have a complete trusted chain available to the clients.

Using a public CA certificate is generally much cleaner for remote users because the Endpoint Security VPN clients already trust the public CA hierarchy.

3. Configure Link Selection carefully

This is the particularly important part of your scenario.

Check Point needs to know which external interface/IP should be used for VPN connections and how the gateway should behave when there are multiple ISP links.

In the Gateway's VPN/Link Selection configuration, configure the external interfaces as the VPN links.

Conceptually you want:

VPN Gateway
│
├── ISP1
│     Public IP1
│
└── ISP2
      Public IP2

The exact Link Selection option depends on how you want Check Point to handle the two links.

If both public IPs are intended to be reachable by remote clients, you should configure both links appropriately rather than treating the secondary ISP merely as an ordinary routing backup.

4. Important distinction: routing failover vs VPN failover

This is where the Check Point design can differ from the ASA behavior you're describing.

Your ASA currently has something like:

Default route
     |
     +---- ISP2 (preferred)
     |
     +---- ISP1 (backup)

That determines outbound routing.

It doesn't necessarily mean that a remote VPN client will automatically move between ISP1 and ISP2 if ISP2 fails.

For example:

Normal:

Client
  |
  | exampl.win.co.in
  v
ISP2 Public IP
  |
Check Point

If ISP2 fails and DNS still contains both addresses, a new client connection can potentially use ISP1.

But an already-established VPN tunnel isn't necessarily going to migrate seamlessly from ISP2 to ISP1. The client generally has to establish a new connection.

This distinction is important when testing the migration.

5. DNS configuration

You can retain:

exampl.win.co.in → Public IP1
exampl.win.co.in → Public IP2

But I'd recommend verifying exactly how your DNS provider handles multiple A records and what TTL you are using.

Also remember that DNS round-robin is not the same thing as Check Point ISP failover.

For example:

DNS
 |
 +---- IP1
 |
 +---- IP2

doesn't necessarily mean:

ISP2 failed → DNS automatically removes IP2

unless you have a DNS health-check/failover mechanism.

If both IPs remain published, clients may initially try either address depending on DNS/client behavior.

6. Endpoint Security VPN configuration

Since you're managing the Endpoint Security VPN client through SmartEndpoint, make sure the VPN site/gateway configuration uses:

exampl.win.co.in

rather than hard-coding either:

Public IP1

Public IP2

That gives you the flexibility to change the underlying ISP addressing without changing the client configuration.

7. Certificate vs ICA — direct answer

For your specific question:

Do I have to explicitly configure a CA-signed certificate, or can I use the ICA certificate because the FQDN resolves publicly?

DNS resolution does not make the ICA certificate sufficient.

For a production remote-access VPN using:

exampl.win.co.in

I'd use a CA-signed certificate with exampl.win.co.in in the SAN.

The fact that the FQDN resolves to the public IP doesn't establish certificate trust.

Think of it this way:

Component	Purpose
DNS	Finds the VPN gateway IP
Public IP	Provides network reachability
Certificate	Authenticates the VPN gateway to the client
ICA	Check Point's internal certificate authority/trust infrastructure
Endpoint Security VPN	VPN client
Link Selection	Determines which gateway link/IP Check Point presents/uses

8. One thing I'd test before migration

Before moving all users, build the Check Point configuration and test the following independently:

exampl.win.co.in resolves to both public IPs.
Each public IP is reachable from an external network.
The certificate presented by the gateway matches exampl.win.co.in.
Endpoint Security VPN can establish a tunnel through ISP1.
Endpoint Security VPN can establish a tunnel through ISP2.
Test authentication through both paths.
Disable ISP2 and verify a new VPN connection through ISP1.
Restore ISP2 and test the reverse.
Test an already-established VPN session during an ISP failure to understand the client behavior.
Verify that NAT, firewall policy, anti-spoofing, and required VPN services are correct on both external interfaces.

Re: Remote Access VPN via FQDN

emmap — Thu, 24 Sep 2026 02:01:50 GMT

Please read through these two SKs, you'll probably need to do both of them.

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

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

Re: Remote Access VPN via FQDN

RPawar — Thu, 24 Sep 2026 08:38:44 GMT

Hello Rock & Emmap,

Thanks for your inputs it is really helpful, However i have few more queries regarding the approach that you have suggested.

As i have checked in the current setup there is no such Public CA signed certificate installed on the cisco ASA setup.

The client installs an internal certificate every 3 months, so can we use the same certificate for the check point setup?

The article that was shared by emmap i have already read it before

Solution ID: sk131612

Example Topology

Remote Access VPN Clients <-----> Load Balancer <----> Security Gateway

The Security Gateway's IP address for Remote Access VPN is NATed to multiple public IP addresses through the Load Balancer. The clients try to connect to the gateway using DNS resolution, The DNS resolution resolves the FQDN to one of the gateway's NATed IP addresses.

In my scenario there is no NAT in place, also there is no such LB in place the fqdn directly resolves on both the Public IP of ISP which are currently statically mapped to cisco ASA interfaces

Re: Remote Access VPN via FQDN

PhoneBoy — Thu, 24 Sep 2026 15:02:00 GMT

The ICA-generated certificate does not allow you to specify specific FQDNs.
Having said that, users can either manually trust the certificate or you can push the relevant certificate fingerprints to the clients: https://support.checkpoint.com/results/sk/sk66263

Re: Remote Access VPN via FQDN

emmap — Fri, 25 Sep 2026 01:19:47 GMT

In your case you can probably ignore the load balancer and NAT part of it, but I don't know how you're going to manage the routing if you're going to try to return the connections out of the same external interface they came in on.