- Products
- Learn
- Local User Groups
- Partners
- More
Secure Your AI Transformation
9 April @ 12pm SGT / 3pm CET / 2PM EDT
Check Point WAF TechTalk:
Introduction and New Features
AI Security Masters E6: When AI Goes Wrong -
Hallucinations, Jailbreaks, and the Curious Behavior of AI Agents
Ink Dragon: A Major Nation-State Campaign
Watch HereAI Security Masters E5:
Powering Prevention: The AI Driving Check Point’s ThreatCloud
CheckMates Go:
CheckMates Fest
Hey guys,
I hope someone can shed some light here. So, I set up RA mep in my lab (with 2 single gateways) and connection works fine, BUT, when I reboot what is considered "primary" firewall, access via vpn client is lost, it never gets reconnected to the other firewall thats part of ra community.
I followed below document and set automatic_mep to false, enable_gw_resaolving to true and also mep_mode to primary_backup and then indicated primary/backup IP addresses as per manual method.
I did not have much time to troubleshoot this, but will do tomorrow. Just wondering if there is some guidbedit parameter I might be missing here? So say, my primary gw is 172.16.10.78 and secondary is 172.16.10.161. Now, VPN domains are exactly same on both firewalls. If I reboot 172.16.10.78 fw when vpn client is connected, I will see message "reconnecting" about 20 seconds later and it will never reconnect to 2nd fw.
Tx as always!
The Office Mode IP will be different for the primary and backup gateways by design.
That, I believe, requires you to reinitialize the connection on the client side.
Hey phoneboy...I have exact same office mode net for both gateways, but no difference. I dont see anywhere in the documentation where this is even mentioned...I thought that whole purpose of that setting for primary/backup in mep mode in trac file was for failover to be seamless?
My understanding is that each cluster needs to have a different Office Mode range.
Did you try this SK, though? https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
MEP requires that the VPN tunnel will disconnect and connect again in order to probe the available MEP members and to connect to one of them.
I think if you get into reconnecting, you most likely already lost the tunnel, so why not probe other gateways listed in MEP. It seems straight forward, but I am pretty sure there are complications in the algorithm which probably prevents from doing so.
Also alwaysON is quite annoying to end users, especially when you have MFA.
Hi there,
this is exactly my observation too:
https://community.checkpoint.com/t5/Remote-Access-VPN/MEP-failover-speed/m-p/100697#M4120
Unfortunately, nothing happened including the help from TAC. Many attempts to play with various parameters etc, in the end to be told "this is how it works".
From my experience, windows client behaves the better than Mac OS, which did not even tried to reconnect if I correctly remember.
I wonder then if documentation is totally wrong, because we followed it exactly how it shows and no luck no matter what we do. What did TAC say in your case?
I also think you should use separate network ranges for office mode (that's what we do), otherwise you might have troubles routing the traffic.
As for TAC, its been more than a year since I worked on this issue, but if I correctly remember, they basically told me I need different solution if I want to have such resilience level 🙂 Anyway, I was disappointed enough to push this further. If you would be luckier, please share the outcome,
But the customer does not want to do that, they want to use SAME enc domain for both gateways. The only catch is, not sure if that can work for manual mep, or if it has to be implicit, thats the tricky part...
Sorry, I should have been more clear. We are talking about two separate things. When configuring MEP you must have same encryption domain (or proper subset), however for office mode IP range (IPs distributed to clients), those should be separate to avoid routing issues.
I sort of figured thats what you meant : ). Yes, those are 100% different.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 7 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
Tue 07 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Check Point WAF and IO River: Multi-CDN Security in ActionWed 08 Apr 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: The Cloud Firewall with near 100% Zero Day prevention - In 7 LanguagesWed 08 Apr 2026 @ 07:00 PM (CST)
ERM al Descubierto: Amenazas Ocultas que Pondrán a Prueba tu Empresa en 2026Tue 07 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Check Point WAF and IO River: Multi-CDN Security in ActionWed 08 Apr 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: The Cloud Firewall with near 100% Zero Day prevention - In 7 LanguagesWed 08 Apr 2026 @ 07:00 PM (CST)
ERM al Descubierto: Amenazas Ocultas que Pondrán a Prueba tu Empresa en 2026Tue 14 Apr 2026 @ 03:00 PM (PDT)
Renton, WA: Securing The AI Transformation and Exposure ManagementThu 30 Apr 2026 @ 03:00 PM (PDT)
Hillsboro, OR: Securing The AI Transformation and Exposure ManagementAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY