- Products
- Learn
- Local User Groups
- Partners
- More
Step Into the Future of
AI-Powered Cyber Security
The State of Ransomware Q1 2026
Key Trends and Their Impact
AI Security Masters E8:
Claude Mythos: New Era in Cyber Security
Blueprint Architecture for Securing
The AI Factory & AI Data Center
Call For Papers
Your Expertise. Our Stage
CheckMates Go:
CheckMates Fest
HI Mr,
My customer has this topology :
Smartconsole 700s running R82
Two Sgw 9100 on clusterXL HA deployment running R81.20.
Well, he has 7 Wan with private IP links behind broadband Routers (those routers configured with pppoe session with ISP)
The first two Wan are used for navigation and publishing some internet services vecises such website and mailing.
I have deactivated mobile access blade due to conflict port 443 on some devices such ISP broadband router which have closed firmware.
I have configured link selection in smart console and also in GuiDBTool, but still facing some issues and instability, when I saw whireshark, PC witch E88 client shows That it is connected to sgw and move on to look for another attempt with private sgw main ip address..
With capsule android, I have no problem except when I change the sgw IP address it doesn't want to get up the tunnel.
Is the any solution to meet the requirements for the customer to share the seven Wans among all vpn users?
The support team informed us that it is not possible to configure Remote Access VPN on a link that is not the default route.
They updated (after we opened the case) SK165777 to reflect this information.
"Note: If you have multiple External interfaces, Remote Access VPN and Office Mode network must be routed to the interface with the Default route."
In any case, I have submitted an RFE requesting this functionality.
If possible, please do the same. The more requests there are, the higher the chance that it will be considered.
Since you responded to a very old thread, I decided to create a new thread for your question.
I also removed your attachment as it's not clear how it relates to the problem you've described and it appears to contain potentially sensitive information.
"PC witch E88 client shows That it is connected to sgw and move on to look for another attempt with private sgw main ip address." how precisely are you doing this?
Also what precise version of client?
"When I change the sgw IP address" what precisely are you doing here?
Not sure you can "load balance" remote access over multiple WANs as it has to terminate on the gateway itself.
Hi,
Well I'm running E88.30 build 986105506.
On the client site, the server name filled is MyIP:18544 - - let say 196.195.194.193:18443
Sgw 9100 in clusterXL HA configuration with R81.20
Smart1 700s with R82
On smartconsole :
The ipsec VPN blade is activated
Visitor mode listening on 18443.
I have configured link Selection for remote access only as mentioned on R82 remote access vpn administration guide, with probing loadsharing
When I activate the VPN client and doing some wireshark capture I see That the client re initiate tunnel to sgw with its main IP address which is internal
Hope it is clear
Sounds like you didn't follow all the steps in: https://support.checkpoint.com/results/sk/sk32229
You may need to delete and re-add the site after applying these changes.
Hi Mr,
as mentionned by silva, the sk32229 doesn't resolve the issue.
let have a brief of what is installed on the customer side :
-Smart1 base 700S
- 2 quantum 9100 in clusterXL HA configuration Mode : LAN port 172.16.4.0/22 and the Main IP address 172.16.7.254. DMZ 10.100.0.254/24 web services, 7 WANs interfaces 10.10.x.254/24 x from 11 to 17, each WAN is behind broadband isp router with static IP public let say 1.1.x.254, with port forwarding configured for 500/4500/18443(Visitor mode)
-
- Mobile access blade is deactivated due to conflict forwarding port 443 used by the SGW and broadband ISP routers which are running with isp proper firmware.
- IPSec blade activated and configured with the first WAN for VPN Site to Site connection
- Identity Awarness blade activated
- Selection for remote access only with this parameters (Configuring Link Selection for Remote Access Only conf Admin Guide ) withDatabase Tool (GuiDBEdit Tool) :
apply_resolving_mechanism_to_SR = False
ip_resolution_mechanism = ongoingProb
interface_resolving_ha_primary_if : 10.10.11.254 / 1.1.11.254 ( i have tried both private and public) even in LAB environnement
use_interface_IP = False
available_VPN_IP_list : ( i have tried both private and public) even in LAB environnement
10.10.11.254 / 1.1.11.254
10.10.12.254 / 1.1.12.254
10.10.13.254 / 1.1.13.254
........................................
........................................
10.10.17.254 / 1.1.17.254
- On the windows machine for remote access CP VPN Client E88.3 and E89.10 (i have tried them both)
when i lunch wireshard and i start the capture :
- client configured with one of the seven WAN IP, let say 10.10.13.254 / 1.1.13.254 for the initial call, all is running good and i get access to resources granted.
- on gaia portal, when i make the related interface down let say WAN3, i loose connectivity on the client side et the VPN client try de reconnect but what i see in wireshark capture, the VPN client try to connect de the main IP address 172.16.7.254 which is private, and the tunnel never come back up.
the customer has 500 remote users and need to load share VPN access to the SGW.
As I understand it, the "Load Sharing" only works on initial connection.
If an existing connection fails (e.g. because the WAN went down), you might have to reconnect.
However, I would confirm this with TAC.
Hi everyone,
We're seeing the same issue and have already identified the root cause: asymmetric routing.
During the Remote Access connection process, the SYN packet comes in through the VPN interface, while the SYN-ACK is routed out via the default internet interface.
We are currently working with support, but haven't been able to resolve it yet.
Applying sk32229 does not address this issue.
If anyone manages to resolve it, please update this case.
Good luck.
When the default route points to the Remote Access VPN interface, the connection works normally.
Hi,
I think this is the expected behavior. Traffic from gateway to the user public IP address will always use routing table to decide outgoing interface. So use default route interface for remote access vpn is mandatory. On this post someone created a script which automatically creates static routes for vpn clients using secondary internet connection, and every nigth the script deletes the routes.
How to configure VPN Remote Access on non-default ... - Check Point CheckMates
Regards
The support team informed us that it is not possible to configure Remote Access VPN on a link that is not the default route.
They updated (after we opened the case) SK165777 to reflect this information.
"Note: If you have multiple External interfaces, Remote Access VPN and Office Mode network must be routed to the interface with the Default route."
In any case, I have submitted an RFE requesting this functionality.
If possible, please do the same. The more requests there are, the higher the chance that it will be considered.
Hi Silva;
i have submitted a RFE.
however, in order to migrate my costumer to checkpoint, i have use sk103440: How to force Remote Access VPN Client to resolve DNS name of Remote Access VPN Gateway for...
and also andrew post in the link https://community.checkpoint.com/t5/SASE-and-Remote-Access/Remote-Access-VPN-How-to-reduce-reconnect... reducing failover timing.
it was helpul for my case.
Now i am looking for caching MFA credentiels which is not working actually even configured in global configuration smartconsole.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 3 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
Tue 19 May 2026 @ 06:00 PM (IDT)
AI Security Masters E8 - Claude Mythos: New Era in Cyber SecurityWed 20 May 2026 @ 11:00 AM (CEST)
The New DDoS Reality: Autonomy, Scale, and the Future of DefenceTue 19 May 2026 @ 06:00 PM (IDT)
AI Security Masters E8 - Claude Mythos: New Era in Cyber SecurityWed 20 May 2026 @ 11:00 AM (CEST)
The New DDoS Reality: Autonomy, Scale, and the Future of DefenceFri 29 May 2026 @ 09:00 AM (EDT)
Caracas: Executive Breakfast: Innovación en Ciberseguridad – IA y Threat IntelligenceAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY