Provya

Sécurité et téléphonie

Articles & Tutoriaux  -  Liens & Actualités

[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN

icon 11/09/2016

Un cas fréquent lorsque l'on souhaite connecter deux sites en VPN est que ces deux sites soient sur le même plan d'adressage. Dans ce cas, une bonne solution peut être de recourir au NAT pour la mise en place d'un VPN natté.

Article mis à jour le  : 13/08/2019

Par exemple, si l'on souhaite connecter deux sites utilisant le sous-réseau 192.168.1.0/24, ceux-ci ne pourront pas communiquer l'un vers l'autre à travers le VPN car le plan d'adressage du réseau distant est le même que celui du réseau local.

Afin d'y remédier, nous proposons d'utiliser le NAT pour communiquer d'un réseau à l'autre. C'est le principe du VPN natté (overlap network).

À noter : nous ne détaillons pas dans cet article comment configurer OpenVPN. Il existe déjà un article dédié sur le sujet : [pfSense] Monter un accès OpenVPN site-à-site.



Principe de fonctionnement

Pour chaque sous-réseau commun sur les sites distants, nous utiliserons un nouveau sous-réseau disponible associé à du 1:1 NAT.

Nous allons prendre l'exemple de deux sites (A et B) disposant tous deux du même plan d'adressage 192.168.1.0/24 :

Schéma réseau overlap openVPN pfSense - Provya


Afin de pouvoir relier ces deux sites en VPN, nous allons translater l'intégralité du plan d'adressage réseau du site B afin qu'il soit joignable depuis le site A à travers le VPN. Et nous ferons de même du plan d'adressage réseau du site A afin qu'il soit joignable depuis le site B à travers le VPN.

Le trafic à destination du site A sera translaté en 192.168.100.0/24.
Le trafic à destination du site B sera lui translaté en 192.1168.200.0/24.

Une entrée 1:1 NAT sera ajoutée pour chaque sous-réseau afin de translater l'intégralité du /24.
Ainsi, pour joindre le site A depuis le site B, on utilisera une adresse IP du type 192.168.100.x et pour joindre le site B depuis le site A, on utilisera une adresse IP du type 192.168.200.x.

Grâce au 1:1 NAT, on conservera le dernier octet de l'adresse réseau de chaque site. C'est-à-dire que pour joindre l'adresse IP 192.168.1.10 du site A, depuis le site B on utilisera l'adresse IP 192.168.100.10. Et pour joindre l'adresse IP 192.168.1.50 du site B, depuis le site A on utilisera l'adresse IP 192.1168.200.50.



Configuration du VPN natté

Sur le serveur pfSense du site A, nous nous rendons dans menu Firewall > NAT, puis sur l'onglet 1:1 :

menu firewall NAT 1 to 1 pfSense - Provya


Nous cliquons sur le bouton "Add". Les champs à configurer sont les suivants :

  • Interface : l'interface de notre tunnel VPN OpenVPN
  • External subnet IP : le sous-réseau utilisé pour le NAT. Soit, pour le site A : 192.168.100.0
  • Internal IP : le sous-réseau local que nous souhaitons translater. Dans notre cas : LAN net
  • Destination : Any

Exemple de résultat obtenu :

Configuration 1 to 1 NAT pfSense - Provya



Nous procédons de la même manière sur le serveur pfSense du site B, en adaptant le champ "External IP" qui passe à 192.168.200.0 dans notre cas.

Exemple de résultat obtenu :

Configuration 1 to 1 NAT pfSense - Provya



Enfin, dans la configuration du client et du serveur OpenVPN, le champ "IPv4 Remote network(s)" doit correspondre aux plages d'adresses IP nattées.

C'est-à-dire que sur le pfSense du site A, le champ "IPv4 Remote network(s)" est renseigné à "192.168.200.0/24". Sur le pfSense du site B, le champ "IPv4 Remote network(s)" est quant à lui renseigné à "192.168.100.0/24".

La configuration est terminée.

Pour davantage d'information sur la configuration OpenVPN sur pfSense, voir l'article dédié sur le sujet : [pfSense] Monter un accès OpenVPN site-à-site.

Le VPN natté est en place !



Pour aller plus loin

[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] La gestion des certificats pour les connexions OpenVPN


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.


Découvrez nos firewall Gbps full-SSD pour pfSense 2.4+

           

store.provya.fr

icon Tags de l'article :

9 commentaires

Henri - 15/04/2015 à 16:30:03

C'est beaucoup plus compliqué que d'installer un serveur VPN avec le protocole PPTP. Mais je compte m'y mettre.

@répondre #lien

Olivier - 28/04/2016 à 10:48:30

Bonjour.

Pourquoi mettre l'interface WAN et pas l'interface OpenVPN dans vos captures d'écran des NAT 1:1 ?

Merci de votre retour.
OD.

@répondre #lien

Guillaume - 28/04/2016 à 11:23:06

Bonjour Olivier,

C'est une erreur sur la capture d'écran. Les règles de NAT s'appliquent bien sur l'interface OpenVPN et non sur l'interface WAN.

Je corrige cette coquille rapidement.

Guillaume

@répondre #lien

Gibs - 15/02/2017 à 14:43:29

Bonjour,
J'ai apprécié vos tutos qui m'ont bien aidé. Par contre, j'ai un petit soucis que je n'arrive pas à résoudre.
Site A se connecte au site B, tout est ok.
Par contre un client nomade se connecte au site A, cela fonctionne, mais impossible de joindre le site B.
Les règles de parefeu ont détecté la demande et on coché en vert, donc communication aller est ok, mais pas de retour on dirait.
Une petite idée? Cela fait 15 jours que je planche là-dessus.
Merci d'avance.
Gibs

@répondre #lien

Guillaume - 17/02/2017 à 12:53:44

@Gibs :
Bonjour,

Ça sent le problème de NAT. Un tour du côté de "Diagnostic" > "Packet Capture" sur le pfSense du siteB vous permettra de voir l'adresse IP source des paquets reçus du client nomade.

Si c'est bien le cas, il vous faudra créer une règle de NAT Outbound.

Si le problème n'est pas là, un packet capture sur le pfSense du siteA vous permettra de vérifier par quelle interface sort le paquet.

Guillaume
--
Provya

@répondre #lien

Gibs - 18/02/2017 à 20:00:53

@Guillaume :
Un tout grand merci.
C'est effectivement une règle de NAT qui était fausse (fausse interface).

@répondre #lien

FloLaco - 04/05/2019 à 12:16:52

Bonjour ,

Merci pour votre article. En revanche, êtes vous sur qu'il ne manque pas une partie de la config ?
En effet, quand le site A envoie au site B, son IP source est toujours en 192.168, or, quand le site B voudra répondre, il va répondre à 192.168, qui est sont propre LAN et ainsi le flux ne partira dans le VPN mais restera dans le LAN.

Merci à vous

@répondre #lien

FloLaco - 04/05/2019 à 12:25:34

@FloLaco :
Je me répond tout seul ... En fait, il faut mettre dans la partie NAT 1:1 l'interface OpenVPN et non pas WAN. En effet le fonctionnement du 1:1 se fait dans les deux sens j'ai l'impression. A savoir, le PfSense local, quand il envoie le trafic dans le tunnel, il change l'IP source du site A puis l'envoie au site B, et le site B se charge de NAT l'IP destination.

Ainsi :
10.0.0.4 to 192.168.151.10 ---PfSense site A---> 192.168.150.4 to 192.168.151.10 ---PfSense site B---> 192.168.150.4 to 10.0.0.10

@répondre #lien

icon Flux RSS des commentaires de cet article