[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN
13/08/2019
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 :
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.168.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 :
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 :
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 :
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
[pfSense] Monter un VPN IPsec natté (Overlap network)
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.
Retrouvez nos services et firewall pour pfSense & OPNsense
Tags de l'article : NATopenVPNpfSenseVPN
24 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.
Guillaume - 15/04/2015 à 16:42:44
Bonjour,
pfSense 2.3 ne supportera plus PPTP. De plus, c'est un protocole qui n'est plus considéré comme sûr : https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/
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.
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
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
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
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).
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
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
touth - 05/12/2019 à 14:16:38
j'ai correctement configuré mon vpn (openvpn) cela fonctionne bien. cependant le nat 1:1 j'rrive pas a joindre les equipements des deux extremités qui partagent la même placge d'adresse. J'ai suivi le tuto
Guillaume - 06/12/2019 à 17:57:50
@touth :
Bonjour,
Utilisez-vous bien les adresses de NAT ?
Avez-vous vérifier vos routes (depuis le menu Diagnostics > Routes) ? Vous devriez également jetez un œil aux logs et si besoin vous appuyer sur l'outil Packet Capture afin d'identifier comment sont routés les paquets réseau par pfSense.
Vous pouvez également vous appuyer sur notre article dédié : pfSense - Troubleshooting / Dépannage de ses règles de filtrage.
Cordialement,
Guillaume
--
Provya
Hadil - 08/06/2020 à 21:00:45
Good
Guigui - 04/12/2020 à 14:46:58
@Gibs :
J'ai trouvé mon probleme (La phase 2 n'etait pas monté :(
Maintenant cette partie est OK
Merci
Guigui - 04/12/2020 à 15:00:10
Bonjour,
J'ai 3 PfSence et 2 VPN : M1 -> PfSence1 --vpn1 -- PfSence2 -- vpn2 -- PfSence3 ->M2
Est il possible de mettre en place une NAT sur le pfSence2 pour que la machine M1 puisse attendre le M2 au travers des vpn 1 et 2 ?
Pour l'instant je vois mes paquets arrivé sur PfSence2 mais pas repartire vers PfSence3 et M2.
Guigui
Guillaume - 07/12/2020 à 10:33:59
@Guigui :
Bonjour,
Oui, c'est possible. Pour compléter la réponse apportée dans mon autre commentaire, il suffit d'annoncer correctement les routes dans les champs "Local network(s)" et "Remote network(s)" de vos liens OpenVPN.
Si vous pensez que la configuration est bonne, mais que le routage ne s'applique pas correctement, vous pouvez vous appuyer sur notre article pfSense - Comprendre et analyser ses règles de routage ou encore utiliser l'outil "Packet Capture" (accessible depuis le menu Diagnostic) afin de visualiser via quelle interface repartent les paquets de M1 arrivant sur le pfSense2.
Cordialement,
Guillaume
--
Provya
Mickelebof - 12/12/2020 à 11:13:42
Bonjour,
Tout d'abord merci pour votre (vos) tutos :)
J'ai appliqué les instructions avec soins mais rien y fait, ça ne fonctionne pas :(
Le tunnel OpenVPN est bien monté (Up/Up des 2 cotés)
J'ai ajouté une route statique sur 1 machine de chaque site :
Site A (192.168.1.119) => 192.168.200.0/24 via 192.168.1.12 dev eth0 (la gateway est l'IP WAN de pfsense)
Site B (192.168.1.152 => 192.168.100.0/24 via 192.168.1.71 dev eth0 (la gateway est l'IP WAN de pfsense)
Le ping fonctionne correctement des 2 cotés, je vois également les paquets arriver et repartir correctement (tcpdump)
Par contre je ne peux utiliser aucun port (ssh par exemple).
Sur mes tcpdump, je vois bien les paquets arriver sur la cible et en repartir, mais il semble que n'a ne revient pas jusqu'à la source :(
J'ai tout de suite pensé à un problème de rules FW mais tout est passants, je vois d'ailleurs bien dans les logs que c'est passant (coche verte).
Du coup je sèche, est-ce qu'il y a d'autres règles ne NAT (outbound ?) à mettre en place ?
Etant donné que le FW ne semble pas être bloquant, je pense donc à un problème de NAT mais je ne trouve pas la solution.
Merci pour votre aide.
Cordialement,
Mick
Guillaume - 12/12/2020 à 12:06:30
@Mickelebof :
Bonjour Mick,
Pourquoi avoir configuré une route statique ?
Les règles d'Outbound 1:1 NAT sont-elles bien configurées sur la bonne interface (l'interface logique OpenVPN) ?
Avec l'outil "Packet Capture", si vous voyez repartir les paquets, par quelle interface repartent-ils ? Par la bonne interface (l'interface OpenVPN) ?
D'une façon générale, si le ping passe, le reste doit passer aussi (à condition que les règles de firewall le permettent, bien-sûr). Enfin, vous utilisez pfSense ou OPNsense ?
Cordialement,
Guillaume
--
Provya
Mickelebof - 12/12/2020 à 13:13:47
Bonjour @Guillaume
Merci pour la réponse rapide !
J'utilise pfsense (2.4.5):)
Alors en fait, si depuis le site A (192.168.1.119) je veux joindre 192.168.1.152 du site B, il faut donc que j'atteigne 192.168.200.152 depuis mon site A, correct ?
Donc sur ma machine 192.168.1.119, il me faut une route pour lui dire d'atteindre 192.168.200.0/24 en passant par 192.168.1.12 (IP pfsense) ?
Sinon j'ai un network unreachable.
J'ai essayé de faire un schéma de mon besoin, j’espère qu'il est compréhensible :)
Schéma : https://nextcloud.sboule.fr/s/p9DQQ2cBQPMNcXA/preview
Sans cette route, je ne vois pas comment je peux joindre 192.168.200.0/24 depuis mon réseau A en 192.168.1.0/24.
J'ai bien sur mis la route retour sur la machine du réseau B.
"Les règles d'Outbound NAT sont-elles bien configurées sur la bonne interface (l'interface logique OpenVPN) ?" =>
Alors justement c'est bien là la question, vous ne parlez pas de règle Outbound dans le tuto et je dois avouez que j'ai du mal avec ça, donc il en faut bien ?
J'ai essayé pas mal de règles, sur l'interface logique OpenVPN, mais rien y fait.
Je pense que je ne dois pas faire comme il faut à ce niveau :(
Mick
Guillaume - 12/12/2020 à 14:38:23
@Mickelebof :
Je voulais parler de 1:1 NAT et non pas d'Outbound NAT dans ma réponse précédente.
Si pfSense est la passerelle par défaut de vos équipements alors vous n'avez pas besoin d'ajouter de routes sur vos postes A et B. Mais vu ce que vous décrivez, je comprends que ce n'est visiblement pas le cas.
Si pfSense n'est pas la passerelle par défaut alors à votre place je ferais du SNAT : c'est-à-dire configurer une règle d'Outbound NAT sur le pfSense du site B pour que les paquets en provenance du site A et à destination du LAN du site B prennent l'adresse IP du pfSense du site B.
Idem dans l'autre sens sur le pfSense du site A.
Je ne comprends pas très bien votre schéma où LAN et WAN semblent inversés et surtout où il semble que la gateway du pfSense (le routeur fibre) soit sur le même réseau que votre LAN (192.168.1.0/24). Vous ne pouvez pas avoir le même plan d'adressage côté LAN et côté WAN ; ou alors c'est que vous aimez réellement vous créer des problèmes ;-)
Cordialement,
Guillaume
--
Provya
Mickelebof - 12/12/2020 à 14:57:33
@Guillaume :
Effectivement, en utilisant le pfsense comme gateway par défaut, ça prend tout son sens (je n'y avais pas pensé) :-)
Je me doutais que ça n'allait pas vous plaire cette histoire de LAN et WAN sur mon schéma, je ne savais pas comment les représenter :-P
En fait ce sont juste les noms de mes interfaces sur le pfsense (qui est une VM).
J'ai donc juste une interface avec comme adresse 192.168.1.12 (site A) qui s'appelle "WAN" dans pfsense.
L'interface LAN (logique) est celle qui porte l'IP du tunnel 10.0.8.1 (site A)
Ok donc si j'ai bien compris, votre tuto implique d'utiliser le pfsense comme default gw pour que ça fonctionne et donc dans mon cas ne pas faire du NAT 1:1 mais du Outbound. Je vais donc essayer ça de ce pas, merci :)
Cordialement,
Mick
Guillaume - 12/12/2020 à 17:56:13
@Mickelebof :
Je comprends mieux votre schéma avec votre explication.
Vous ne devez pas remplacer le 1:1 NAT par du Outbound NAT, mais faire les deux : vous conservez la configuration 1:1 NAT et vous ajoutez une règle d'Outbound NAT pour votre interface WAN (à faire sur chaque pfSense).
Cordialement,
Guillaume
--
Provya
Mickelebof - 12/12/2020 à 18:03:18
@Guillaume :
Merci pour votre aide, je viens juste de trouver le problème !
En fait avec le paquet capture, j'avais des erreurs de checksum.
Je les avais mis de côté vu que le ping passait bien.
Je suis revenu sur ma configuration initiale, qui correspond donc à votre tuto et j'ai désactivé la case : Disable hardware checksum offload
Et là, miracle, tout fonctionne parfaitement !
En vous souhaitant un très bon week end :)
Cordialement,
Mick
Guillaume - 14/12/2020 à 08:21:20
@Mickelebof :
Parfait,
Merci d'avoir indiqué la solution mise en œuvre.
Cordialement,
Guillaume
--
Provya
fahd - 02/03/2023 à 19:58:09
Besoin d'aide,
Le site A et le site B n'arrive pas a communiquer. Pourtant le vpn est up des deux cotes. Je remarque que il n'y a pas de trafic au niveau de l'interface logique de l'openvpn.
Flux RSS des commentaires de cet article