Création d’un réseau interne grâce au NAT sur Proxmox VE 5

Il y a quelques semaines maintenant, j’ai repensé mon cloud personnel. Auparavant basé sur ESXi, j’ai changé de technologie pour revenir sur quelque chose de plus « léger » que je connaissais déjà : Proxmox. Cet hyperviseur basé sur Debian m’avait causé dans sa version 4 pas mal de maux de tête pour réussir à monter un réseau et donner accès à internet à mes VM sans qu’elles n’utilisent d’IP globales ; la version 5 ne fait pas vraiment mieux, c’est pourquoi je vais partager dans cet article les opérations nécessaires via l’interface de Proxmox et via la modification du fichier /etc/network/interfaces.

Sur l’hôte, dans les paramètres réseau, doivent apparaître juste après l’installation la carte physique de la machine et un bridge. Il est très important de ne pas y toucher sous peine de rendre la machine injoignable après le redémarrage ou la recharge de la configuration des cartes. L’interface web ne semblant pas traduire correctement les valeurs saisies en un fichier de configuration propre, on va donc passer par la modification en direct du fichier /etc/network/interfaces pour y créer un deuxième bridge qui sera notre réseau local.

En l’ouvrant avec nano en utilisateur root, il doit ressembler à ceci (je vais appeler dans cet exemple ma carte réseau eth0 et mon IP 26.10.19.91), en gras les paramètres qu’il faut absolument vérifier afin qu’ils soient sur cette valeur :

auto lo
iface lo inet loopback


iface eth0 inet manual


auto vmbr0
iface vmbr0 inet static
  address 26.10.19.91
  netmask 255.255.255.0
  gateway 26.10.19.1
  bridge_ports eth0
  bridge_stp off
  bridge_fd 0 


auto vmbr1
iface vmbr1 inet static
  address 192.168.2.1
  netmask 255.255.255.0
  bridge_ports none
  bridge_stp off
  bridge_fd 0

Le vmbr1 est le nouveau bridge sur lequel nous allons raccorder nos VM pour leur donner accès à internet et pouvoir faire du NAT afin de les joindre depuis l’extérieur sur la même IP que l’hôte et qu’elles puissent éventuellement communiquer entre elles.

Un redémarrage plus tard (relancer les interfaces réseaux n’est pas suffisant), le nouveau pont doit apparaître dans la section réseau de l’interface web :

Par la suite, en configurant le réseau sur les VM, on indiquera une adresse IP comprise entre 192.168.2.2 et 192.168.2.254 (si vous avez laissé le sous-réseau par défaut) et 192.168.2.1 en gateway. Concernant les serveurs DNS, il est possible d’utiliser des serveurs DNS externes ou internes ; parmi les DNS publics, on peut renseigner par exemple 1.1.1.1 qui est le DNS public CloudFlare, ou le réputé 8.8.8.8 de Google.

Maintenant que les machines peuvent avoir une IP définie, afin de les joindre via certaines applications, il ne reste plus qu’à faire le NAT dans iptables. Toujours en root, on autorise le routage des paquets venant sur l’interface vmbr0 (qui est liée à eth0, la carte physique liée à internet) vers notre sous-réseau fraîchement créé :

iptables -t nat -A POSTROUTING -s ‘192.168.2.0/24’ -o vmbr0 -j MASQUERADE

Et enfin, si l’on souhaite ouvrir le port 80 sur 192.168.2.2 :

iptables -t nat -A PREROUTING -i vmbr0 -p tcp –dport 80 -j DNAT –to 192.168.2.2:80

A noter que si l’on souhaite simplement retirer une règle, on remplace -A par -D. iptables ne sauvegardant pas de manière permanente les règles, elles sont perdues au redémarrage. Il est possible d’installer des applications permettant de faire des backup/restore des règles ou bien d’ajouter les règles au fichier /etc/network/interfaces en utilisant post-up pour les règles à exécuter une fois que l’interface est montée, et post-down pour celles a exécuter quand l’interface est désactivée. Par exemple :

post-up iptables -t nat -A PREROUTING -i vmbr0 -p tcp –dport 80 -j DNAT –to 192.168.2.2:80

post-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp –dport 80 -j DNAT –to 192.168.2.2:80

Pour plus d’informations concernant iptables et ses possibilités, je vous renvoie à ce lien.

Montage d’un NAS sur une machine virtuelle Debian distante

J’ai franchi le pas récemment en achetant un NAS pour sauvegarder à la maison mes documents personnels et du contenu multimédia en tout genre. En plus d’utiliser Google Drive avec Plex (voir cet article), j’ai décidé de monter un troisième serveur Plex sous Debian Stretch pour y décoder le multimédia qui provient de mon NAS directement. Afin que le NAS à la maison soit accessible sur mon Plex qui est une machine virtuelle située en dehors de mon réseau local, je vais utiliser Samba – intégré à mon NAS – et faire un peu de routage sur ma Livebox.

Tout d’abord, satisfaire les prérequis en termes de paquets sur la machine :

adduser <sambaplex>
apt-get install cifs-utils

Je me servirai du dossier home de l’utilisateur sambaplex pour y monter mon NAS afin de le séparer du répertoire de l’utilisateur courant. Etant donné que sur le serveur nous n’allons pas héberger un partage mais seulement en monter un, il n’y a pas besoin d’installer tous les paquets de samba.

Ensuite, il faut paramétrer la box qui fait office de routeur à la maison. Dans mon cas, ayant une IP dynamique, j’ai dû faire appel à un service externe nommé No-IP qui permet de souscrire gratuitement (avec une offre payante) à un nom de domaine que je prolongerai tous les mois ; ce service est géré par ma box grâce à l’API, ce qui signifie que dès que mon IP change, l’adresse que renvoie mon nom de domaine change aussi. Cela évite d’avoir à remonter le partage sur le serveur dès que l’IP change et de pouvoir communiquer avec un nom, ce qui est plus pratique.

Je configure ici mon service de DNS dynamique ; sur la Livebox plusieurs prestataires sont disponibles

Ensuite, il est nécessaire de procéder à l’ouverture des ports dans le pare-feu, et également de NATer ceux-ci afin que le trafic puisse rentrer et sortir proprement. 5 ports sont nécessaires pour que toutes les fonctionnalités soient accessibles :

Je route les ports 135, 137 et 445 en TCP/UDP, 138 en UDP et 139 en TCP vers le NAS

Par précaution, j’ai également procédé à la création d’un bail DHCP permanent pour le NAS afin qu’il ne change pas d’adresse IP locale en cas de redémarrage ou de perte de connexion. Une fois que tout est prêt côté « maison », il ne reste plus qu’à monter le partage samba du NAS sur le serveur distant grâce à cette commande exécutée en root :

mount -t cifs //<nas.domain>/<share> /home/sambaplex -o username=<nasuser>

Il sera alors demandé le mot de passe du compte nasuser qui devra avoir les droits en lecture sur le share que l’on souhaite monter.

Si l’on souhaite démonter le share, rien de plus simple :

umount /home/sambaplex

Désormais je peux ajouter mon contenu sur ce serveur Plex comme si il était localement sur la machine virtuelle, chaque appel aux fichiers passant par Samba – et nécessitant de ce fait, une bonne bande passante étant donné que tout transite du NAS à la maison vers la machine virtuelle.

Accéder à un serveur FTP situé derrière un routeur

Un ami qui partait en vacances et qui souhaitait sauvegarder les vidéos de son drone afin de pouvoir libérer la mémoire interne avait besoin d’un espace en ligne pour déposer les fichiers car sa tablette Android n’avait pas une capacité suffisante. J’ai donc ouvert sur le web mon serveur FTP personnel situé sur mon Cloud personnel. Je vais donc détailler les quelques pas nécessaires à la bonne configuration du serveur FTP afin qu’on puisse y accéder depuis le web même si il est situé derrière un routeur.

J’ai réalisé cette opération en me servant d’un routeur virtuel pfSense car mon serveur FTP est hébergé sur un serveur vSphere ESXi, ainsi que de FileZilla Server pour Windows, sur un 2012 R2. Pour des raisons de simplicité, j’ai utilisé le port 21 afin d’éviter des incompatibilités avec les clients FTP disponibles sur Android.

Etant donné qu’il est placé derrière un routeur, le serveur ne doit pas agir en mode actif, mais en mode passif. Le mode passif nécessite d’être configuré dans FileZilla, car afin de fonctionner correctement, il faut lui spécifier l’IP externe de la machine physique, c’est à dire, par exemple, 87.32.38.143, et non l’IP du serveur FTP sur le réseau local, qui pourrait être 192.168.1.2. Ensuite, un range de ports pour que le mode passif fonctionne, et le tour est joué.

A titre d’exemple, j’ai utilisé le range de ports 30000-30100 car il n’était utilisé par aucune autre application sur l’hyperviseur.

Il faut maintenant ouvrir et router correctement les ports, ce qui n’a rien de difficile. Sur pfSense, il m’a suffit de rediriger vers le serveur FTP les requêtes TCP sur le port 21 sur le range 30000 à 30100. Le test montre bien que tout communique sans problème :

Création d’un routeur et pare-feu pour un serveur ESXi avec l’appliance pfSense

Lorsque je suis passé de Proxmox VE qui est un hyperviseur basé sur Debian à vSphere ESXi, il m’a fallu trouver une nouvelle solution pour faire du routage d’adresses vers mes machines virtuelles car je ne veux pas utiliser une adresse IP par machine virtuelle. Si Proxmox VE permet cela nativement car basé sur Debian il possède iptables, ESXi n’a rien par défaut. Cependant, grâce à pfSense, il est possible d’ajouter cette fonctionnalité, pour peu que l’on soit en mesure d’avoir une deuxième IP différente de celle de l’ESXi à affecter (chez les prestataires louant des serveurs, une telle IP est généralement appelée une IP failover).

pfSense est une appliance faisant office – entre autres – de pare-feu, de routeur, de serveur DHCP, de serveur DNS, etc. basée sur BSD. Il existe une version gratuite que l’on peut récupérer sur le site web officiel. Dans cet article, je vais donc expliquer comment utiliser pfSense pour faire du NAT sur un serveur ESXi.

J’ai réalisé ces manipulations sur un serveur vSphere ESXi de test en version 6.0u2 – avec une licence gratuite. Je pars du principe que vous avez un minimum de connaissances de l’interface web ou du vClient, par conséquent je ne vais pas systématiquement réaliser des captures d’écran ou détailler le chemin à effectuer pour trouver où effectuer les réglages. Les captures d’écran peuvent être agrandies en cliquant dessus pour une meilleure visibilité.

1. Préparation côté vSphere

Le rôle de l’appliance va être de capter le trafic venant de l’internet pour le bloquer ou le rediriger vers les machines virtuelles hébergées. On va donc avoir deux vSwitch : un qui va servir pour le LAN, dans lequel nous placerons toutes les machines virtuelles ainsi que l’appliance pfSense, et un autre vSwitch qui servira pour le WAN, sur lequel seule l’appliance sera connectée.

Etant donné qu’il est évidemment nécessaire que le vSwitch WAN soit celui qui soit relié physiquement à la carte réseau du serveur, celui qui est créé par défaut par vSphere sera le vSwitch WAN. Il faut donc créer un nouveau vSwitch qui sera celui pour le LAN.

On valide en laissant les options par défaut, et on arrive normalement à quelque chose comme ceci – j’ai renommé l’étiquette du WAN afin qu’elle soit plus lisible.

Il faut maintenant récupérer l’ISO de pfSense, téléchargeable sur le site officiel. Une fois le fichier récupéré, on l’envoie sur le datastore puis on crée la machine virtuelle. pfSense occupe très très peu de ressources : 1 vCPU, 512 Mo de RAM et un disque virtuel de 8 Go suffisent. Lors de la création, le type d’OS à sélectionner sera « Free BSD ».

Ne pas oublier d’ajouter une deuxième carte réseau à l’appliance. Sous BSD, em0 sera le WAN et em1 le LAN.

Ensuite, il est nécessaire de modifier les paramètres de la machine virtuelle avant de la démarrer et d’installer le système. En effet, sur la carte WAN, nous allons déclarer l’adresse MAC de l’adresse IP que nous allons affecter à pfSense. Dans le cadre d’un serveur loué chez OVH par exemple, nous allons prendre une IP failover et utiliser l’adresse MAC de celle-ci. La carte LAN gardera une adresse MAC automatique gérée par vSphere.

L’adresse MAC de notre carte WAN sera celle de l’IP failover ou du matériel possédant cette IP.

Ensuite, il suffit de monter l’ISO depuis le datastore et de connecter le lecteur optique virtuel pour pouvoir démarrer la machine et laisser l’autoboot de pfSense agir.

2. Installation de pfSense

En démarrant pfSense, l’installeur va démarrer automatiquement si le mode rescue n’est pas sélectionné. Le premier écran permet de configurer rapidement l’installation.

Les options par défaut vont bien, bien qu’il soit possible de configurer le clavier, cela n’importe peu car une fois le système redémarré, nous allons rebasculer sur un clavier en-us. A l’étape suivante, nous allons choisir la « Quick / Easy Install » et le « Standard Kernel ». Ensuite, nous allons redémarrer. Par défaut, l’accès à l’interface d’administration est 192.168.1.1 et les logins admin / pfsense. Après le premier redémarrage, le système va se préconfigurer, cela peut prendre quelques minutes. A l’issue, il est possible de configurer l’appliance via le web ou via la console. L’installation est terminée lorsque nous arriverons sur cet écran post-boot.

C’est le moment de vérifier que tout est bien configuré. Normalement le WAN ressort sur l’interface em0 (sur VMware, cela doit être la carte WAN, situé sur le vSwitch0, avec l’adresse MAC de l’IP failover, la première carte de la machine) et le LAN ressort sur l’interface em1 (carte LAN, situé sur le vSwitch que nous avons créé au début, avec une MAC automatique, la deuxième carte de la machine).

3. Configuration de base de pfSense

Attention : la console de pfSense utilise un clavier en-us. Il est possible de changer la disposition du clavier en accédant au shell, cependant étant donné le peu de manipulations à faire en console, nous allons rester sur ce type de clavier.

La première chose à faire une fois l’écran accessible est de configurer les deux cartes. Même si l’interface LAN possède la bonne IP, nous allons faire une passe sur les deux. Nous allons donc saisir 1 comme option, et répondre à quelques questions :

  1. Création de VLAN : cela n’est pas important au départ, et peut très bien attendre la configuration par le web. Nous allons donc répondre « No » pour l’instant.
  2. L’interface pour le WAN nous est demandée. Il s’agit donc de notre première carte réseau sur la machine, donc em0 pour pfSense.
  3. L’interface pour le LAN nous est demandée : em1.
  4. Nous n’avons pas d’autres interfaces, nous laissons le champ vide et validons.
  5. Une confirmation est demandée : il suffit de valider.

Un petit temps de traitement est nécessaire et on retombe normalement sur l’écran principal. Nous allons maintenant configurer les adresses des deux interfaces.

En premier, l’interface WAN.

Il nous faut renseigner l’adresse IP WAN (l’IP failover, ou celle reliée à l’adresse MAC que nous avons saisi auparavant), le masque de sous-réseau et enfin la passerelle. Dans le cas d’une IP failover, il est fort probable que la passerelle soit l’IP en .254 à la fin. Ensuite, à moins d’avoir une IPv6, la seconde partie peut être passée – sinon, le même raisonnement que pour l’IPv4 est à appliquer. Ensuite, il est demandé si l’on veut basculer l’interface web sur du HTTP au lieu du HTTPS.

On revient ensuite à l’écran de base et nous allons répéter cette configuration mais pour la deuxième interface.

La configuration de la carte LAN est plus simple. 192.168.1.1 devient la passerelle pour les autres VM.

Il est possible d’activer le DHCP sur l’interface LAN à la fin de la configuration. Etant donné que nous allons installer une seule machine virtuelle sur la plateforme, cela a peu d’importance. Si l’option est sélectionnée, alors la plage d’adresses que le serveur pourra attribuer est demandée. La configuration de base est terminée, pfSense fonctionne.

4. Pour aller un peu plus loin

Nous allons déployer une machine virtuelle toute simple afin de tester le bon fonctionnement de pfSense et accéder à l’interface web bien plus pratique que le shell BSD. Une machine virtuelle fonctionnant sous Debian GNU/Linux fera parfaitement l’affaire. La petite image « netinst » pèse moins de 300 Mo et nécessite une connexion internet pour s’installer : le test idéal.

Une seule carte réseau pour la VM, celle du LAN.

Je ne vais pas faire une passe sur l’installation d’un système Debian. Cependant, l’installateur a bien pu configurer la machine virtuelle automatiquement grâce au DHCP que j’ai activé – sans cela, il aurait fallu saisir une adresse IP – par exemple 192.168.1.2 – et pfSense offre bien internet à la VM qui a pour IP de sortie notre IP failover, car les paquets sont téléchargés depuis les miroirs de Debian au fil de l’installation :

L’image « netinst » de Debian a besoin d’internet pour récupérer les paquets qui ne font pas partie du système de base. La machine a donc bien accès au net.

pfSense fonctionne donc très bien, puisqu’il est accessible et que l’appliance a fourni une adresse IP à ma machine virtuelle. On peut donc désormais se connecter à l’interface d’administration et passer par le petit assistant de configuration. Normalement, tout a été configuré par nos soins via la console – rien n’est à modifier pour l’instant. Enfin, à la fin, il est conseillé de changer le mot de passe d’administration.

Une fois libre, il est possible d’accéder à tout un tas de paramètres différents, mais nous allons seulement nous intéresser à la partie NAT dans ce billet, car les possibilités de pfSense sont très larges (sur mon infra perso, je m’en sers également comme serveur DHCP et DNS, par exemple). En allant dans Firewall > NAT, il est possible de créer des règles de redirection de ports. Par exemple, si je veux accéder en RDP à une machine VM Windows, il me suffit de créer une règle et de demander la redirection des bons ports :

Si 192.168.1.12 est l’IP de ma machine Windows, tout ce qui arrive sur le port 3389 de l’interface WAN (donc l’IP failover) est redirigé vers le port 3389 de ma machine Windows. Une fois la règle enregistrée, la configuration de pfSense doit être validée pour qu’elle rentre en action.

Pour faire un test de bon fonctionnement, je vais ouvrir le port 22 et le rediriger vers la VM.

L’écran de NAT de pfSense. Il est possible de catégoriser et de trier toutes les règles.

Une fois la configuration appliquée, il ne me reste plus qu’à ouvrir un client SSH et à tenter de me connecter.

La connexion est ouverte, je suis bien connecté en SSH sur ma VM depuis une machine extérieure.

Et voilà 😉

Afin de clore cet article, deux autres petites choses :

  • Il existe un paquet BSD pour les vmtools afin que la machine s’interface mieux avec ESXi. Dans System > Package Manager, il suffit de rechercher Open-VM-Tools et d’installer le paquet.
  • Dans Diagnostics > Backup & Restore, il est possible de faire un export XML de toute la configuration de pfSense. Cette sauvegarde est importante car en cas de crash, il est possible depuis l’install de pfSense de lui donner ce fichier XML pour que toute la configuration soit restaurée à l’identique.
L’écran des baux DHCP (Status > DHCP Leases), à partir duquel on peut transformer un bail temporaire en une réservation.