DR VPN without MEP or Secondary Connect

[Ruan_Kotze]

Hi All,

I have a scenario with two non-clustered gateways providing remote access VPN, managed by the same SMS and sharing an encryption domain, in different locations connected to same DC.  The intention is to provide Remote Access to users if the Primary gateway goes down for whatever reason.

Typically I would use MEP to accomplish this, but in this instance it's not feasible (smaller pipe at DR, licensed to only cater for VIP users, certain subset of users must connect to DR always etc.).  We also cannot use Secondary Connect for a couple of reasons and the end user is hard set on the ability to manually select Prod or DR gateway.

Due to end-users being distributed and not all centrally managed I want to avoid touching client config files where possible.

Based on my research the best way to accomplish this would be to:

1. Disable MEP

Set the following command to true in DBedit:
desktop_disable_mep

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

2. Disable Secondary Connect on both Prod and DR Gateways

edit $FWDIR/conf/trac_client_1.ttm and set the :default value of enable_secondary_connect to false.

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

3. Publish changes and push policy.

Would appreciate any feedback as to whether I am missing something simple, or just if anyone else has attempted the same?

Thanks,
Ruan

[Benedikt_Weissl]

I've configured something similar twice, so your plan should work. If you're feeling brave you could also try to create 2 different ttm-files with different mep backup gateways, see here:
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[the_rock]

I strongly believe modifying .ttm file would be best option here, but not 100% positive of the settings needed. Maybe confirm with TAC to be 100% sure.

[Ruan_Kotze]

Thanks for the responses thus far.

I've done some further experimenting in my lab.  I've enable Implicit Primary-Backup MEP and the behaviour was as follows:

• VPN connected to primary gateway and received updated topology
• After topology update there are now two gateways under my site
• I can connect to them individually, however if I drop the connected gateway it does not automatically re-establish a connection to the secondary
• If I manually try to connect to the downed gateway it automatically establishes a VPN connection to the remaining gateway

All good thus far.  Next step was to disable secondary connect in the trac_client_1.ttm file.  Initially had a couple of issues due to bracket spacing (seems the parser is incredibly finicky, despite the vpn check_ttm command saying the file is OK).  The following was observed:

• Upon successful connection to the primary gateway, the DR gateway was removed from my client

This was unexpected, as MEP and Secondary Connect are two seperate things.  I know Secondary Connect leverages MEP, but there is no dependency on Secondary Connect from MEP's side.  I don't know if this is expected behaviour?

Next step was to disable MEP by setting desktop_disable_mep to true via GUIDBEdit (strange that SK suggests GUIDBEdit when this also lives in the GUI?).  Observations:

• This made zero difference from a client perspective.  I expected it to change my client topology to just include the primary gateway, but it didn't
• When creating a new site, my client created both primary and secondary gateways
• Setting Secondary Connect to true or false (with MEP disabled as per above) made no difference in my outcome

So to summarise - to achieve most of my goal, based on my testing I only have to edit $FWDIR/conf/trac_client_1.ttm and set the :default value of enable_secondary_connect to false.

Unfortunately I will not be able to have the primary and secondary sites to be automatically created based on topology, as the only way this happens is with Secondary Connect enabled.  Again, not sure if this is expected behaviour as it seems to me this should be done when MEP is enabled?

P.S. Testing was done on R81 Take 25

[WorkingDread]

Hello

i had a similar lab (using R80.40),

For VPN reasons you have to include both Gateway in RemoteAccess community, i found that i couldnt connect to the GWs (web and ssh) from vpn clients, just until i removed one of the GWs from the community i could connect again.

i dont know if this is expected behaviour too

😕

[Ruan_Kotze]

Yes both gateways definitely needs to be in the RemoteAccess community.  I've destroyed my lab, but don't recall having any issues. If I had to guess I'd say that perhaps your gateways were included in your encryption domain?