Disabling MEP

[_Daniel_]

Hi All,

We got 2 gateways (R80.30 Take 191) in the remote access community using the same encryption domain. Each gateway got a different public FQDN -for the sake of it, remote01.customer.com and remote02.customer.com.

The 2 sites are created on the endpoint clients, our aim is to disable MEP, letting the user decide to which site he/she shall connect. Currently, end users chose to connect to remote01.customer.com but they end up on remote02.customer.com.

For this We did disable MEP in Global Properties (the explicit way), and we edited trac_client_1.ttm file -on the gateways- (implicit way) setting:

1- automatic_mep_topology, default (false), it didn't help

2- ips_of_gws_in_mep, default(<ip address of remote01.customer.com>), it didn't help

2- mep_mode, default (dns_based), it didn't help

We went through sk75221 and sk78180 but we didn't succeed in enforcing our requirement.

Not sure how things work under the bonnet, we're trying to avoid modifying the trac.default on the end user laptops.

The interesting point we noticed, if the user deletes the site and re-create it, things will behave as expected, though not sure why, we understand this will delete the topology of the site, but does anyone out there know what exactly happening, can we replicate it without asking for user intervention? We're talking about hundreds of non-technical end users and we prefer if we don't get them involved in it.

Or is this not possible by design, i,e. the minute you add more than a gateway to the remote access community, there isn't a way around MEP.

Cheers

[G_W_Albrecht]

I would suggest to contact TAC - no use dabbling and trying...

[_Val_]

What are the settings for mep_mode and ips_of_gws_in_mep in your TTM file? That would explain why they are ending on one specific GW.

Now, If both RA VPN GWs are managed from the same CMA/SMS, there is not much you can do anyway. Each of the GWs reports all other RA VPN GWs belonging to the same community when the clients connect.

You still can control to some extent how and where clients connect, but the options you have are either probing, round-robin, or DNS based resolution.

If you want to have two separate sites, you need two different security domains, each managing a separate VPN GW.

May I ask, why do you need users to chose manually? What is the purpose behind this requirement?

[_Val_]

Another suggestion. With "client_decide" option in the TTM file, you should have a second drop-down menu on the client side with the list of GWs per site. That should work. One site, but ability to chose a particular GW within that site. 

Still, the purpose question remains, I am curious.

[_Daniel_]

you mean on the mep_mode?

[_Val_]

yes

[Pawel_Szetela]

Hi Val,

We are trying to achieve this "... you should have a second drop-down menu on the client side with the list of GWs per site. That should work. One site, but ability to chose a particular GW within that site. " but with no luck. Some time ago there was no problem with that but it was on older versions. If we try it in lab with fresh gateways it works without any problem. But in production no luck.

Regards

[_Val_]

did you choose "client decide" for mep mode?

[Pawel_Szetela]

Hi _Val_,

In trac_client_1.ttm it is set "client decide". We didn't change it.

Regards,

[_Val_]

If it does not work for you, open a call with TAC

[Pawel_Szetela]

Ok, Thank You.

[_Daniel_]

Thanks Gwendolyn, we're about to raise a new ticket with TAC on the hope to reach a resolution

Hi Val, was hoping R80.40 will introduce the support of more than a single remote community per SMS, but it looks we've to wait for future versions. The settings are as below:

- mep_mode, default (dns_based)

- ips_of_gws_in_mep, default(<ip address of remote01.customer.com>)

The reason behind it is pure business requirement, remote02 is a DR DC with a smaller internet feed and a smaller gateway. So customer wants its workforce to use remote01 and if they can't connect choose remote02.

Even not sure ticking "Enable Backup Gateway" would help in our situation, as the customer got a plan to add a new gateway in their international office to the remote community so users in that country would use their local gateway, but based on what we're experiencing, this have the risk of local users connecting to it.

Not sure if CP might not be able to provide these requirements, we might need to socialise with the customer that we need to look at a separate remote access solution down the track.

[_Val_]

Why don't you use mep_mode primary_backup? That should cover your case.

Look into sk75221 and "Editing the TTM File" section in the E80.72 and higher Remote Access Clients for Windows Administration Guide

[_Daniel_]

Thanks Val,

We thought of it, but there'is 2% of users that need to always connect to remote02 -again for business requirements.

We were hoping from the TAC case to get where the endpoint client saves the mapping between the FQDN and the ip address so we can delete this info without the need of deleting/creating the site -which as mentioned would solve the issue.

All is good, thank you all for your input.

[_Val_]

Not sure I understand. Do you have an answer to your own question? If yes, please share with others. Thanks

[_Daniel_]

Hi Val,

The solution for our initial requirement -send users to remote01- wasn't found, though now and after lot of hours with TAC, it looks we've we've no choice but to delete/create the site.

[Yaroslav_Basenk]

We have the same issue with MobileAccess EndpointVpn and configured ISP Redundancy(Primary\Backup mode). 

I have tried to apply :

sk78180 (For R77.30 , R80.40)

sk32229 (For R77.30 , R80.40)

sk92383 (for R80.40)

SR in TAC

Still no any results - Endpoint VPN not tried connect to second IP of SG.

SK which say that VPN Link selection is unsupportable for Enfpoint VPN :

sk113617

sk114623

[_Daniel_]

My issue is bit different, I trust you need to use link selection with ISP redundancy

As Dameon mentioned in an old post

"You can use Link Selection for Remote Access Clients without ISP Redundancy.

If you have a need for both features, this is not currently supported as mentioned in the SKs."

[Yaroslav_Basenk]

Without ISP Redundancy, manual MEP does not work either. I tried to configure it in my test environment with R80.40 and Endpoint VPN E83.10. For manual MEP, it doesn’t matter if Reduncancy ISP is enabled or not. When manual MEP is enabled for EndpointVPN, there should be a simple choice between two IP addresses to connect, but this does not happen.

[Yaroslav_Basenk · Accepted solution]

If the problem is relevant, I found a solution for sk78180. One more step is required for the solution to work properly. You have to change mep_mode. I checked it with Primary_Backup mode and EndpoindVPN(E83.10) switched between GWs perfectly. I mean when main IP is unaccessible the client after several seconds reconnect to backup IP.
I tested this on R77.30 and on R80.40. And yes this is works with ISP_Redundancy(Primary\Backup mode) either.

I see you are trying to use the FQDN, but might be acceptable try use IP addresses?

The main changes with trac_client_1.ttm file:

1. Disable automatic_mep

:automatic_mep_topology (

                        :gateway (

                                :map (

                                        :false (false)

                                        :true (true)

                                        :client_decide (false)

                                )

                                :default (false)

2. Set site topology:

:ips_of_gws_in_mep (

                        :gateway (

                                :default (192.168.1.199&#192.168.2.199&#)

                        )

3. Set MEP mode:

                        :gateway (

                                :map (

                                        :dns_based (dns_based)

                                        :first_to_respond (first_to_respond)

                                        :primary_backup (primary_backup)

                                        :load_sharing (load_sharing)

                                        :client_decide (client_decide)

                                )

                                :default (primary_backup)

                        )

                )

[I_Santos]

@Yaroslav_Basenk I've tried your solution and worked fine. I have two SG's at the same Security Manager and Remote Access community. When I was trying to connect to <IP_of_SG1> it connects on the first try, but in the next attempt it shows me the drop-down box with the two SG's to choose. Therefore, on the second attempt the same connection fails.

By disabling the MEP as you have described and recreating the site, the second attempt no more brings the drop-down box and connects successfully. 

I think is valid to mention some changes that I've made on SMS using GuiDBedit. My source was Configuring Link Selection for Remote Access Only section on Remote Access R80.40 Administration Guide.

Thanks for sharing your results with us.

[TheRealDiZ]

Hi ALL

I was trying to understand how to disable MEP and I have found this post.. Looking at the admin guide, disabling MEP for remote access should be that simple right ?

https://sc1.checkpoint.com/documents/R80.10_andhigher/WebAdminGuides/EN/CP_RemoteAccessVPN_AdminGuid... 

I look forward to hearing from you,

Thanks

Luca

[Arskaz]

A bit late answer, but that's what I'm just tryin to do to resolve a problem, where 2 gateways have identical encdomain for clients. Customer wants to manually choose, to which gateway they will connect.

They have similar problem, that if they create new site, it works with that, but next time client automatically connects first to respond one. And that is not what they want.

I just disabled MEP via guidbedit.

We'll see, if this helps.

[TheRealDiZ]

YES MATE!

Here you have it:

You have to modify these two lines in the trac_client_1.ttm file

FROM this:

-----------------------------------------------------------

:ips_of_gws_in_mep (
:gateway (
:default (client_decide)
)
)

:automatic_mep_topology (

:gateway (
:map (
:false (false)
:true (true)
:client_decide (client_decide)
)
:default (true)
)
)
-----------------------------------------------------------

TO this:

-- before modifying the file save a copy of the original one #cp trac_client_1.ttm trac_client1.ttm_ORIGINAL

-- to find the file and correct path especially on VSX use find / -name trac_client_1.ttm

-- to modify the file then use vi trac_client_1.ttm

1. In the ips_of_gws_in_mep instead of (client decide) just put the public IP of the external interface for that specific gateway where the users are going to connect. Here below as example 8.8.8.8 *note use that specific syntax don't forget &#

To disable the mep properly you must do this on each cp gateway that is part of the vpn remote access community.

2. In the automatic_mep_topology instead of (client decide) put (false) AND instead of default (true) put default (false).

3. Install the policy to apply the changes!

4.When you upgrade (both upgrade/clean install) your system this configuration will be erased. So be careful and save the modified file!

-----------------------------------------------------------

:ips_of_gws_in_mep
:gateway (
:default (8.8.8.8&#)
)
)

:automatic_mep_topology (

:gateway (
:map (
:false (false)
:true (true)
:client_decide (false)
)
:default (false)
)
)
-----------------------------------------------------------

Here below you can find also sk relevant to the trac client file.

Remote Access TTM Configuration (checkpoint.com)

I hope at some point Check Point VPN R&D team will review the way we interact with such an important piece of configuration, especially during the pandemic this is a very painful way to configure vpn client setting!

Hope this helps. 😉

[Arskaz]

Hi!

Did you ever resolve this?

Have you tried just to disable MEP via guidbedit?

[I_Santos]

@ArskazI did this procedure by CLI, using VI editor. I did use GuiDBedit too, but as those procedures were done before editing the trac_client_1.ttm file, I'm not have tested if they are really needed. 

But this solution works very well. Do you need some help?

[Arskaz]

Hi!

I just disabled MEP via guidbedit. There was no need to edit ttm files in my case.
This solution works only, if MEP is not needed anywhere with desktops. 

Admin guide tells this quite a clearly. Just search  desktop_disable_mep.