Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
_Daniel_
Contributor
Jump to solution

Disabling MEP

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

1 Solution

Accepted Solutions
Yaroslav_Basenk
Participant


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)

                        )

                )

View solution in original post

26 Replies
G_W_Albrecht
Legend Legend
Legend

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

CCSP - CCSE / CCTE / CTPS / CCME / CCSM Elite / SMB Specialist
_Val_
Admin
Admin

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?

 

 

 

 

0 Kudos
_Val_
Admin
Admin

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_
Contributor
you mean on the mep_mode?
_Val_
Admin
Admin

yes

Pawel_Szetela
Contributor

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

0 Kudos
_Val_
Admin
Admin

did you choose "client decide" for mep mode?

0 Kudos
Pawel_Szetela
Contributor

Hi _Val_,

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

Regards,

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
Pawel_Szetela
Contributor

Ok, Thank You.

0 Kudos
_Daniel_
Contributor

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_
Admin
Admin

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

0 Kudos
_Daniel_
Contributor

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.

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
_Daniel_
Contributor

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.

0 Kudos
Yaroslav_Basenk
Participant

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

0 Kudos
_Daniel_
Contributor

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
Participant

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.

0 Kudos
Yaroslav_Basenk
Participant


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
Contributor

@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.

 

0 Kudos
TheRealDiZ
Collaborator

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

0 Kudos
Arskaz
Contributor

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
Collaborator

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. 😉

0 Kudos
Arskaz
Contributor

Hi!

Did you ever resolve this?

Have you tried just to disable MEP via guidbedit?

 

I_Santos
Contributor

@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?

0 Kudos
Arskaz
Contributor

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events