- Products
- Learn
- Local User Groups
- Partners
- More
Policy Insights and Policy Auditor in Action
19 November @ 5pm CET / 11am ET
Access Control and Threat Prevention Best Practices
Watch HereOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
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 |
|---|---|
| 4 | |
| 3 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
Wed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY