pfSense 2.4.3 : IP-Failover sur un ESXi chez OVH
Sommaire
I. Présentation
Avec une seule IPv4, un serveur dédié à manager et potentiellement des services à publier au travers de machines virtuelles, ce n'est pas toujours simple de s'en sortir... On peut très bien imaginer attribuer une IPv6 à l'hyperviseur pour l'administration et conserver l'adresse IPv4 pour publier nos services, au travers d'un firewall virtuel.
Dans le cadre de la location d'un serveur dédié chez OVH, vous pouvez bénéficier d'un nombre conséquent d'IPv4, gratuitement. Enfin presque. En fait, il n'y aura pas de loyer mensuel sur cette option car c'est inclus, mais il y a un coût de mise en service de 2,40€ TTC par adresse IP supplémentaire.
L'objectif de cette configuration est de conserver l'adresse IPv4 fournit par OVH pour administrer l'hyperviseur VMware ESXi via le vSphere Client. Tout en ayant une seconde adresse IPv4 pour sortir sur Internet pour les machines virtuelles. Pour protéger l'accès à nos machines virtuelles, comme on le ferait finalement sur une infrastructure on-premise, on va positionner en frontal un firewall.
Le rôle de firewall sera assuré par la solution pfSense, où l'interface WAN se verra attribuer l'adresse IP-Failover, et où le LAN isolé et NATé permettra aux VMs de sortir sur Internet. On pourrait même imaginer avoir plusieurs LANs isolés, le tout contrôlé par le firewall. L'intérêt est d'acquérir/louer qu'une seule IP publique supplémentaire, mais on pourrait en prendre plusieurs et envisager de la redondance.
Pour mener à bien cette configuration, il nous faut :
- Un serveur dédié chez OVH (ou SoYouStart)
- Une adresse publique IP-Failover et l'adresse MAC virtuelle associée
- Une machine virtuelle pfSense
- Une machine virtuelle cliente pour administrer le pfSense et tester l'accès au web
- Un serveur VMware ESXi, en version 6.5 et administré par le vSphere Web Client dans mon cas
Si l'on fait abstraction de la couche virtuelle, ça nous donne le schéma suivant :
Pour des raisons de confidentialité, certaines données sont masquées. Voici les données que nous utiliserons :
- IP publique OVH dédiée à la gestion ESXi : 50.50.50.1
- Passerelle OVH : 50.50.50.254
- IP Failover acquise en supplément : 90.90.90.90
- Adresse MAC virtuelle du failover : 00:50:56:0a:16:0e
Voilà, maintenant nous allons commencer...
II. Configurer l'IP-Failover sur OVH
Remarque : Nous partons du principe que vous avez déjà commandé votre IP-Failover.
Sur votre espace client OVH, accédez au menu "Dédié" et ensuite sur la gauche cliquez sur "IP".
La liste de vos IP va s'afficher, avec l'une qui sera mentionnée par l'icône "FO" pour "IP Failover", c'est celle-ci qui nous intéresse.
Tout au bout de la ligne sur la droite, cliquez sur les trois points, puis "Ajouter une MAC virtuelle".
Sélectionnez le type "vmware" et indiquez le nom d'hôte du serveur qui va bénéficier de cette IPv4 et de cette MAC. Validez.
Il faut ensuite patienter quelques minutes...
Le message "Une nouvelle MAC virtuelle a été générée et sera disponible sur l'IP X.X.X.1 dans quelques minutes." va s'afficher et l'adresse MAC sera indiquée, comme ceci :
Notez cette adresse MAC car nous allons dès maintenant la configurer sur notre VM firewall.
III. Configurer l'adresse MAC statique sur la VM
Je ne vais pas détailler ici la procédure de création d'une machine virtuelle, ni l'installation de pfSense ou encore des vSwitchs dans VMware. Nous partons du principe que vous avez une machine virtuelle pfSense avec deux cartes réseau :
- Une carte réseau rattachée à un vSwitch pour le WAN, qui utilise l'adaptateur physique de votre serveur dédié OVH (ce vSwitch est déjà existant si vous avez utilisé l'installation ESXi via OVH) - C'est sur cette carte virtuelle du firewall que l'on va attribuer l'IP-Failover
- Une carte réseau rattachée à un vSwitch pour le LAN, interne à la couche de virtualisation c'est-à-dire qu'il n'a pas d'adaptateur physique, il faudra passer par le firewall pour accéder à Internet
Nous allons maintenant attribuer l'adresse MAC fournie par OVH sur la carte WAN du firewall pfsense. Pour cela, vous devez éteindre la VM car ce n'est pas possible "à chaud".
Ensuite, effectuez un clic droit sur la VM et "Modifier les paramètres".
Déroulez les options de la carte réseau WAN, et passez l'adresse MAC sur "Manuel". Au sein du champ sur la droite, renseignez l'adresse MAC. Comme ceci :
Validez la configuration et vous pouvez relancer votre VM.
IV. pfSense : Interface WAN et routage
Sur mon serveur dédié, j'ai également une machine virtuelle Windows 10 connectée sur le LAN isolé. L'adresse IP par défaut du LAN pfSense est 192.168.1.1/24, je lui ai donc attribué l'adresse IP 192.168.1.2/24 ce qui permet de se connecter sur l'interface de gestion du pfsense, en https.
Cet accès va faciliter la configuration de la carte WAN et surtout évitera d'y revenir plus tard. Étonnamment, via l'interface web on peut définir un masque /32 sur une interface mais pas via la configuration en shell où l'on peut seulement jusqu'à /31. Du coup, si on configure via le Shell il faudrait revenir sur l'interface ensuite pour rechanger le masque...
Une fois sur l'interface de pfSense (default login : admin / password : pfsense), accédez à "Interfaces" puis "WAN".
Configurer l'adresse IPv4 statique sur l'interface WAN, en indiquant l'IP Failover dans le champ. Pour ma part ce sera 90.90.90.90 et mettez le masque en /32. Pour la passerelle, nous devons utiliser la passerelle de l'adresse IP publique du serveur dédiée, ce qui est hors réseau par rapport à l'IP définie sur l'interface. Pfsense ne va pas nous laisser faire via l'interface web... Il va falloir créer nos propres routes en ligne de commande, laissez impérativement "None" pour la passerelle et validez.
Maintenant, ouvrez la console pfSense, vous devriez d'ailleurs voir vos interfaces apparaître avec le nom (em0 et em1) ainsi que l'adresse IP. Indiquez le choix "8" pour ouvrir la console.
Pour éviter tout conflit, on va supprimer une éventuelle route par défaut existante :
route del default
Maintenant, on va définir une passerelle sur notre interface WAN "em0" et ensuite indiquer à pfSense la passerelle par défaut à utiliser. Ce qui donne :
route add -net 50.50.50.254/32 -iface em0 route add default 50.50.50.254
Pour rappel, "50.50.50.254" correspond à la passerelle utilisée par le serveur dédié OVH. Autrement dit, vous devez reprendre la même passerelle que celle utilisée par votre ESXi.
A partir de ce moment-là, vous devez pouvoir ping Google :
Attention : après le redémarrage, cette configuration sera perdue ! Il faut passer par shellcmd pour reéxecuter ces deux commandes à chaque démarrage, lisez notre tutoriel à ce sujet : pfsense shellcmd.
A ce stade de la configuration, votre pfSense accède à Internet mais pas notre client Windows 10 connecté au LAN. Il va falloir créer une règle du NAT.
V. pfSense : Règle de NAT
A partir de la VM Windows 10, retournez sur l'administration Web de pfSense. Dans le menu "Firewall", cliquez sur "NAT" et ensuite sur la section "Outbound".
En ce qui concerne le mode de NAT, choisissez "Manual Outbound NAT" ce qui va nous donner la main sur les règles de NAT que l'on veut créer.
Sauvegardez la configuration, ensuite appliquez-la.
Maintenant, dans le bas de la page cliquez sur le bouton pour ajouter une règle de NAT.
Nous allons utiliser les paramètres suivants :
- Interface : WAN
- Protocol : Any
- Source : Network - 192.168.1.0/24 pour NATer les hosts connectés au LAN isolé
- Destination : Any (Internet)
- Translation : Interface Address (c'est l'IP de l'interface WAN qui sera utilisée pour sortir sur Internet)
Quand vous aurez définit ces paramètres, validez la création de la règle et appliquez la configuration.
Dès lors que cette règle est appliquée, votre machine virtuelle connectée au LAN doit pouvoir accéder à Internet en passant par votre firewall :
Voilà, la configuration est terminée. Il ne vous reste plus qu'à peaufiner les règles de firewalling sur votre pfSense, puis à créer des VMs dans votre LAN isolé !
Merci pour le tuto, tu me sauve des heures !!!
Petite modification en vmware 6.7 et pfsense 2.4.4
route add default 50.50.50.254 et non pas route add default 50.50.50.254/32
la config du tuto est bonne, c’est bien route add default 50.50.50.254
tu confonds avec la config pour iface
THANK YOU.
Thank you so much Florian! After days of googling, trying, testing and failing, I come across your article and following YOUR steps, I finally manage to setup PFSense.
Thank you!
Hi Florian,
I have followed your blog with 2.4.4 but ping gives sendto no route to host? Do you have an idea?
I got the same problem. You found anything?
Ok I found, I had the bad Gateway. I was using desktop vSphere client, so the gateway wasn’t visible. The OVH gateway usually ends with .254. The exact gateway IP can be found on vSphere web client under Networking->TCP-IP stacks.
Hi, same on Online server with vmware, i had to use the gateway of the ip stack
Bonjour et merci pour ce super tuto !
Malheureusement je n’arrive pas à accéder à internet, j’ai toujours une erreur « no route to host ». D’ailleurs l’IP de la gateway en 254 répond « host down » au ping.
Auriez-vous une idée pour m’aider SVP ?
As-tu trouver la solution?
Bonjour, merci pour ce guide.
Il est possible de créer la route sans passer par le CLI. Dans les options avancées de la route par défaut, cocher la case « Use non-local gateway through interface specific route. » (sous pfsense 2.4.4, pas essayé avec une version plus ancienne.
Bonjour,
J’ai suivi ce tuto, mais sur une pfsense 2.4.4 je ne parviens pas à configurer la route.
En ligne de commande, j’ai le message « sendto no route to host »
Via l’interface web de la pfsense, je ne trouve pas « Use non-local gateway through interface specific route »
merci Florian pour ton Tuto c’est rarement bien fait alors Bravo !!!!!!! clap clap!!
TOP !!!
Ton tuto est super simple de compréhension !
J’ai juste eu un petit soucis lors de l’ajout de la gateway par CLI, mais en suivant les conseils de Pierre j’ai réussi à le faire à partir de l’ui.
Merci !!
Hello.
J’ai aussi eu le problème du gateway et sans son ajout dans l’IHM (merci Pierre aussi), même avec shellcmd, j’arrivais pas à sortir sur internet avec une machine sur le 192.168.1.x
Par contre, je ne comprends pas ton chapitre 5 sur la NAT. Dans mon cas, je ne l’ai pas fait du tout et ça marche normalement. Une idée du pourquoi ?
Bonjour,
J’ai un souci. La route marche bien, mais après 100 jours d’uptime, j’ai du redémarrer la VM de pfsense, et je me suis rendu compte qu’il fallait que je remette les routes en place manuellement. Y’a-t-il un moyen de faire en sorte que les routes soient persistantes ?
Bonne journée!
Emeric
Bonjour Emeric,
Il est possible d’utiliser l’extension shellcmd, voir ici : https://www.it-connect.fr/pfsense-shellcmd-pour-executer-des-commandes-au-demarrage/
Bon après-midi.
Florian
Bonjour et merci pour les supers explications !
Pour aller plus loin, un de mes réseaux, LAN1, doit accéder à l’API proxmox (port 8006 de l’IP publique, équivalent de 8443 sur vmware je crois).
J’ai créé une règle parefeu qui fonctionne : IP locale sur LAN1 => IP publique port 8006
J’ai sniffé mon IP publique, je vois bien les paquets arriver. Comment faire en sorte que ça réponde maintenant ?
$ nc -w 1 -vz IPPUBLIQUE 8006
nc: connect to IPPUBLIQUE port 8006 (tcp) timed out: Operation now in progress
sur l’IP publique on voit :
16:09:26.914141 IP IPFO > IPPUBLIQUE.8006: Flags [S], seq 268326979, win 64240, options [mss 1460,sackOK,TS val 849514525 ecr 0,nop,wscale 7], length 0
16:09:26.914205 IP IPFO > IPPUBLIQUE.8006: Flags [S], seq 268326979, win 64240, options [mss 1460,sackOK,TS val 849514525 ecr 0,nop,wscale 7], length 0
Ou peut-être est-ce absurde ? Si j’héberge un site sur le port de mon routeur je n’arriverai pas à sortir et à re-rentrer.
Cordialement
Merci Florian pour ce tuto.
J’ai configuré pendant des années la .254 du réseau de failover et du jour au lendemain la gw a disparu.
Le support ovh m’a indiqué cette conf mais elle était tellement tordu et surtout mal documenté que je n’y comprenais rien.
Tu m’as bien aidé sur ce coup là !
comment le nom dédie au chez ovh ?
combien € par mois
je refaire que j’appris un esxi dédie 🙂
cordialement
Roro
Merci pour le tuto : tellement bien fait que j’ai même compris ce que je faisais!
Bonjour,
Ce tuto est-il transposable/utilisable chez online.net où j’ai plus l’habitude d’avoir mes serveurs.
Merci de votre retour ou des expériences de chacun.
Cordialement
DomDeLaBas
Pour le problème de route, il faut bien ne pas omettre de créer 2 vSwitchs, un pour le LAN et un pour le WAN !
Ca parrait évident mais c’est cela qui m’a bloqué car j’avais totalement oublié.
Merci pour le tuto et à Pierre pour l’astuce pour la config de la gateway qui est en effet bien plus pratique que de faire les routes à la main et de devoir installer shellcmd en plus.
J’ai également eu le problème du « host is down » que certains ont rencontrés également en essayant de ping la gateway.
Cela m’a donné du fil a retordre mais je pense avoir identifié la cause de celui-ci : en fait j’ai remarqué qu’en déconnectant et reconnectant le câble virtuel de la VM pfSense (dans ESXI c’est via « modifier les paramètres de la VM » -> décocher la case « connecté » de l’adaptateur réseau 1 -> valider -> retourner au même endroit -> recocher -> valider) la VM retrouvait bien la connexion à la GW de façon aléatoire.
J’ai l’impression que c’est le système d’authentification pour l’accès à la passerelle géré par OVH/Online (scaleway) via adresse failover et MAC spécifiques qui merdouille avec pfsense : parfois l’authentification ne se fait pas et il faut débrancher / rebrancher le cable virtuel 1, 2, 3 fois avant que ça fonctionne.
Car en faisant ceci sans modifier ni la configuration de l’esxi, ni de la VM, ni de pfsense tout marche ou ne marche pas de façon complètement aléatoire.
Je suis chez Online, j’ai ouvert un ticket de support à ce sujet même si je doute fortement qu’ils me donneront une réponse précise à ce sujet 🙂
Bonjour,
Merci pour l’option à cocher quand la passerelle n’est pas dans la même plage que l’IP failover (comme chez OVH) :
Système \ Routage \ Modifier la passerelle
puis
Options avancées \ Utiliser une passerelle non locale : OUI
(Pfsense 2.4.5_1)
Ça fonctionne parfaitement.
Après un ugprade sur pfsense 2.5, la coche dans l’IHM ne semble plus faire l’affaire. Je vais devoir réinstaller shellcmd
Si vous avez une idée du pourquoi..
Merci pour le tuto, avec quelques adaptations, tout fonctionne encore.
Quelques heures de troubleshooting évitées !!!
Merci
pfsense: 2.5.2
esx: 6.7
Bonjour, si je veux ajoute un 2eme pfsense pour faire un cluster, dois-je prendre une ip failover ?