Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
mashls4
Explorer

Remote Access VPN - Overlap Network in VPN Domains

Hello everyone,

I have the following scenario:

  • A cluster (FW Corp) and a GW (FW NOC) on R80.10 managed by the same SMS.
  • Remote access (VPN) is required for FW Corp and FW NOC.
  • Users who log in through FW Corp and FW NOC must have to access the same network. (NETWORK A according to diagram)

Is it possible to have the same network (NETWORK A) in the VPN domains (overlap) for both GWs: FW Corp and FW NOC? considering that they share the same remote access community.

Additionally, FW Corp and GW have other networks declared in their VPN domains not common to each other. Only NETWORK A is the only one in common between GWs.

FW_CENTROSUR.JPG

0 Kudos
5 Replies
JozkoMrkvicka
Mentor
Mentor

NETWORK A should be loadbalanced in this case. The users will use only single IP to access resources and LB will pass the packet to the selected GW based on criteria specified by LB mechanism.

Or you can use different NETWORK B (dummy, only part of 1 GW) and translate it to NETWORK A.

Kind regards,
Jozko Mrkvicka
0 Kudos
mashls4
Explorer

Thank you very much for your reply.

According what you're saying. I understand that it is not possible to use the same network (NETWORK A) in both encryption domains for remote access VPN.  I assume this depends on the 2 domains declared in the same community (Remote Access Community).

An additional fact is that each FW has configured office mode with a different IP pool.

Regards,

 

 

0 Kudos
Wolfgang
Authority
Authority

Hello mashls4,

what you want is possible. The keyword is MEP ( Multiple Entry Point ).

With MEP you have more then one gateway with the same encryption domain. And if you have different IP-pools for remote-access clients connecting to different gateways, this will be fine. You don‘t need to NAT your remote clients, the returning packets can be routed according to the entry gateway.

Had a look at the documentation:

Remote Access VPN R80.10 and Higher Administration Guide 

and search for MEP or multiple entry point. 

Your need is described in the part  „The need for Multiple Entry Point security gateways“

Wolfgang

mashls4
Explorer

Hi Wolfgang,

Thank you for your reply. However, according to the information you tell me, MEP is more to create a redundacy scenario with remote access VPN. It has 3 methods for the GW selection:

1. First to respond: Indicates that "to use the same VPN domain for the Security Gateways". In our case it does not apply because the VPN domain of each GW is different but they have a common network (NETWORK A). I mean (VPN DOMAIN 1= NETWORK A + NETWORK B and VPN DOMAIN 2= NETWORK A + NETWORK C)
2. Primary Backup: does not apply because both GWs have to operate with remote access VPN at the same time.
3. Load Distribution: Indicates that "the load distribution is dynamic and the remote client randomly selects a Security Gateway". In our case it does not apply because we don't want to balance the access of the VPNs. Each GW has to work independently of the other GW.

Additionally, NETWORK A is a network that has as a mask: 255.255.224.0. Which is extremely large. And for this reason we want to restrict access to different segments of this network depending on the GW (FW_Corp or FW_NOC).

 

Regards,

0 Kudos
Wolfgang
Authority
Authority

mashls4,

having the same encryption domain on both gateways does not mean that you have access to all ressources internal.

You can define different remote access rules for you two gateways. Meaning FW_Corp has rules only allowing traffic to "VPN DOMAIN 1= NETWORK A + NETWORK B" and FW_NOC has rules only allowing traffic to "PN DOMAIN 2= NETWORK A + NETWORK C"

The let the client only use one gateway at the time you can configures these in the trac_client_1.ttm file.

With these file you control the behaviour of the VPN client.

Hope that's fit your requirements.

Wolfgang

PS.: Be aware you can have a different VPN domain for RemoteAccess and Site2Site VPN.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events