Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
perfect4situa
Contributor

Remote Access VPN issues (performance, DNS, internal connections) on Spark 2570 Cluster – R82.00.10

Hi everyone,
I’m working on a Check Point Spark 2570 cluster, locally managed, running Gaia Embedded R82.00.10 Build 2110, and I’m experiencing several issues with the Remote Access VPN configuration.

Environment setup

  • Spark 2570 cluster, locally managed
  • Gaia Embedded R82.00.10 Build 2110
  • Single Internet connection in cluster mode
  • Internal networks in standard configuration
  • No internal DNS servers available but gateway configured as DNS (tested and working internally)
  • Remote Access VPN configured in Full Tunnel mode

Current VPN status

The Remote Access VPN is working, but I’m facing multiple issues that I haven’t been able to resolve yet.


Problems observed

1. Very slow VPN performance

The VPN connects successfully, but throughput is extremely low (only a few Mbps), despite both the remote connection and the cluster’s Internet connection being much faster.

No bandwidth shaping or QoS is configured.
I’m trying to understand if this is a configuration issue or a limitation/bug of R82.00.10 on Spark appliances.


2. DNS resolution fails unless I manually set a public DNS

If I leave the default setting and use the gateway itself as DNS, name resolution does not work at all.

Since I don’t have internal DNS servers, my goal would be to use the firewall as DNS forwarder, but this seems to fail for Remote Access clients.

The only way to make DNS work is to manually push a public DNS server to VPN clients, which is not ideal.


3. VPN from inside the LAN does not work (disconnects immediately)

If I try to connect to the VPN from the internal network, the client connects, but after a few seconds it disconnects.

It looks like a routing loop caused by full‑tunnel mode (internal traffic being pushed into the VPN, then routed back inside, etc.).

I’m trying to understand if this behavior is expected in locally managed Spark clusters or if there is a workaround or specific configuration required.


Questions for the community

  • Has anyone experienced very slow throughput on Remote Access VPN in R82.00.10 locally managed clusters?
  • Is there a known method to make DNS forwarding work through the gateway for RA VPN clients?
  • Is it normal that full‑tunnel VPN does not work from inside the LAN, or is there a specific setting to avoid internal routing loops?
  • Any best practices or recommended settings for RA VPN on locally managed Spark appliances?

Any help, suggestions, or shared experiences are highly appreciated.

Thanks in advance!

0 Kudos
18 Replies
PhoneBoy
Admin
Admin

Please provide the precise methods used to test throughput.

Considering this is mentioned in the documentation, DNS should work over Remote Access.
Try this command via the CLI and see if the situation changes: 
set vpn remote-access advanced-settings enc-dns-traffic true
Otherwise, I suggest a TAC case.

0 Kudos
perfect4situa
Contributor

Hi PhoneBoy, I've checked the enc-dns-traffic and it's already set as true.

As testing method to verify bandwidth i used from my pc both a simple speed test online tool and iperf test via cli with the same results as up and down you can find it attached.

 

uploaduploaddownloaddownload

I'm also working with TAC to make this work but seems difficult to solve... So I was hoping for someone in community with the same issues.

Let me know if you have further considerations, BTW on tuesday i should be able to upgrade the gateway.

0 Kudos
Tom_Hinoue
Advisor
Advisor

I would start by upgrading the firmware to R82.00.10 Build 998002133 which was just released just recently.
There are many fixes that might resolve your issues and I believe TAC will inform you to do so as the first step.

perfect4situa
Contributor

On tuesday I'll try to upgrade to the latest version that also support suggest today and let you know.

Thank you

perfect4situa
Contributor

Hi Tom,

after the upgrade I ran additional tests, but the behavior is unchanged.

DNS:

  • Tested both automatic DNS and manual DNS pointing to the firewall cluster IP → DNS from VPN clients still not working.
  • Verified via clish that Encrypt DNS requests is enabled.
  • Added an explicit rule allowing VPN users to access This Gateway on DNS — no change.

MSS / performance:

  • Initial MSS tests may have been affected by an IPS MSS limitation.
  • After adjusting the parameter, MSS reached ~1350 bytes, which seems acceptable.
  • However, VPN throughput is still low and comparable to previous results.
  • Also tested AES‑128 instead of AES‑256, with no noticeable performance improvement.
0 Kudos
PhoneBoy
Admin
Admin

Try deleting/re-adding the site just to make sure the config is propagating to the client.
If no change, suggest a TAC case.

0 Kudos
josi
Participant
Participant

Did you configure DNS domain manually or keep it "Same as DNS domain name" in Advanced Remote Access Options?

If kept same, Spark GWs used to add .local or .info.local suffix into domain names for Remote Access users.

0 Kudos
perfect4situa
Contributor

Hi Josi,

Initially — and also in another environment — I kept everything set to Automatic, using the gateway as DNS and the gateway domain as well.

In this case, the issue occurs when “Office Mode first DNS for clients” is left on Automatic (This gateway). With this setting, name resolution does not work as expected. I tested it again and, this time, web navigation worked, but nslookup did not, which makes me think that the VPN DNS is not being used.

I performed these tests after:

  • Disabling and re‑enabling the Remote Access VPN blade
  • Deleting and recreating the site

Let me know if you need more details or additional test results.

0 Kudos
Tom_Hinoue
Advisor
Advisor

@perfect4situa 
I'll check if I can reproduce the issue in my env with a locally managed cluster.
Btw, I know there is an issue with tunneled connections like PPPoE where accessing Spark WEBUI is slow after RA-VPN connection, but it's my first time to hear about the low throughput.

Is your cluster internet connection Static IP or PPPoE/DHCP?
The interface is clustered(VIP) right?

Regarding MSS, my understanding is that mss clamping is enabled by default for VPN in Spark, so I think we don't need any manual adjustments...

0 Kudos
perfect4situa
Contributor

Hi Tom,

thanks for your feedback and for planning to run the test — much appreciated.

Regarding my setup: the cluster WAN interface is configured with one static IP connection using the clustered VIP. I did not configure a single routable IP shared by both members; each gateway has its own public IP address configured.

On the gateway side, the WAN connection is not PPPoE.
On the client side, I’ve tested Remote Access VPN connections from multiple access types, including:

  • PPPoE connections
  • LTE connections
  • Static public IP connections

The behavior is the same in all cases, so it doesn’t appear to be related to the client-side connection type.

Thanks again for looking into this.

0 Kudos
Timothy_Hall
MVP Gold
MVP Gold

Is this 

Because Quantum Spark models do not support AES-NI, AES-128 is the highest encryption level that should be used; AES-256 will be much slower.  Be especially sure you are not using 3DES, which is 2-3 times slower than AES: sk98950: Slow traffic speed (high latency) when transferring files over VPN tunnel with 3DES encrypt...

For speed testing, using a single testing thread will not show complete results, see here: sk167313: Speed tests do not show expected throughput on SMB appliances

New Book: "Max Power 2026" Coming Soon
Check Point Firewall Performance Optimization
0 Kudos
perfect4situa
Contributor

Hi Timohy, thank you for the sk.

As suggested I tested RA with AES-128 (default AES-256) but there was no improvement.

Interesting also the possible cause you reported for the low speed result. I don't know if it's enough but some online speedtest report to use multi connection mode to test the internet speed.

2026-04-03_14h50_10.png

As additional information i can say the MSS in VPN path to the internet is very low (between 1000-1100) so i think there is also too much overhead.

I tested it with ping and i previously verified source and destination connection has standard 1500 mtu with standard 1472 mss:

mtumtu

0 Kudos
Chris_Atkinson
MVP Platinum CHKP MVP Platinum CHKP
MVP Platinum CHKP

Note there is a max ping option that you will need to configure in order to do this test properly.

CCSM R77/R80/ELITE
perfect4situa
Contributor

Hi Chris, please let me know what do you mean to test it as well.

0 Kudos
Chris_Atkinson
MVP Platinum CHKP MVP Platinum CHKP
MVP Platinum CHKP

In Device > Advanced > Advanced Settings there is an IPS option for 'Max Ping Limit' you would need to increase it to 1500 to check your mss/MTU using ping.

CCSM R77/R80/ELITE
perfect4situa
Contributor

Thank you for this, i've changed this parameter to 9000 just to be sure and then the ping test actualy increase his mss but only to 1322.

Is possible VPN RA limit MTU to 1350?

Any suggestion to increase troughput?

0 Kudos
Chris_Atkinson
MVP Platinum CHKP MVP Platinum CHKP
MVP Platinum CHKP

Did you identify where the MTU restriction occurs, you may require measures such as MSS clamping.

Which VPN client type / Endpoint version?

 

Refer: https://support.checkpoint.com/results/sk/sk121114 (MSS clamping settings are described here)

 

CCSM R77/R80/ELITE
0 Kudos
perfect4situa
Contributor

I’m using Check Point Endpoint Security VPN E88.70 (build 986105912).
I captured traffic on the client PC and observed the following MSS values:

Outgoing MSS from PC: 1310
Incoming MSS from the destination site: 1379

I’m not sure where or how to verify the MSS on the firewall for Remote Access VPN users.
I tried capturing traffic on the gateway, but with the following command I don’t see any VPN traffic:

tcpdump -i any -s 0 -nn -vv -w /logs/cattura.pcap


Any hints on how to capture RA VPN traffic or check/enforce MSS on the firewall would be appreciated.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events