Problème de mutualisation

Ce problème est valide au moins jusqu'à la version NGX R65.

Actuellement, il est impossible sur un management CheckPoint de définir plus d'une communauté d'accès distant (Remote Access Community) et plus d'un domaine d'encryption par VPN. Ceci a pour conséquence, sur une passerelle VPN mutualisée entre plusieurs clients, que tous les clients partage un même domaine d'encryption.

Fig. 1

Présentation :

• Nous avons avons deux clients A et B disposant chacun d'un adressage interne qui leur est propre.
  
• Ils accèdent à notre VPN au travers un accès WAN qui translate leurs adresses. On peut par exemple imaginer que nous les voyons arriver avec une adresse sur le réseau 192.168.3.0.
• Le client A accède au serveur X via le tunnel VPN
• Le client B accède au serveur Y via le tunnel VPN

Il nous faut donc mettre dans le domaine VPN de notre passerelle à la fois X et Y.

Ceci ne posera aucun problème au client A dont le réseau interne n'a rien à voir avec nos réseaux 192.168.1.0 et 192.168.2.0.

Par contre ce n'est pas le cas pour le client B. En effet il pourra sans problème communiquer avec le serveur Y à travers le tunnel VPN, par contre son réseau interne est identique à notre réseau 192.168.1.0. La conséquence est que dès qu'il voudra communiquer avec une machine de son réseau ayant la même adresse que notre serveur X, SecuRemote ou SecureClient interceptera la communication et voudra la faire passer dans le tunnel. Bien sûr nos règles n'autorisant pas B à communiquer avec X, le flux sera refusé sur notre passerelle. Pour pouvoir communiquer avec sa machine 192.168.1.3, B pourra :

1. Indiquer à SecuRemote / SecureClient de ne pas monter le VPN pour cette machine pendant une durée limitée.
2. Quitter SecuRemote / SecureClient.

B ne pourra donc pas travailler simultanément avec sa machine 192.168.1.3 et notre serveur Y, ce qui peut être très gênant pour lui.

La seule solution faisable actuellement est de dédier une VPN pour chaque client rencontrant ce problème. Bien sûr dans le contexte actuel de maitrise des coûts, cette solution n'a rien d'idéal. Elle multiplie en effet le nombre d'équipements et les coûts d'exploitation liés.

Dans le contexte de mutualisation, il faudrait pouvoir limiter pour un groupe de client les IP qui font partie pour lui du domaine VPN.
Dans ce but, on peut imaginer plusieurs solutions, comme par exemple attacher un domaine VPN à un groupe d'utilisateur ou bien à une communauté d'accès distant (Remote Access Community). Dans la seconde hypothèse, il faudrait déjà pouvoir déclarer plusieurs de ces communautés, ce qui n'est pas possible actuellement.

Retour à l'index SecuRemote / SecureClient