Remote Access VPN in a Load-sharing Cluster Environment

[Di_Junior]

Dear Mates

I hope you are doing fine.

I started working as Check Point admin of a large corporation, and my first challenge is to migrate our Remote Access VPN from one vendor that we are currently using to Check Point Remote Access VPN solution. I have implemented Remote Access VPNs in simple environments with a single gateway and Management server, but I now have to implement it in a much complex environment, thats why I need a hand. The diagram bellow gives an high-level overview of our infrastructure. 

Based on the diagram above, I would like to have your help with regards to the following questions:

1. Do I have to buy remote access VPN (mobile access) for both clusters (Internal and external)? if yes why? if not why?

2. Since the clusters are operating in Load-sharing unicast, do I have to activate Sticky Decision Function in cluster properties? if yes why? if no why? 

3. Should Sticky Decision Function be activated on both clusters (Internal and External)?if yes why? if no why? 

4. Is there any documentation or SK you would recommend for implementation of Remote Access VPN in similar environment? or maybe share your experience if you have worked on similar environment.

[Vladimir]

You need the Mobile Access licenses only for the cluster on which RA VPN connections will be terminated.

If your External cluster is in a full routing mode, then that the one that will need mobile access licenses.

If your External cluster is in the transparent bridge mode, you'll have to use licenses on the Internal cluster.

If your clusters are indeed consist of two simple gateways, there is no benefit from load sharing being enabled, just complications. I.e. you are still limited to the 50% capacity on each cluster member, otherwise, if one of the members will fail, the other will be overloaded.

Load sharing makes sense if: 1. you have 3+ gateways, 2. you are planning to expand the existing cluster in a foreseeable future.

I seldom see the #2, as once cluster deployed, the hardware tend to go towards obsolescence relatively fast and it is hard to justify buying identical units down the road. This may be different with scalable platforms, but I have no experience working with those.

If you are planning to use SSL Network Extender, you'l have to use Sticky Decisions, see Mobile Access R80.10 Administration Guide  and search for "cluster".

Cheers,

Vladimir

[Di_Junior]

Thanks for the great inputs you shared., it will definetely be very helpful

[Danny]

1. You needed to buy Mobile Access licenses only for the cluster that will provide this functionality, ideally this would be your external cluster.

2. Mobile Access in Load Sharing Clusters automatically enables SDF (Sticky mode), which disables SecureXL > Read: ClusterXL Load Sharing mode limitations and important notes and Which features are not supported when the Sticky Decision Function (SDF) is enabled in ClusterXL obj...

3. See 2. It will be automatically enabled on the MOB cluster. You don't need to enable it on the other one.

4. You have a much bigger issue mate. Clusters with less than three or more than four cluster members are not recommended for Load Sharing mode.

[Di_Junior]

Thanks for your contribution Danny Yang 的部落格. it will be very helpful.

can you please share the link you wanted to share in point 4.

Regards

[Di_Junior]

Hi Mates,

I have managed to get the Remote Access VPN working with the licences on the external cluster, but I am facing a little challenge. The remote clients are only able to communicate with the operation & Management interfaces of the Gateways and Management, not the rest of the network. In the Destination side of the access rule I am using "Any" which means I should be able to reach any network behind the gateway (which is not happening): Any hints on how I could overcome this.

Thanks in advance

[Vladimir]

Check what you have defined in your Encryption Domain and your Encryption Domain for Remote Access as well as what is defined in the topology of your gateways.

Additionally, you may be NATting the outbound traffic behind external IP of your internal cluster.

If this is the case, you should stop doing that and route networks to the external cluster unchanged, leaving NAT duties to it.

Check the routing from external cluster to internal network before troubleshooting VPN.

Your Remote Clients are likely getting IPs assigned from the "CP_default_Office_Mode_addresses_pool" network object on the external cluster.

Make sure that it is routed into and out of your internal cluster and networks and is included in the security policy applied to your internal cluster.

Cheers,

Vladimir

[Di_Junior]

Hi Vladmir,

Thanks for your prompt reply and help.

I have changed the office-mode pool address to an address that will not have conflict in our internal network.

I changed the Encryption Domain, and now I get routes to all the operations and Magement IP addresses. Thanks for your help.

I can ping the internal hosts through their O&M interfaces and I get replies successfully. But when I try to RDP an internal server, the connection goes to the Clean-up rule. (see bellow image)

Any thoughts as to how this could be overcomed.

Thanks for your great comments.

[Vladimir]

Well, besides the obvious, "Have you created the rule permitting RDP from this source to this destination", the "Information field in the event you are showing contains:

Inzone: External

Outzone: External

Please check the topology and verify that the Pool's IP is included in the Internal cluster's "External" manually defined group. That there is a route in Gaia configs of both members pointing Pool's network to your External cluster's vIP and your internal networks are define behind Internal interfaces topology in both, external and Internal clusters objects. 

[Di_Junior]

Hi Vladimir

Everything seems to be working just fine so far. but I wish to ask you one question.

Currently, our clients are being assigned Ips from the office pool defined by me (Eg.10.10.0.0). But when they try to access a resource inside our network, their traffic is being NATed into the External Cluster´s internal VIP(Eg, 10.33.7.1). Is there anyway I can stop this NATing, so that office pool address get into our network without being NATed.

Thanks in advance

[Vladimir]

Yep.

Create a two NAT rules on top of your NAT policy with:

Pool,Internal_Nets_Group, Any; Original, Original, Original

Internal_Nets_Group, Pool, Any; Original, Original, Original

Provided you have configured routing and topology properly, i.e.:

1. the Pool Network should be defined on External interface of Internal cluster member

2. the route to the Pool should be included in the routing table of the Internal Cluster Members

3. routes from external cluster members to Internal_Nets_Group should be present on the External Cluster Members

4. access control rules permitting this communication should be defined

5. Policy published and installed

Regards,

Vladimir

[Di_Junior]

"Make sure that it is routed into and out of your internal cluster and networks and is included in the security policy applied to your internal cluster"

Could you elaborate on this.? Thanks

[Vladimir]

Your internal GWs should know that the Pool's range is on its external interface.

Your security policy should permit communication between Pool's range and your internal hosts that you are trying to connect to.

Your External Cluster's Internal interface topology should contain the same networks that are defined behind your Internal Cluster's Internal interface (in addition to intermediate network between internal and external clusters), else they will be treated as spoofed.

While you do have route 0 on your internal cluster members that should route your internal hosts to the Pool's range, I'd personally feel better adding explicit route for the Pool, pointing to the External Cluster's internal vIP.

[Di_Junior]

@Vladimir Yakovlev I would like to thank you for all your inputs during this migration process. Thanks to your contribution I got everthing up and running.

On behalf of my company, I thank you.

[Vladimir]

You are quite w:)lcome!

[Di_Junior]

Thank you. 

I have one more question for you before closing this thread.

I dont want our partners to connect to our VPN and get the message that the certificate is not trusted.

Would you kindly recommend which type of certificate has to be paid in order to overcome this situation? Since we have two different sites, do we have to buy two certificates or one should suffice.

Once again, thank you again

[Vladimir]

Any trusted CA cert would work.

GoDady is now the cheapest and most common source for the certs.

Please follow this post by Gaurav Pandya‌ to issue a CSR for the upload to the CA and the installation of the certificate:

https://community.checkpoint.com/docs/DOC-2732-create-csr-and-importing-third-part-certificate-in-mo... 

[Di_Junior]

Thank you...

[Vladimir]

If it is not too much trouble, please leave a brief feedback on my LinkedIn page:

https://www.linkedin.com/in/vladimiry/ 

We are ramping-up our services and all positive references are appreciated.

Regards,

Vladimir

[Di_Junior]

Not a trouble at all. Please accept my request so that I can recommend.

https://www.linkedin.com/in/dialungana-malungo-50321998/

[Di_Junior]

Hi Vladimir Yakovlev‌

Everything seems to be working now, but the access to the corporate resources is very slow specially when accessing through a browser.

Any hints on how this issue could be overcome? Or some suggestions to improve the response time?

Thanks in advance

[Vladimir]

Without knowing what corporate resources you are talking about and their relation to the Check Point infrastructure, it is hard to figure out what may be wrong.

That being said, provided that there are no IP related issues, when in doubt, look at Name Resolution:

And make sure that the Name Server(s) you are specifying are accessible from and via your gateways.

Run nslookups from the gateways themselves, from local network to the same name servers and from VPN client.

Try changing the split tunnel to send all traffic through the VPN:

And keep in mind that if you are using Windows, it has a "DNS Leakage" issues. I.e. when you attempt to access anything by name, it will blast out DNS requests from ALL interfaces, including local Wi-Fi as well as that of the VPN virtual device.

If your "corporate resources" are resolvable from outside as well as from inside by the same names, confusion might ensue.

There are registry settings that could remedy that. See my article on LinkedIn for the link at the end:

DNS Security missconceptions 

Cheers,

Vladimir

[Di_Junior]

Hi Vladimir Yakovlev‌

Thanks for the prompt response.

I am talking in particular about web applications and other platforms accessed via web.

Regards

[Di_Junior]

Hi again Vladimir Yakovlev‌

The picture bellow shows our setup, the RA Access is being terminated on the internal firewall. There is a public IP on the External Firewaal that is being Statically NATed to the Internal Firewall Network C address (NAT performed by the External Firewall).

The RA clients are getting IPs from the defined Office_Mode Pool. The Office_Mode addresses are then being NATed to an Internal Network valid IP address (This NAT is performed by the Internal Firewall)

The DNS servers that are beeing assigned together with the Office_Mode Pool addresses arein the Internal Network.

"make sure that the Name Server(s) you are specifying are accessible from and via your gateways" . Yes, they are accessible, the Names are resolved but it takes some time to be resolved. However, the response time also takes a bit longer even when accessing directly with the IP address of the machine instead of its "name".

"keep in mind that if you are using Windows, it has a "DNS Leakage" issues. I.e. when you attempt to access anything by name, it will blast out DNS requests from ALL interfaces, including local Wi-Fi as well as that of the VPN virtual device". Yes, most of RA clients are windows based machines, in particular windows 10.

"If your "corporate resources" are resolvable from outside as well as from inside by the same names, confusion might ensue." No, most of the corporate resources (web applications and other platforms) are only part of our Intranet and they are not accessible from the outside unless you are connected to the VPN.

Thanks in advance

D

[Vladimir]

"make sure that the Name Server(s) you are specifying are accessible from and via your gateways" . Yes, they are accessible, the Names are resolved but it takes some time to be resolved. However, the response time also takes a bit longer even when accessing directly with the IP address of the machine instead of its "name".

Please test the access time and the lookup time from your external firewall and post it here.

Additionally, please remind me if your firewalls are single objects of clusters and, if second, if those are HA or VSLS.

[Di_Junior]

We are using a clusterXL in Load-sharing mode.

Could you kindly remind me of any tool or commands that could help me get the lookup time.

[Vladimir]

Below are results of the query from the gateway with domain prefix properly configured looking up its defined DNS server:

[Expert@GW8010:0]# dig dc16

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-25.P1.11.cp991310011 <<>> dc16
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37009
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dc16. IN A

;; Query time: 1 msec
;; SERVER: 10.101.25.10#53(10.101.25.10)
;; WHEN: Tue Nov 6 09:26:27 2018
;; MSG SIZE rcvd: 22

[Expert@GW8010:0]#

and this is its lookup of the internet host:

[Expert@GW8010:0]# dig www.yahoo.com

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-25.P1.11.cp991310011 <<>> www.yahoo.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 84
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.yahoo.com. IN A

;; ANSWER SECTION:
www.yahoo.com. 211 IN CNAME atsv2-fp-shed.wg1.b.yahoo.com.
atsv2-fp-shed.wg1.b.yahoo.com. 54 IN A 87.248.98.7
atsv2-fp-shed.wg1.b.yahoo.com. 54 IN A 87.248.98.8

;; Query time: 88 msec
;; SERVER: 10.101.25.10#53(10.101.25.10)
;; WHEN: Tue Nov 6 09:29:39 2018
;; MSG SIZE rcvd: 97

[Expert@GW8010:0]#

[Di_Junior]

"Please test the access time and the lookup time from your external firewall and post it here."

I found the command to test the lookup time. But which lookup time you would like to see? from the external to which address/domain name?

[Vladimir]

To the internal corporate resources from both clusters. 

[Di_Junior]

I will do that. But before that, there is one thing that I dont quiet understand.

The DNS server used by the RA Clients to resolve names is the one configured on the firewall (via GAIA), or the one configure in the Office_mode "Optional Parameter".