Slowness when Accessing HTTP traffic over Remote Access VPN

[Di_Junior]

Dear Mates

I need a help.

We have started using Check Point Remote Access Solution in our company. So far everything seems to be working just fine apart from long delays we experience when accessing services running over http protocol (it takes really long to access a page). The situation is different when accessing services running over other protocols such as  https, RDP, SSH, which works really faster than http.

I would like to know if there is any configuration changes that needs to be made so that http traffic cannot have higher latency? Or if there is any reason why this is happening.

Another question is related to Capsule VPN (Android and IOS). When I connect a mobile device to the Capsule VPN, I can access all my corporate resources (http traffic is still very slow). However I cannot use the internet on my phone while connected. Internet services only work when a disconnect the Capsule VPN.

Is this a normal behavior of Capsule VPN, or is it something that could be resolved with some configuration changes? if the later is true, how can I solve this issue?

We are using GAIA R77.30.

Thanks in advance

[Vladimir]

For latency issues, please check if the CPU load and traffic latency after activating Anti-Bot and/or Anti-Virus blade on Security Gateway  sk describes your situation.

As to Capsule's access to the rest of the Internet: Check your Mobile Access configuration to see if you have Split Tunneling disabled. If so, either enable it, in which case your remote users will only be accessing the corporate resources via VPN and the rest via local access or, create a rule explicitly permitting your mobile access users access to the Internet.

[Di_Junior]

Hi Vladimir Yakovlev 

Thanks for your feedback.

With regards to the Http traffic, I tried to remove HTTP protocol form the  Antivirus profile, but no sucess, the traffic is still slower compared to HTTPS.

With regards to Capsule VPN/Connect, the split tunnel is enabled by default in Global Properties. The issue is that when I connect using Endpoint Security on my Mac/laptop I can access the internet and my corporate servers without any problem.

The issue is only when I connect using Capsule VPN/Connect from my Android or Iphone, the internet connection is lost, but I can access my corporate servers.

The endpoint clients and the Capsule VPN/Connect are receiving Ips from the same Office Pool. Why is that the endponint security clients can go to the internet, but the Capsule VPN/Connect clients cant? 

Assuming that I have to create an explicity rule for the Capsule VPN/Connect to access the internet, I am a bit clueless because they all get IPs from the same Office Pool. Could you kindly give an example of how the rule should look like?

Thanks in advance

Merry Christmas 

[Vladimir]

Please verify that the split tunnel is enabled in both locations:

 

In addition to this, please check the settings in the first screenshot above pertaining to "Enable Firewall Policy" for SecureClient Mobile and try it with these settings:

If you are saying that the split tunnel is already enabled, than you should not see traffic from remote users laptops or phones NOT addressed to corporate resources traversing your firewalls.

If it does, that means the split tunnel is not working.

Regards,

Vladimir

[Di_Junior]

Hi Vladimir

Thank you very much for your continuous help.

After chenging rthe split tunel configuration on the SecureClient Mobile, everything is now working as expected.

I can now access the internet while connected to the VPN with my Mobile Devices.

One again, Thank you.

DM

[Di_Junior]

Hi Vladimir

I have another two issues which  I need your help with.

After making the changes you suggested, both Adnroid and Iphones are now able to access the VPN resources and the Internet at the same time. However, Iphones are not able to access corporate servers by their names (Eg: intranet.mydomain.com), but Android phones are able to access the servers with their names. Any idea on what should be causing this and how it could be resolved?

The second isssue is related to the Capsule on Windows 10 Machine. I downloaded the application from windows store, and I can successfully connect to the VPN. However, once I am connected, a PPP adapter is created but it does not get the DNS servers that I configured in the Office Pool, it only gets the IP address. Hence, I am not able to resolve internal hosts names because the DNS query is being sent to the Wifi adapter DNS. 

Any idea on how I can solve this issue?

Thanks in advance

[Vladimir]

Try:

Some of your corporate resources may be addressable by their NETBIOS names, especially from Windows PCs and laptops, in this case, define the WINS servers in [5].

Additionally, if the VPN client is not aware of the suffix "internal.mydomain.com" it will, in Windows attempt to resolve "mydomain.com" from fastest responding name server.

See the bottom of this post for the explanation: https://community.checkpoint.com/docs/DOC-2873-dns-security 

Any reason you are using Endpoint VPN on MAC but Capsule VPN on Windows?

I'd suggest sticking with Endpoint VPN on both platforms.

Cheers,

Vladimir

[Di_Junior]

Hi Vladimir

Any reason you are using Endpoint VPN on MAC but Capsule VPN on Windows? No, we are not doing that. Sorry if I made you understand that way.

Currently, we have Endpoint Security Working on both (Windows and MAC). But we also want to test other Remote Access solutions available with Check Point. Hence, we are now testing Capsule VPN/Connect for Androids and IOS devices (Iphones, and IPads). Since there is also a battle going on with regards to AutoVPN, I also want to show that we can achieve that by installing Capsule on Windows 10 from the Microsoft Store.

So currently, we are only having issue with Iphones, IPads, and Capsule on windows 10 laptop.

When I enable the split tunel as you suggested above, Iphones and Ipads are not able to resolve the names of our internal servers, but Android phones can access our internal servers by their names. If I disable the split tunel, iphones, ipads, and  androids can access our internal servers by their names, but they cannot access the Internet.

So why is it that when split tunel is configure in remote access in global properties, Android phones can access both Internal servers by their names, and the Internet, but Iphones and Ipads are not able to resolve the names of our internal servers, they can access the Internet?

Capsule on Windows 10 laptop is having the same problem. In windows 10 I cannot even see the DNS servers that are configured in Office Pool additional Parameters, and Mobile Access Name Resolution as show in the picture bellow. The windows machine can only access internal servers by their Ip addresses, not by their names.

Basically that is the issue we have right now.

Another additional question is, what is the difference between DNS and WINS Servers, can they be the same machines? or the DNS servers is also the WIN Server?

Thanks in advance

[Vladimir]

>>Another additional question is, what is the difference between DNS and WINS Servers, can they be the same machines? or the DNS servers is also the WIN Server?

This is a question for Microsoft forum really. Typically though, these services running on the same machines that are often a Domain Controllers as well.

At this point, the best option will be for you to open a TAC SR and let them look into your environment for solution.

It is hard for me to remote troubleshoot based on relayed information and without access to the systems.

Regards,

Vladimir

[Di_Junior]

Hi Vladimir

Thanks for your feedback.

I have already requested my Partner to open a TAC SR for me.

Thanks once again.

[Di_Junior]

Hi Vladimir

I guess I found the solution for that.

I have been reading about this issue, and I found something which could be the solution.

There is an option to inspect HTTP on non-standard ports traffic on the following software blades: application control, IPS, Anti-Bot, and Anti-virus.

I have unchecked those option, and the traffic seems to become a bit faster now compared to when that option was checked.

So your suggestion above about Antibot/Antivirus, was correct.

Thanks once again

[Di_Junior]

Hi All,

I finally managed to find the cause of the problem and the solution to it.

Since we are terminating our RA VPN on a firewall with other software blades, there was some inspection that was happening, and in particular with HTTP traffic since it is a clear text traffic.

The root cause of the delay was the inspection that was being done by Threat Prevention Software blades (Antivirus and Antibot).

In order to fix the problem, I have to disable the HTTP inspection on non-standard ports in the Advanced settings in the Threat Prevention. After disabling it, all the HTTP traffic not running on the standard port 80, started running perfectly. But the issue persisted with port 80, the delay was still very high.

After long hours of interactions with TAC, they suggested to create a group Exception. But since I was curious about finding what was the root cause of the HTTP traffic on port 80 being slow, I created a lab and tried to replicate the issue.

After replicating the issue in the lab, I was disabling each and every protection in order to find out which one was causing the issue. And I finally found that two Protections what were causing the issue: Reputation URLs, and URL and URLs with Malware.

I cloned the Recommended Profile, and changed these two Protections to Inactive. Once I pushed the Policy, everything went back to normal, the traffic is now back to an acceptable level.

Disclaimer: changing these protections to inactive may impact your security performance, the best way to do is to create Exception in Threat Prevention. I just wanted to share the root cause of this delay.

Thanks 

[Timothy_Hall]

The Reputation URLs, and URL and URLs with Malware signatures do locally cache results on the gateway for speedy lookup, but will definitely cause some interaction with the Check Point ThreatCloud via the rad (Resource Adviser Daemon).  As mentioned on p. 355 my book ("Special Case: DNS and the rad daemon"), it is critical to ensure that rad has speedy access to the Internet to avoid delays like these.  Specifically, make sure that all DNS servers defined in Gaia on the gateway are reachable and responding quickly.  I've seen an incorrect or slow-responding primary DNS server configured on the gateway cause delays like this if the Resource Classification Mode is set to Hold instead of Background under Manage & Settings...Blades...Threat Prevention...General.

Try enabling these two signatures again but set the Resource Classification Mode to Background instead of Hold.  The delay should be gone.  And check your DNS configuration on the gateway.

--

CheckMates Break Out Sessions Speaker

CPX 2019 Las Vegas & Vienna - Tuesday@13:30

[Vladimir]

Tim,

Can you expand on it a bit?

I thought of he possibility that the DNS response time may be an issue, but in the end decided that it really shouldn't be the case:

Since the protections in play involve URL comparison, this really should be performed locally against hashes downloaded in the course of regular updates. In this case, why would the lookup be performed before the decision is rendered?

Thanks,

Vladimir 

[Timothy_Hall]

Pretty sure checks involving reputation involve a live lookup to the Check Point ThreatCloud and caching of the results in the kernel for 24 hours.  The best description of this is under Reputation Layer in ATRG: Anti-Bot and Anti-Virus  There is not a large database download with this inspection function like there is with Application Control, Anti-virus, & IPS. 

Straight URL filtering uses this cloud-based lookup w/ caching of results as well. 

--

CheckMates Break Out Sessions Speaker

CPX 2019 Las Vegas & Vienna - Tuesday@13:30

[Vladimir]

Di Junior‌, can you confirm that the slowdown of HTTP was caused only on the first access of unique pages?

I am reading ATRG that Tim has pointed me to and it states that the local cache is responsible for 99% of the lookups (see #2 RAD):

Reputation Layer

Analyzes the reputation of URLs, IP addresses and external domains that computers in the organization access. The engine searches for the known or suspicious activity, such as Command and Control (C&C).

The Reputation layer classifies per connection:

• IP address - from handle first packet before security rule base. Only in kernel, not in the cloud.
• DNS - host from DNS request (for both TCP and UDP)
• URL - complete URL from the HTTP request
  

After the discovery of bot infected machines, the Anti-Bot Software Blade blocks outbound communication to C&C sites based on the Rule Base.

This classification has 3 stages:

1. First, every URL is searched in the local database, located in $FWDIR/conf/urlrep.eng file that contains some malware data - commonly used signatures, URLs, and their related reputations.
   Local database is loaded to the kernel, and compiled to one Pattern Matcher (PM) that is executed on the incoming URLs to find a match.
   If the URL is found there, a response to the client is returned.
   If there is no match against local database, continue to next Step.
   
   
2. RAD (Resource ADvisor) cache (for DNS and URL only), that gives answers to 99% of URL reputation requests.
   
   
3. RAD (Resource ADvisor) service in the cloud (for DNS and URL only)

If the URL was not found in the cache, a request is sent out to RAD and a response is returned (asynchrony) back to the client, and the relevant data is kept in the cache.

Anti-Bot Resource Classification mode for DNS is overridden to "background" on the Security Gateway. These settings override the existing default settings in the SmartDashboard.

The Resource Classification settings for Anti-Bot are now configurable from the Security Gateway using the malware_config file.

Using the Security Gateway configuration file provides more granularity and divide classification to DNS, HTTP and SMTP.

There are three values for each option:

• hold - for hold classification
• bg - for background classification
• policy - for classification according to Security policy

While it is possible that you have managed to access unique pages each time, I find it somewhat unlikely.

Regards,

Vladimir

[Di_Junior]

Hi Vladimir,

"can you confirm that the slowdown of HTTP was caused only on the first access of unique pages?"

No, It was not only on the first access. The issue persisted whenever I tried to perform an operation on the page. It was really slow.

Regards

[Di_Junior]

Hi Tim

Thanks for your contribution.

You are completely right. That was the exact issue. After changing the classification mode to Background and push the Policy, everything continued to work without any problem. So that was definitely the root cause of this delay. 

I guess this is the safest way, rather than setting the Protections to Inactive.

Thank you for your support. 

See you in Vienna, I will take my book so you can sign it.