Proxmox VE 6 + pfsense sur un serveur dédié (2/2)

Posted by

Note : cet article a été écrit par Charles Bordet, et se veut être une version à jour de cette suite d’articles écrits sur ce blog (mais avec des versions obsolètes de Proxmox et de PFSense). Merci à lui !


Dans l’article précédent, nous avons mis en place notre serveur Proxmox, l’avons sécurisé, puis avons téléchargé puis installé une machine virtuelle PFSense qui va nous faire office de point d’entrée unique.

Routage du trafic vers la PFSense

Comme nous l’avons déjà évoqué, l’hyperviseur est en première ligne. Et la PFSense est en 2e ligne et nos VMs, bien au chaud derrière.

L’objectif, c’est d’avoir la PFSense en 1e ligne. D’un point de vue purement réseau, l’hyperviseur va s’effacer en ne devenant rien de plus qu’un routeur.

La première chose à corriger, c’est qu’actuellement, il existe un raccourci qui permet de passer directement de l’hyperviseur aux VMs puisqu’ils sont tous sur le réseau LAN. Dans notre schéma mental, on ne veut pas que ce soit possible puisque tout doit passer par pfsense.

Essayez par exemple de pinger 192.168.9.10 depuis l’hyperviseur, ou de pinger 192.168.9.1 depuis la VM.

Sur l’hyperviseur, on va ajouter une route qui dit : Tous les paquets vers le LAN doivent passer par l’interface WAN de la PFSense. C’est cette règle qui nous permet de forcer tout le trafic à passer par la PFSense, comme si la PFSense était en frontal, avant d’arriver dans le LAN.

On crée un fichier /root/pfsense-route.sh avec la commande suivante.

cat > /root/pfsense-route.sh << EOF
#!/bin/sh

## IP forwarding activation
echo 1 > /proc/sys/net/ipv4/ip_forward

## Rediriger les paquets destinés au LAN pour l'interface WAN de la PFSense
ip route change 192.168.9.0/24 via 10.0.0.2 dev vmbr1
EOF

Pour que ce fichier se lance automatiquement dès qu’on boot, on lance la commande chmod +x /root/pfsense-route.sh et on ajoutera à la fin du fichier /etc/network/interfaces la ligne post-up /root/pfsense-route.sh à la fin du bloc de configuration de vmbr2, juste avant le commentaire #LAN :

[...]
auto vmbr2
iface vmbr2 inet static
        address 192.168.9.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        post-up /root/pfsense-route.sh
#LAN

Si vous exécutez ce fichier /root/pfsense-route.sh, et que vous essayez de nouveau de ping l’hyperviseur depuis la VM, ou l’inverse, ça ne devrait plus aboutir. Cela signifie que le petit paquet essaye bien de passer par PFSense, et comme on lui a rien dit, PFsense drop sans mot dire.

Note: Ça veut aussi dire que notre beau tunnel SSH ne fonctionnera plus à terme (si vous avez choisi cette solution plutôt que la "VM rebond")…

Si jamais, pour débugger, vous avez besoin de laisser passer le ping, on peut le réactiver de manière sélective dans PFSense.

Dans l’interface de la PFSense, on va commencer par aller dans Status / System Logs. Puis cliquez sur l’onglet Firewall. Le but ici c’est de vous montrer un moyen de débugger au cas où vous auriez des problèmes.

Sur cette page, vous verrez toutes les connexions bloquées par le pare-feu.

Si vous descendez dans la page, vous allez voir les pings qui ont été bloqués.

Cette vue est utile car elle vus permet de voir tout ce qui a été récemment bloqué. Les petits (-) et les petits (+) vont vous permettre d’ajouter rapidement des règles, respectivement pour dropper ou autoriser des connexions similaires que PFSense rencontrerait à l’avenir.

Si vous voulez tout faire vous même (car vous souhaitez comprendre et maitriser ce que vous faites), allez plutôt dans Firewall/Rules. Cliquez sur Add puis entrez les paramètres suivants :

  • Action : Pass
  • Interface : WAN
  • Address Family : IPv4
  • Protocol : ICMP
  • Source : Any
  • Destination : Any

Cette règle assez permissive permet d’autoriser tous les paquets en protocole ICMP. Une fois ajoutée, n’oubliez pas d’appliquer les changements. Puis réessayez de faire pinger vos machines. Le ping est de retour ! Mais il passe par la PFSense cette fois-ci.

Port forwarding de la PFSense

Maintenant que la base de notre script fonctionne, on va continuer à ajouter des règles iptables. Comme il est assez long, je vais vous l’expliquer et on va le remplir au fur et à mesure. Pour ceux qui veulent la version complète du fichier immédiatement, elle est disponible ici.


Note : Le gros souci avec iptables et les règles de firewalling en général, c’est que même quand on est expert, si jamais vous vous êtes planté (ou que pour une raison ou pour une autre, les commandes que je donne ne sont pas 100% compatibles dans votre contexte il y a une petite subtilité) vous risquez de vous couper l’accès.

Un bon moyen de limiter ce genre de risque est de suivre la procédure suivante à chaque fois que vous faites une modification :

  • faire une copie datée des fichiers /etc/network/interfaces, /root/pfsense-route.sh et /root/iptables.sh avant toute modif
  • désactiver/supprimer les lignes avec le post-up /root/pfsense-route.sh et/ou /root/pfsense-route.sh dans /etc/network/interfaces, ce qui vous permettra de retrouver la main après une reboot
  • exécuter le script à la main une première fois, puis ne rebooter seulement que SI TOUT fonctionne (en testant de nouvelles connexions)

Si jamais vous vous êtes scié la jambe (ou la branche, ou tiré une balle dans le pied), un reboot et une restauration du fichier initial vous tirera d’affaire.


Note bis Ne lancez pas non plus ces instructions une par une. En effet, la première chose qu’on fait, par convention, c’est de TOUT dropper, pour réautoriser ensuite au compte goute. Donc si vous avez de grande chance de vous bloquer vous même.

1/6 Variables

Avant de commencer quoique ce soit, récupérez l’adresse IP publique de votre machine. On en aura besoin dans le script. Vous pouvez la trouver dans l’interface de votre Proxmox si elle est visible depuis votre hyperviseur, ou a minima dans l’interface de votre provider.

Ensuite, on l’exporte dans le bash pour qu’elle soit intégrée de manière transparente dans le futur script iptables.sh

export PUBIP=xx.xx.xx.xx

Faite ensuite la même chose pour le port que vous avez choisi dans le tuto précédent pour SSH (22 par défaut, mais le tuto précédent donne un port arbitraire, 22153)

export SSHPORT=22153

Puis créez la première partie du script en copiant collant simplement cette commande en entier dans un terminal (le cat va copier proprement les lignes dans un fichier texte)

cat > /root/iptables.sh << EOF
#!/bin/sh

    # ---------
    # VARIABLES
    # ---------

## Proxmox bridge holding Public IP
PrxPubVBR="vmbr0"
## Proxmox bridge on VmWanNET (PFSense WAN side) 
PrxVmWanVBR="vmbr1"
## Proxmox bridge on PrivNET (PFSense LAN side) 
PrxVmPrivVBR="vmbr2"

## Network/Mask of VmWanNET
VmWanNET="10.0.0.0/30"
## Network/Mmask of PrivNET
PrivNET="192.168.9.0/24"
## Network/Mmask of VpnNET
VpnNET="10.2.2.0/24"

## Public IP => Your own public IP address
PublicIP="${PUBIP}"
## Proxmox IP on the same network than PFSense WAN (VmWanNET)
ProxVmWanIP="10.0.0.1"
## Proxmox IP on the same network than VMs
ProxVmPrivIP="192.168.9.1"
## PFSense IP used by the firewall (inside VM)
PfsVmWanIP="10.0.0.2"
EOF

Cette première partie est inoffensive, on définit les variables. Ça permet d’éviter de ré-écrire des milliers de fois les mêmes adresses IPs et de rendre le script un peu plus lisible.

Point très important, vérifiez bien que le fichier contient bien votre adresse IP publique à la ligne qui commence par PublicIP="

2/6 DROP & start again !

Par contre, à partir de maintenant ça se gâte. Par défaut, on spécifie qu’on interdit tout. Tous les paquets sont droppés.

cat >> /root/iptables.sh << EOF

    # ---------------------
    # CLEAN ALL & DROP IPV6
    # ---------------------

### Delete all existing rules.
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
### This policy does not handle IPv6 traffic except to drop it.
ip6tables -P INPUT DROP
ip6tables -P OUTPUT DROP
ip6tables -P FORWARD DROP
    
    # --------------
    # DEFAULT POLICY
    # --------------

### Block ALL !
iptables -P OUTPUT DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP

    # ------
    # CHAINS
    # ------

### Creating chains
iptables -N TCP
iptables -N UDP

# UDP = ACCEPT / SEND TO THIS CHAIN
iptables -A INPUT -p udp -m conntrack --ctstate NEW -j UDP
# TCP = ACCEPT / SEND TO THIS CHAIN
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP

    # ------------
    # GLOBAL RULES
    # ------------

# Allow localhost
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Don't break the current/active connections
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# Allow Ping - Comment this to return timeout to ping request
iptables -A INPUT -p icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
EOF

Ensuite, on crée des chaînes qui vont capturer toutes les nouvelles connexions TCP et UDP, respectivement.

Et enfin, on ajoute des règles un peu de base :

  • On accepte les connexions localhost
  • On ne stoppe pas les connexions existantes. Comme votre connexion SSH par exemple.
  • On autorise les pings. Parce que c’est pratique pour débugger.

Si vous vous demandez ce qui se passerait si vous lanciez le script maintenant, il ne se passerait rien, tant que vous n’essayeriez pas d’ouvrir une nouvelle connexion (SSH par exemple), car on accepte les connexions déjà ouvertes. En revanches, toutes les nouvelles échoueraient…

Pas terrible, donc on continue…

3/6 INPUT

cat >> /root/iptables.sh << EOF

    # --------------------
    # RULES FOR PrxPubVBR
    # --------------------

### INPUT RULES
# ---------------

# Allow SSH server
iptables -A TCP -i \$PrxPubVBR -d \$PublicIP -p tcp --dport ${SSHPORT} -j ACCEPT
# Allow Proxmox WebUI
iptables -A TCP -i \$PrxPubVBR -d \$PublicIP -p tcp --dport 8006 -j ACCEPT
EOF

Ces règles sont à propos de l’interface vmbr0, celle qui nous relie à Internet. On ajoute deux règles :

  • On autorise les nouvelles connexions sur le port SSH qui passent par vmbr0 et dont la destination est notre IP publique.
  • On autorise les nouvelles connexions sur le port 8006 qui passent par vmbr0 et dont la destination est notre IP publique.

Ça c’est seulement pour les paquets entrant, donc les personnes qui veulent initier une connexion avec nous.

Note : vérifiez bien que la ligne juste en dessous de # Allow SSH server contient bien le port que vous utilisez pour SSH (et qu’on a exporté dans la variable SSHPORT) !

Plus tard, on pourra même supprimer ces règles. À la place, on se connectera au VPN, et à partir de là on aura accès au SSH ou au Proxmox.

4/6 OUTPUT

Ensuite, on ajoute les paquets sortants :

cat >> /root/iptables.sh << EOF

### OUTPUT RULES
# ---------------

# Allow ping out
iptables -A OUTPUT -p icmp -j ACCEPT

### Proxmox Host as CLIENT
# Allow HTTP/HTTPS
iptables -A OUTPUT -o \$PrxPubVBR -s \$PublicIP -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -o \$PrxPubVBR -s \$PublicIP -p tcp --dport 443 -j ACCEPT
# Allow DNS
iptables -A OUTPUT -o \$PrxPubVBR -s \$PublicIP -p udp --dport 53 -j ACCEPT

### Proxmox Host as SERVER
# Allow SSH 
iptables -A OUTPUT -o \$PrxPubVBR -s \$PublicIP -p tcp --sport ${SSHPORT} -j ACCEPT
# Allow PROXMOX WebUI 
iptables -A OUTPUT -o \$PrxPubVBR -s \$PublicIP -p tcp --sport 8006 -j ACCEPT
EOF

D’abord, on autorise les pings à sortir. Cette règle est redondante avec une autre précédente où on autorisait les pings dans tous les sens.

L’idée, c’est que la règle précédente est très permissive pour pouvoir débugger. Mais elle est pas censée rester pour toute la vie.

Par contre, autoriser un ping sortant, ça peut toujours servir à l’occasion, et ça pose zéro problème de sécurité.

Puis j’autorise les paquets HTTP et HTTPS à sortir. Ça c’est ce qui va nous donner accès à l’internet. D’ailleurs vous pouvez essayer. Envoyez un ping vers 1.1.1.1 avant d’entrer ces nouvelles règles, ça devrait être bloqué, puis ré-essayez après avoir entré ces nouvelles règles, et ça devrait marcher !

Cette règle vous servira par exemple à télécharger des images ISO ou à mettre à jour le serveur. Ce n’est pas cette règle qui sert à donner accès à l’internet au VM par contre.

Et c’est tout pour les règles output. Vous noterez que m4vr0x en avait ajouté pas mal plus. Je vous conseille d’en rajouter seulement si vous en avez besoin. De base, on est parcimonieux.

Par exemple les règles output pour le port SSH et le port 8006 ne sont pas nécessaires. En effet, on les accepte déjà dans INPUT, ce qui permet à votre ordinateur local d’initier une connexion avec le serveur. Une fois la connexion initiée, tous les paquets sont autorisés (c’est la règle qu’on avait ajouté dans les GLOBAL RULES). La plupart des règles concernent les nouvelles connexions.

5/6 FORWARD

Finalement, il ne reste plus qu’à dire qu’on route tout le trafic vers la PFSense :

cat >> /root/iptables.sh << EOF

### FORWARD RULES
# ----------------

### Redirect (NAT) traffic from internet 
# All tcp to PFSense WAN except ${SSHPORT}, 8006
iptables -A PREROUTING -t nat -i \$PrxPubVBR -p tcp --match multiport ! --dports ${SSHPORT},8006 -j DNAT --to \$PfsVmWanIP
# All udp to PFSense WAN
iptables -A PREROUTING -t nat -i \$PrxPubVBR -p udp -j DNAT --to \$PfsVmWanIP

# Allow request forwarding to PFSense WAN interface
iptables -A FORWARD -i \$PrxPubVBR -d \$PfsVmWanIP -o \$PrxVmWanVBR -p tcp -j ACCEPT
iptables -A FORWARD -i \$PrxPubVBR -d \$PfsVmWanIP -o \$PrxVmWanVBR -p udp -j ACCEPT

# Allow request forwarding from LAN
iptables -A FORWARD -i \$PrxVmWanVBR -s \$VmWanNET -j ACCEPT
EOF

Le début est une règle de PREROUTING. Ça veut dire que l’action s’exécute sur le paquet avant toute autre chose. Par exemple, si José essaie de se connecter sur le port 3812 de votre Nextcloud, on veut pas forcément le dropper. Ce genre de décision sera le futur boulot de la PFSense. Sans la règle de pré-routing, le paquet serait droppé par défaut.

Donc à la place, on l’envoie… vers la PFSense.

Notez que cette règle s’applique SAUF pour les ports SSH et 8006, qui ont un traitement un peu particulier. De nouveau, plus tard, quand vous aurez mis le VPN, on pourra aussi supprimer ces règles.

Le paragraphe suivant va de pair avec ce qu’on vient de faire. En gros ça dit : Si un paquet est en transfert d’Internet vers la PFSense, alors on l’autorise. Et ça tombe bien, puisqu’on vient juste de dire que tous les paquets qui viennent d’Internet sont automatiquement transférés vers la PFSense.

Finalement, on fait aussi l’inverse. Tous les paquets qui sont en transfert depuis la PFSense (et donc qui se dirigent de toute vraisemblance vers Internet) sont acceptés aussi. La communication, ça va dans les deux sens.

Donc là, je résume : Un paquet vient d’Internet. On le pré-route vers la PFSense. On accepte ce transfert. La PFSense le reçoit. La PFSense va prendre une décision, par exemple l’envoyer vers une VM, recevoir une réponse, puis renvoyer ce paquet vers Internet. On accepte ce transfert de nouveau.

On a tout ce qu’il faut pour que les VMs aient accès à Internet.

6/6 MASQUERADE

SAUF ! Le port forwarding. La petite astuce en gros qui permet à une machine d’un réseau local à accéder à Internet sans avoir d’IP publique :

cat >> /root/iptables.sh << EOF
### MASQUERADE MANDATORY
# Allow WAN network (PFSense) to use vmbr0 public adress to go out
iptables -t nat -A POSTROUTING -s \$VmWanNET -o \$PrxPubVBR -j MASQUERADE
EOF

A partir de là, le script est prêt. Tentez de l’exécutez et si vous ne vous jetez pas dehors bravo vous avez gagné !

chmod +x /root/iptables.sh
/root/iptables.sh

Là maintenant votre LAN est raccordé à Internet.

Spécificité VirtIO

Sauf si… vous aviez choisi VirtIO comme modèle de carte réseau dans le tuto précédent.

Si vous pingez 1.1.1.1 depuis votre VM Ubuntu, vous allez réussir à joindre Internet. C’est un signe que les règles que nous avons mises fonctionnent bien. Mais… pourtant, l’accès à Internet ne va pas forcément marcher.

C’est un problème qui m’a cassé la tête pendant longtemps. Jusqu’à ce que je tombe sur ce thread au titre évocateur : Quelqu’un a-t-il réussi à *** un *** de PFSense avec Proxmox.

En fait, la solution est documentée sur le site officiel de pfsense

La solution est donc d’aller dans System / Advanced / Networking au niveau des paramètres PFSense et de cocher la case Disable hardware checksum offload.

Et pouf, ça marche.

On est pas mal là ?

A partir de maintenant, vous pouvez vous amuser à regarder les logs du firewall de la PFSense et vous verrez toutes les gentilles personnes qui se font refouler.

On a bien avancé, mais il reste encore quelques petits détails à voir :

  • On doit toujours passer par une VM Ubuntu Desktop pour paramétrer la PFSense. Pas pratique.
  • Le Proxmox est accessible depuis Internet. Pas optimal niveau sécurité.
  • On ne sait pas comment servir un service depuis une VM qui soit accessible depuis Internet (un serveur nginx par exemple).
  • Et aussi comment servir un service pour des besoins internes (un serveur SSH par exemple).

On va voir comment résoudre tout ça dans la prochaine partie. Et puis après on verra comment mettre un VPN en place pour que ce soit bien sécurisé.

Hébergement de services

Mais je suis sûr que vous avez hâte d’utiliser le potentiel de votre hyperviseur dès maintenant ! En tout cas, moi j’avais hâte :D

Donc faisons-le, mais promettez-moi qu’après vous ferez les étapes pour mettre le VPN ;-p

Un serveur nginx sur Internet

Pour l’exemple ici, on va utiliser notre VM UbuntuDesktop. C’est vraiment pour l’exemple, parce que je pense que c’est mieux d’isoler les services. 1 VM = 1 service.

On va donc aller sur la VM, et dans le terminal on install nginx: sudo apt install nginx (faites un update d’abord).

Une fois l’installation faite, vérifiez que le serveur fonctionne bien en allant sur http://localhost à partir de la VM. Vous devriez voir l’écran de bienvenue de nginx.

Maintenant, on veut arriver à accéder à cette page depuis Internet. Depuis chez nous quoi. Pour ça, on va aller dans la configuration de la PFSense, et cliquer sur Firewall/NAT, puis ajouter :

  • Interface : WAN
  • Protocol : TCP
  • Destination : Any
  • Destination Port Range : 8001
  • Redirect target IP : 192.168.9.10
  • Redirect target port : 80
  • Description : Serveur nginx

Ici il faut bien avoir en tête qu’on se met du point de vue de la VM dans le LAN. Donc destination signifie la destination du paquet qui part de la VM. On veut qu’il arrive d’Internet, sur le port 8001. Ce choix de port est complètement libre.

Le Redirect target IP, c’est l’IP de la VM, ainsi que le port initial du serveur nginx. Là on n’a pas le choix par contre.

On valide et on applique les changements.

Vous remarquerez qu’une règle a automatiquement été ajoutée dans Firewall/Rules. Oui parce que c’est bien de mettre un NAT en place, mais si le port 80 n’est pas ouvert au niveau de la PFSense, les paquets ne passeront pas.

On attend une petite minute, et on essaie d’accéder : http://proxmox.example.com:8001.

Gagné !

Un serveur SSH sur l’internet privé

Bon, maintenant supposons qu’on veuille mettre en place un serveur SSH.

Oui parce que la console via l’interface de Proxmox, c’est ok, mais bon, autant utiliser le terminal dont on a l’habitude.

C’est différent du serveur nginx parce que cette fois-ci, on n’a pas besoin de le déployer publiquement. Moi je dis que si un service est réservé à un usage privé, il faut le laisser privé. Sinon on multiplie les angles d’attaque pour les méchants.

Donc là l’objectif c’est de pouvoir se connecter en SSH sur notre machine UbuntuDesktop à partir de l’hyperviseur. Donc oui, il faut d’abord SSH dans l’hyperviseur, et à partir de là, on SSH dans la VM. Trop d’étapes ? Plus tard, avec le VPN, vous pourrez directement SSH dans la machine sans cette étape intermédiaire.

Premièrement, installons le serveur SSH sur la VM Ubuntu : sudo apt install openssh-server. De base, il va écouter sur le port 22, et on va laisser ça comme ça.

Vous l’avez compris, il va falloir ouvrir le port sur la PFSense. Pas de NAT cette fois-ci, juste une ouverture de port. Donc dans Firewall/Rules :

  • Action : Pass
  • Interface : WAN
  • Address Family : IPv4
  • Protocol : TCP
  • Source : Single host = 10.0.0.1
  • Destination : LAN net (on pourrait se limiter à notre VM, mais on va probablement vouloir se connecter en SSH systématiquement à toutes les VMs)
  • Destination port Range : 22
  • Description : SSH pour les VMs

On valide, on applique les changements, on attend une petite minute, et on essaie depuis l’hyperviseur : ssh charles@192.168.9.10.

Timeout.

Ah !

Pourquoi ?

C’est là que je vous annonce que tout à la fin de ce tutorial, vous trouverez une section Comment débugger qui vous apprendra comment écouter des paquets et comprendre ce qui se passe sur vos machines. Voici un petit récap en attendant.

Un moyen de comprendre les flux de paquets, pourquoi ils sont bloqués, où est-ce qu’ils sont bloqués, etc., c’est d’utiliser la commande tcpdump qui permet de sniffer le trafic sur votre machine. Cette commande m’a énormément aider pour suivre le tuto de m4vr0x, donc je vous donne l’astuce aussi.

Un tcpdump -i vmbr1 -p tcp permet d’écouter sur l’interface WAN. Outre le bruit des méchants qui tapent à votre porte, on s’attend à voir des paquets SSH aller de 10.0.0.1 vers 192.168.9.10. Il n’en est rien. Ça veut dire quoi ? Ça veut dire que les paquets ne partent même pas de la machine. Pourquoi ?

Les iptables ! Mais oui. On n’a jamais dit qu’on acceptait de faire sortir des paquets sur le port 22.

Une autre astuce de tonton : Dans le fichier iptables qu’on avait créé, vous pouvez rajouter l’instruction suivante : iptables -A OUTPUT -p tcp -o vmbr1 -j LOG. Placez-la avant les instructions qui bloquent tout (donc vers le début du fichier). Ça vous permettra d’enregistrer tout le trafic qui correspond à l’instruction (en l’occurrence, ici, les paquets sortants en TCP sur l’interface vmbr1), et donc de voir ce qui est bloqué et ce qui ne l’est pas. Les logs s’enregistrent dans /var/log/syslog.

Ici, tout simplement, on va dire qu’on autorise les paquets à sortir sur l’interface vmbr1. Rajoutez à la fin du fichier iptables ces quelques lignes :

cat >> /root/iptables.sh << EOF
    # --------------------
    # RULES FOR PrxVmWanVBR
    # --------------------

### Allow being a client for the VMs
iptables -A OUTPUT -o \$PrxVmWanVBR -s \$ProxVmWanIP -p tcp -j ACCEPT
EOF

(Promis, on y touche plus)

Ici, vous avez peut-être deux questions qui vous viennent à l’esprit.

On avait pas déjà l’ensemble du trafic qui était autorisé de l’hyperviseur vers la PFSense ?! Alors, oui, mais seulement en FORWARD. On avait mis une règle qui acceptait tous les paquets qui provenaient d’Internet et qui étaient transférés vers la PFSense. Là, dans ce cas, on accepte tous les paquets en provenance de l’hyperviseur vers la PFSense.

Pourquoi on ne limite pas au port 22 ? C’est un peu brutal cette ouverture générale non ? C’est vrai. L’idée, c’est de ne pas avoir à toucher à ce fichier dès qu’on veut rajouter un service. On sous-traite la gestion des autorisations à la PFSense. Et comme c’est seulement les connexions qui sont issues de l’hyperviseur, donc les communications internes, ce n’est pas gênant.

De nouveau, le VPN résoudra ce genre de problèmes.

À présent, essayez de vous connecter en SSH depuis l’hyperviseur vers la VM, et ça marche !

Accéder à la PFSense depuis Internet

Dernier petit point important avant de passer au VPN : Comment accéder à la PFSense depuis votre laptop sans utiliser cette VM qui lag du cul ? (Oui bon désolé mais là j’écris ce tutorial en étant en Asie et ma VM est en Allemagne, c’est horrible le lag !)

C’est très simple. On va juste ouvrir le port HTTPS sur la PFsense. Ajoutons la règle suivante :

  • Action : Pass
  • Interface : WAN
  • Address Family : IPv4
  • Protocol : TCP
  • Source : Any
  • Destination : This firewall (self)
  • Destination Port Range : HTTPS
  • Description : Accès à la PFSense depuis Internet

À présent, si vous vous connectez sur https://host.domain.name, vous pourrez accéder à la PFSense.

Note de zwindler : On préfèrera plutôt ajouter une règle similaire à la précédente qui autorise 10.0.0.1 à accéder à 192.168.9.254 sur le port 443. Ceci nous permettra de refaire marcher notre tunnel SSH (qui ne marche plus depuis qu’on a ajouté la route en tout début de ce 2ème article) pour avoir la console pfsense en local sur votre machine Linux ou Windows.

Sécuriser les services privés avec un VPN

Bon, c’est bien tout ça. On est presque au bout.

Mais il reste des problèmes :

  • J’aime pas trop avoir cette PFSense accessible par n’importe qui (zwindler: "moi non plus"). Y’a que moi qui en ai besoin après tout.
  • Pareil pour l’hyperviseur Proxmox, que ce soit au niveau de l’accès SSH ou de l’interface web.
  • Et puis c’est chiant pour SSH dans une VM. Il faut faire 2 étapes. C’est long 2 étapes !

Woh woh.. calmos ! Le VPN va résoudre tous ces problèmes.

L’idée c’est qu’on va créer un nouveau réseau virtuel : 10.2.2.0/24. La PFSense sera dans ce réseau virtuel. Et on va pouvoir se connecter dans ce réseau virtuel, de telle sorte que notre laptop aura une IP privée du type 10.2.2.2 (le 10.2.2.1 sera réservé à la PFSense).

À partir de là, modulo 2-3 changements, on pourra accéder au LAN à travers la PFSense. Et évidemment, il n’y a que nous qu’on aura le droit de se connecter au VPN.

Et le truc super cool, c’est que la PFSense rend cette création de VPN su-per-sim-ple. Allez, c’est parti ! Déjà, il faut créer des certificats.

Création de l’autorité de certification

Dans la PFSense, on clique sur System/Cert. Manager. puis Ajouter :

  • Descriptive Name : L’autorité de Certification
  • Method : Create an internal Certificate Authority
  • Key length : 2048 (note de zwindler: MINIMUM, n’hésitez pas à mettre 4096)
  • Digest Algorithm : sha256
  • Lifetime : 3650
  • Common Name : example.com (changez pour le nom de votre autorité)
  • Country Code : FR

Création du certificat pour le serveur

Maintenant on clique sur l’onglet « Certificates », puis Ajouter :

  • Method : Create an internal Certificate
  • Descriptive Name : Le serveur VPN
  • Certificate authority : Choisissez votre autorité de certification nouvellement créée
  • Key length : 2048 (note de zwindler: MINIMUM, n’hésitez pas à mettre 4096)
  • Digest Algorithm : sha256
  • Lifetime : 3650
  • Common Name : vpn.example.com (changez pour le nom du serveur VPN)
  • Certificate Type : Server Certificates

Création du certificat pour le client

On recrée un nouveau certificat, mais changer le type à la fin :

  • Method : Create an internal Certificate
  • Descriptive Name : Le client VPN
  • Certificate authority : Choisissez votre autorité de certification nouvellement créée
  • Key length : 2048 (note de zwindler: MINIMUM, n’hésitez pas à mettre 4096)
  • Digest Algorithm : sha256
  • Lifetime : 3650
  • Common Name : vpn-client.example.com (changez pour le nom du client VPN)
  • Certificate Type : User Certificates

C’est fini pour la création de certificats !

Création du serveur VPN

On va dans VPN/OpenVPN et Ajouter :

  • Server mode : Remote Access (TLS + User Auth)
  • Protocol : UDP
  • Interface : WAN
  • Local Port : 18223 : De nouveau, on change le port par défaut.
  • Description : Mon VPN
  • TLS Configuration : Activé
  • Peer Certificate Authority : Choisissez votre autorité de certification
  • Server Certificate : Choisissez le certificat pour le serveur
  • DH Parameter Length : Note de zwindler – n’hésitez pas à passer à 4096
  • Encryption Algorithm : N’hésitez pas à choisir un peu plus que le choix par défaut AES-128
  • IPv4 Tunnel Network : 10.2.2.0/24
  • Redirect IPv4 Gateway : Activé. Cette case vous permettra d’accéder à l’internet à travers le VPN. Sinon, vous pouvez spécifier le réseau local auquel vous souhaitez accéder avec le VPN (192.168.9.0/24 dans notre cas).
  • Concurrent connections : 3. Une pour l’ordi, une pour le téléphone, et une pour un attaquant. Non je déconne :D Mettez 2. Ou en tout cas, mettez le nombre correspondant au nombre d’appareils que vous connecterez simultanément.
  • Compression : Disable Compression. Conseillé pour ne pas être sensible aux attaques VORACLE.
  • Push Compression : Cochez la case. Ne pas cocher cette case m’empêchait de me connecter via mon laptop sous linux. Mais ça marchait avec Android. Cocher juste la case et épargnez-vous le mal de crâne.
  • Dynamic IP : Cochez la case.

Et voilà !

Maintenant il nous faut un utilisateur et on pourra se connecter.

Création de l’utilisateur pour le VPN

Dans System/User manager, cliquez sur Ajouter.

  • Disabled : On ne coche pas la case.
  • Username : charles
  • Password : xxx

Enregistrer. Puis retournez éditer l’utilisateur et ajoutez-lui le certificat client que nous avons créé plus tôt. Dans User Certificates, cliquez sur Ajouter, puis :

  • Method : Choose an existing certificate
  • Existing Certificate : Le Client VPN

On enregistre.

Configuration du client

On est bon !

On peut facilement exporter un fichier de configuration pour automatiquement configurer votre client VPN, que ce soit sous Windows, Mac, Linux, Android, ou votre machine à café intelligente. Oui oui, il est conseillé de connecter vos objects connectés à un VPN si vous souhaitez y accéder à distance. Ce sont de vraies passoires de sécurité.

On va dans System/Package Manager, puis Available Packages, et on cherche export.

Puis on install openvpn-client-export.

On retourne dans VPN/OpenVPN, et on trouve le nouvel onglet Client Export.

  • Remote Access Server : Mon VPN
  • Host Name Resolution : Other – et on renseigne l’IP publique de notre serveur.
  • Use Random Local Port : On coche la case.

On enregistre et on scrolle jusqu’en bas.

Ici on a plein de possibilités d’exports.

Moi je prends le Most Clients parce que ça marche chez moi.

Voilà voilà.

Ensuite, sur mon ordinateur local, qui est un Ubuntu, je vais dans la configuration Réseau, et je clique sur le petit + à côté de VPN. Je choisis "Import from file…" et j’importe le fichier que je viens juste de télécharger. Il vous faudra peut-être installer le client openvpn d’abord, si vous n’avez pas l’option.

Normalement, tout est déjà pré-rempli, sauf, le username et le password. Entrez ceux de l’utilisateur qu’on a créé plus tôt.

Et voili voiloù !

Ça marche chez vous ?

Parce que chez moi, pas encore…

Ah oui. Toujours ces histoires de pare-feu. C’est ennuyant à la fin.

Ouverture des chakras

Il y a deux modifications à faire.

Imaginez un paquet du VPN. Il arrive sur votre serveur. Il demande son chemin pour aller vers son réseau, c’est-à-dire 10.2.2.0/24. Que lui dit la table de routage ?

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         xx.xx.xx.xx     0.0.0.0         UG        0 0          0 vmbr0
10.0.0.0        0.0.0.0         255.255.255.252 U         0 0          0 vmbr1
xx.xx.xx.xx     0.0.0.0         255.255.255.224 U         0 0          0 vmbr0
192.168.9.0     10.0.0.2        255.255.255.0   UG        0 0          0 vmbr1

En gros : retourne chez toi.

On va rajouter une route pour le VPN. Retournez dans le fichier /root/pfsense-route.sh et rajoutez cette ligne :

## Rediriger les paquets destinés au VPN pour l'interface WAN de la PFsense
ip route add 10.2.2.0/24 via 10.0.0.2 dev vmbr1

Ensuite, exécuter le fichier. Assurez-vous que la route est bien correcte avec netstat -r -n.

Là on dit aux paquets destinés au réseau VPN d’aller vers la PFSense. Elle saura bien quoi en faire. Est-ce qu’on doit modifier les iptables ? Non, les paquets en transfert qui viennent d’Internet sont déjà acceptés.

Alors c’est bon ?

Non.

Il faut que la PFSense accepte ces paquets aussi. Dans l’interface, on rajoute deux règles. La première dit d’accepter les paquets en UDP qui sont à destination de la PFSense sur le port du VPN :

  • Action : Pass
  • Interface : WAN
  • Address Family : IPv4
  • Protocol : UDP
  • Source : Any
  • Destination : WAN net
  • Destination port range : 18223 (mettez le port du VPN)
  • Description : Accès au VPN depuis Internet

Maintenant, vous pouvez tester le VPN. Vous devriez pouvoir vous connecter et aussi accès à Internet en étant connecté. Oubliez pas d’activer les changements après avoir créé la règle, ça m’arrive tout le temps.

Ah oui en fait non, vous n’allez pas avoir accès à Internet. On n’a pas autorisé les paquets qui proviennent du VPN. On ajoute cette nouvelle règle :

  • Action : Pass
  • Interface : OpenVPN
  • Address Family : IPv4
  • Protocol : Any
  • Source : Network – 10.2.2.0/24
  • Destination : Any
  • Description : Accès à Internet depuis le VPN

Et voilà !

À présent, depuis le VPN, vous avez accès à :

  • Internet
  • Les services du WAN, c’est-à-dire la PFSense et le Proxmox (et le SSH vers Proxmox)
  • Le réseau LAN. Tapez par exemple 192.168.9.10 dans votre navigateur, et vous tomberez sur le serveur nginx qu’on a déployé plus tôt.

C’est pas beau ça ?

Bravo ! C’est un solide travail que vous avez fait pour en arriver là.

Le VPN vous sauvera

On pourrait s’arrêter là.. Sauf que. J’ai pas arrêté de vous dire tout le long du tuto que « Tel truc sera résolu quand on aura le VPN ». Eh bien il est temps de résoudre ces problèmes.

Protéger la PFSense

Déjà, la PFSense. À l’heure actuelle, elle est disponible sur les internets mondiaux. Si vous allez voir les logs, vous verrez plein d’individus qui s’y heurtent. C’est pas forcément très rassurant.

Et puis, est-ce qu’on a vraiment besoin d’avoir l’interface disponible à la vue de tout le monde ? Bien sûr que non.

Alors supprimez-moi cette règle qu’on avait ajouté :

Dans le doute, vous pouvez seulement désactiver la règle en cliquant sur le ✓. Ça vous évitera de la recréer complètement si vous vous êtes planté quelque part.

Vous n’aurez plus accès en tapant https://hostname.domain.name mais plutôt l’IP du LAN : https://192.168.9.254. Pour changer le domaine, il faudra mettre en place un serveur DNS interne.

Si vous retournez dans les logs, vous n’en verrez pas moins. Vous en verrez encore plus même ! Puisqu’à présent, vous verrez le blocage du port 443.

Protéger l’interface web du Proxmox

Là, on va faire pareil, mais un peu différent. À l’heure actuelle, on accède à l’interface web de Proxmox sans passer par la PFSense.

À la place, on va :

  1. Rediriger le port 8006 vers la PFSense (en supprimant l’exception dans les iptables). Ceci annulera l’accès depuis Internet.
  2. Autoriser d’accéder au port 8006 du serveur proxmox depuis la PFSense. Ceci activera l’accès depuis le VPN.

Dans le fichier des iptables, on va éditer la ligne suivante :

iptables -A PREROUTING -t nat -i $PrxPubVBR -p tcp --match multiport ! --dports 21153,8006 -j DNAT --to $PfsVmWanIP

On supprime tout simplement le 8006. Et on exécute le fichier. À présent, vous n’avez plus accès à l’interface web Proxmox du tout !

Oh, et on peut aussi supprimer ces lignes là : la règle qui accepte les paquets sur 8006 aussi, cette ligne-là :

iptables -A TCP -i $PrxPubVBR -d $PublicIP -p tcp --dport 8006 -j ACCEPT
iptables -A OUTPUT -o $PrxVmWanVBR -s $ProxVmWanIP -p tcp -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT

Autrement dit :

  • On arrête d’accepter les pings dans tous les sens
  • On arrête d’accepter les paquets entrant sur 8006
  • On arrête d’accepter les paquets sortant sur le port SSH

Rappelez-vous que le serveur Proxmox n’est pas une VM ordinaire. C’est une VM avec un fichier iptables ! Il faut juste qu’on lui dise d’accepter les paquets qui viennent de la PFSense. Par où ? Par vmbr1. Rappelez-vous qu’on a condamné l’accès vmbr2. Voici la règle à rajouter dans les iptables :

iptables -A TCP -i $PrxVmWanVBR -d $ProxVmWanIP -p tcp --dport 8006 -j ACCEPT

Exécutez le fichier. À présent, vous pouvez accéder à https://10.0.0.1:8006.

Est-ce qu’on a besoin d’ajouter une règle dans PFSense ? Non ! On a déjà une règle qui dit : Depuis le VPN, on a accès à tout.

Protéger le SSH du Proxmox

Bon. Là, on pourrait faire exactement la même opération pour protéger le SSH du Proxmox. De telle sorte qu’il ne soit accessible que depuis le VPN.

Mais ça devient un peu dangereux… Qu’est-ce qui se passe si vous perdez accès au VPN ? Genre vous supprimez la config par erreur. Ou votre ordi meurt et vous n’avez pas backup la config ?

Vous allez passer un sale dimanche.

Alors il est toujours possible de résoudre le problème si votre provider vous donne un accès à la console. Je sais que chez Hetzner, c’est possible gratuitement pendant 3 heures. Mais il faut prendre rendez-vous, c’est un peu galère.

C’est pourquoi mon choix est de garder l’accès SSH sur Internet. Par contre, il faut être bien sûr d’avoir activé fail2ban.

Ah ? On me dit dans l’oreillette que le script iptables efface toutes les règles de fail2ban. Oops.

À la fin du script des iptables, on rajoute l’instruction suivante : service fail2ban restart.

Dernière petite chose : Le script iptables ne se lance pas automatiquement au boot. Donc si le Proxmox redémarre, pouf on perd toutes nos règles. C’est beta.

Pour résoudre ça, on va lancer apt install iptables-persistent. Suivez les consignes, et à présent les règles persisteront après un reboot.

Par contre, si jamais vous changez le fichier des iptables, alors lancez l’instruction iptables-save > /etc/iptables/rules.v4.

Nettoyage des règles superflues

Maintenant qu’on a le VPN, on peut supprimer quelques règles dans la PFSense.

  • Autoriser les pings ? Finis les pings ! On supprime.
  • NATer le serveur nginx ? Oui bon ça ok on garde.
  • Autoriser le SSH pour les VMs ? Plus besoin ! Le VPN a accès à tout automatiquement.
  • Accès au VPN depuis Internet ? Euuh oui ça on garde !

Au final, voici mes règles (en gris clair celles qui sont désactivées) :

Petite checklist pour vérifier que tout marche bien :

Depuis le VPN :

  • On a accès à la PFSense sur https://192.168.9.254
  • On a accès au Proxmox sur https://10.0.0.1:8006
  • On a accès au serveur web nginx sur http://192.168.9.10
  • On a accès au serveur web nginx sur l’IP publique et port 8001.
  • On peut se connecter en SSH à charles@192.168.9.10

Hors du VPN :

  • Pas d’accès à la PFSense sur https://hostname.domain.name
  • Pas d’accès au Proxmox sur https://hostname.domain.name:8006
  • On a accès au serveur web nginx sur l’IP publique et port 8001.
  • On ne peut pas se connecter en SSH à charles@192.168.9.10

Checks ? Checks !

Comment débugger

Je ne m’attends pas forcément à ce que TOUT marche dans ce tutorial.

Ça marche pour moi.

Mais vous avez une machine différente, vous êtes dans le turfu, vous avez un provider différent, vous êtes peut-être même gaucher, qui sait ! Ça me paraît plus important de vous apprendre à vous débrouiller par vous-même que vous donner une liste d’instructions à copier/coller, et puis que quand ça ne marche pas vous soyez coincé.

Je présente donc dans cette section les outils que j’ai appris et que j’ai trouvé très utiles pour débugger.

Sniffer vos paquets

Quand vous essayez de pinger un serveur, ou juste de vous y connecter, et que ça ne marche pas, c’est frustrant.

Le pointeur clignote, il se passe rien, et vous savez qu’il ne va rien se passer. Juste si vous attendez 1 minute ou 2, vous allez voir un joli "Timeout".

Ça peut être parce que le paquet s’est perdu, parce qu’il a été mangé par un pare-feu, ou même parce que le service auquel vous tentez d’accéder est hors ligne. Pour comprendre le cheminement d’un paquet, on peut utiliser tcpdump.

L’option -i permet de spécifier l’interface sur laquelle vous écoutez. Par exemple : tcpdump -i vmbr0.

L’option -p permet de spécifier le protocole que vous écoutez. Par exemple : tcpdump -p udp.

Et l’option port permet de spécifier le port. Par exemple : tcpdump port 22.

Vous allez voir, ou non, si un paquet sort ou entre de chez vous ou non. S’il ne sort pas, il est en toute vraisemblance bloqué par iptables ou le pare-feu de la machine sur laquelle vous êtes.

Vous pouvez utiliser cette instruction sur l’hyperviseur, sur une VM, et aussi sur la PFSense.

Loggez les iptables

Est-ce que le script iptable est en train de dropper les paquets que vous envoyez ?

Rajouter une instruction dans votre script avant l’instruction qui potentiellement droppe votre paquet. Par exemple, ajoutez :

iptables -A OUTPUT -o vmbr1 -s 10.0.0.1 -p tcp -j LOG

En gros l’idée c’est de remplacer la fin (ACCEPT) par LOG. Et ensuite les logs s’afficheront dans /var/log/syslog.

Utilisez les logs de PFSense

Dans l’interface de la PFsense, vous pouvez aller dans Status / System Logs, puis Firewall, pour voir toutes les connexions bloquées. La vôtre apparaît ? Il faudrait peut-être créer une règle. La vôtre n’apparaît pas ? Alors soit elle est passée, soit elle n’est même pas arrivée sur la PFSense.

Au passage, en cliquant sur le petit +, vous pouvez facilement ajouter une règle qui concerne spécifiquement la connexion qui a été bloquée.

Si vous suspectez qu’elle est passée, alors regardez par où elle est partie en sniffant les paquets de la machine. Soit avec tcpdump, soit en allant dans Diagnostics/Packet Capture.

Ah oui, et si vous venez juste de mettre à jour les règles du pare-feu.. donnez-lui quelques minutes. Ça m’est arrivé de me casser la tête sur un problème, de décider d’y revenir plus tard, et quand je suis revenu, le problème était résolu comme par magie. Il fallait juste attendre un peu.

Un problème avec le VPN ? Les logs sont dans Status / System Logs, puis OpenVPN.


Vous aimez ce blog ? Partagez-le avec vos amis !   Twitter Facebook Linkedin email

Vous pouvez également soutenir le blog financièrement :
Tipeee

56 comments

  1. Salut à toi ! et merci pour cette super mise à jour,
    j’avais suivi le tuto d’origine il y a longtemps, et l’autre jour j’ai « crashé » mon accès au serveur en bidouillant trop l’Iptables ET la VM pfsense pour essayer d’ouvrir ce port 80 (pour let’s encrypt, old method), après m’être battu un peu, j’ai sauvegardé ce qui devait l’être en mode rescue (pas mal ça m’a permis de découvrir ce mode chez scaleway/online/dedibox) et j’ai relancé une install pour passer sous PVE-6. je suivais donc ton tuto, j’ai saisi à la main toute la conf pfsense, car je préfère saisir et comprendre (au moins un peu) ce que je fais. j’ai attendu la fin pour pousser le script et HOP, plus d’accès.
    Qu’à cela ne tienne, on reboot, on reprends, cette fois je Copie/colle ton script (un peu la flemme de chercher le -probablement- seul endroit ou j’ai fait une faute de frappe) je passe le script et HOP, plus d’accès non plus (il rompt en plus les connections établies 8006 et 22 (j’ai pas changé encore le port, mais j’ai bien mis 22 sur les lignes correspondantes), je vais continuer à chercher, je suis à peu près certain que le problème vient de moi et je devrais me débloquer sans soucis.
    Je profitais juste du temps d’un reboot supplémentaire pour te remercier pour cette mise à jour d’un tuto excellent, qui effectivement risquait de devenir totalement obsolète (et ça aurait été vraiment dommage) bravo à l’auteur d’origine, bravo à la mise à jour. Merci à tous !
    Fabs

  2. hello,
    il semblerait que la partie
    « ### Proxmox Host as SERVER

    Allow SSH

    iptables -A OUTPUT -o $PrxPubVBR -s $PublicIP -p tcp –sport 22 -j ACCEPT

    Allow PROXMOX WebUI

    iptables -A OUTPUT -o $PrxPubVBR -s $PublicIP -p tcp –sport 8006 -j ACCEPT »
    de l’ancien tuto soit nécessaire, je l’ai ajouté à mon iptables.sh et finalement je ne suis pas coupé. J’ai essayé tout le reste avant de plonger dans l’ancien tutoriel, mais rien n’y faisait (même pas passer les Cartes réseaux en E1000 (et les redéfinir dans PfSense).
    si ça peut débloquer quelqu’un-e….
    à bientôt je poursuis le tuto merci !

  3. Salut

    Déjà, un grand merci pour ton travail.
    j’ai bien suivi le tuto mais quand je suis arriver sur la parti iptables,c’est parti dans tout les sens.
    Du coup je me retrouve avec un mix iptables de l’ancien tutos et le tiens car juste avec le tiens je n’y arrivais pas.
    j ai remarque que tu dis qu’il faut enlever des lignes dans iptables(fin de tuto) comme celle-ci iptables -A OUTPUT -o $PrxVmWanVBR -s $ProxVmWanIP -p tcp –dport 22 -j ACCEPT, mais je ne l ai jamais trouver.
    j’ai du louper quelques choses et surement fait une erreur quelques part .
    Pourrais tu poster l’iptables au complet afin que je compare(j’en peux plus,ça pique les yeux à force).
    En attendant que tu puisse éclairer quelques lumières de mon plafond dégarni, je cherche, je cherche…..
    Encore merci à tous pour votre travail!!!!!

    Zona

  4. Bonjour,

    Merci pour ce tuto et merci à Fabulous Fab’s pour son commentaire.
    Pour ma part les deux lignes suivantes étaient nécessaires :
    iptables -A OUTPUT -o $PrxPubVBR -s $PublicIP -p tcp –sport 22 -j ACCEPT
    iptables -A OUTPUT -o $PrxPubVBR -s $PublicIP -p tcp –sport 8006 -j ACCEPT

    Je me retrouve maintenant coincé à la partie où l’on autorise l’accès à l’interface Proxmox seulement depuis le VPN. Impossible de me connecter à l’interface sur https://10.0.0.1:8006.
    Quelqu’un aurait une solution ?

    Merci.

  5. J’ai aussi remarqué que les règles iptables bloquent l’accès à la console NoVNC sur les containers.
    J’ai pas fais la règle pour accepter la connexion NoVNC mais ça peut être intéressant à rajouter au script.

  6. @Christian VDZ, en effet on parle bien des deux mêmes lignes.
    personnellement je n’ai pas retiré encore le 8006 de l’extérieur, car je reçois pas mal de DROP de paquets (enfin je supposes, diag en cours) en VPN si je me connecte en SSH à un container, je prends un « too many failed authentication » dès le premier essai sans même avoir le temps de taper un mot de passe.
    je reviendrais donner mes conclusions quand j’aurais trouvé tout ça

    actuellement je me bats avec les certificats HTTPs (SSL de let’s encrypt) car autant pour les ajouter à la console proxmox depuis la V6 c’est facile (dans l’interface web même si on veut), mais je n’arrive pas à avoir de certificats SSL fonctionnel sur mes services derrière le pfsense (mon cloud/un mattermost…)

  7. Bonjour à tous,

    Tout d’abord merci beaucoup pour ce magnifique travail très sincèrement, puis-je upgrader mon proxmox sans risque entre la Proxmox VE 5.4 – 13 en V6 sur un serveur dédier kimsufi ??

  8. @Fabulous Fab’s de mon côté j’ai résolu mon problème d’accès à l’interface Proxmox depuis le VPN avec la ligne suivante :
    iptables -A OUTPUT -o $PrxVmWanVBR -s $ProxVmWanIP -p tcp –sport 8006 -j ACCEPT

    j’ai pas encore pris le temps de faire les certificats
    et maintenant j’essaie de voir pourquoi j’ai autant de perte au niveau du débit (il est divisé par 10 entre l’hôte et les vm) et ça m’embête énormément..

    vous avez quoi qui tourne derrière le pare feu ? perso je me suis mis un reverse proxy nginx pour héberger quelques sites et du mail mais je trouve ça cher d’utiliser un dédié pour ça alors que je pourrais le faire avec 2/3 instances dev chez Scaleway alors j’hésite à garder mon serveur :/

  9. @Christian VDZ:
    Coucou, oui je penses que cette règle est nécessaire pour le VPN, bien trouvé!
    je fais les certificats parce que j’avais installé un mattermost sur mon ancien Proxmox, et en bidouillant trop les iptables et le pfsense (pour essayer de passer le client pour Let’s Encrypt au travers, il avait besoin du port 80) je me suis totalement locked-out du serveur, je me suis battu un moment puis j’ai trouvé cette mise à jour de tuto, j’ai donc décidé de réinstaller tout.
    ça m’a permis de retravailler tout, d’aborder plus intelligemment l’installation totale de mon infra perso et d’apprendre encore plus.
    Donc là je suis toujours sur l’installation et j’ai mis peu de service, mais voici les applis qui ont été installées sur mon proxmox perso (Start SATA chez online.net /scaleway : celui à 11€ / mois pour 1 To 4G de ram, oui c’est short) :
    -un pfSense (non sans déconner?!);
    -un NextCloud : ultra pratique, je l’ai déjà réinstallé celui là car j’ai un paquet de fichiers à réuploader dessus;
    -une seedbox, utile aussi, déjà réinstallé aussi car rapide à mettre en place;
    -un serveur IRC, là c’était pour me la jouer old-school-nerd, mais j’ai beaucoup appris quand même; notamment en y installant un bouncer. il a beaucoup servi pendant un an, bon entre-temps j’ai découvert Slack & TEAMS au travail et donc MatterMost (équivalent libre, un article sur mon blog en parle un peu si tu veux);
    -une VM cliente LinuxMint;
    -un kanka (voir kanka.io pour la mise à dispo d’éléments pour du JDR papier);
    -un invidio.us pour faire proxy à Youtube;
    -un jitsi-meet pour vidéochatter en privé;
    -un Lufi (cf FRAMADROP) pour le transfert de fichiers rapide et anonyme vers la famille;
    -un Lutim (cf FRAMAPIC) pour l’hébergement, le partage et surtout l’affichage (genre dans un forum) d’images de façon rapide, anonyme, perso…;
    -d’autres container pour l’essai, que je n’avais pas forcément gardé, je dois en oublier mais en vrac : openLDAP, un Tracks (remplacé depuis par un compte RTM pro, voir la méthode GTD, mais rien à voir), un WordPress pour le mariage d’un pote, un piwigo pour une photothèque privée, ….

    voilà, je m’en sers autant en prod que pour des tests, depuis que j’ai découvert les containers LXC il y a quelques années (bravo turnkey-linux!) je suis devenu gourmand en tests ! J’avais un proxmox à la maison avant, mais le débit minable de ma campagne m’empêchait de réellement m’en servir en prod.
    j’éspère que ça réponds bien à ta question.

    là maintenant j’essaye de poser donc le certificat SSL sur le nom de domaine et de l’héberger sur le proxy (un proxy dédié ou simplement le pfSense qui étant en Frontal fait effet similaire) afin que TOUTES mes applis soient protégées par le même certificat géré à un seul endroit…

  10. Bonjour,

    Merci pour cette article très intéressant qui m’a bien aidé.
    Je me suis arraché les cheveux à essayé de faire marcher mes VM avec mes 4 IP FO sans succès. Alors qu’avec des CT ça marche très bien. Certains diront peut être « bah utilise des CT à la place des VM » oui mais… pas de snapshot sur les CT (ou alors j’ai pas trouvé comment faire…).
    En parcourant le net je suis tombé sur ton article et j’ai trouvé l’idée d’utiliser PFSense très intéressante (surtout que je ne connais pas ce produit).
    Pour mon 1er essai, j’ai essayé avec une seul IP FO. Niveau config, pour le LAN j’ai fais un bridge comme décris dans ton article. Pour la Wan, j’ai gardé celui par défaut. Par contre j’ai attribué à la carte réseau de ma Vm la MAC que me donne OVH. Ensuite dans le menu « Set interface IP Address » de PFSense je lui renseigne l’IP FO ainsi que la GW (aussi fourni par OVH). Youpii ça marche.
    Je rajoute donc 2 autres cartes réseaux sur ma VM (pour utiliser 2 autres IP FO) et je me rends sur l’interface PFSense pour configurer tout ça… et la s’est le drame! On ne peut pas avoir plusieurs WAN avec la même GW… je ne vois pas comment faire pour contourner ce problème…

  11. Tres bonne serie mais là j’ai besoin d’aide. J’ai exactement la meme architecture que dans ce tuto. Je voudrai monter un share entre mon xpenology (192.168.9.51) et mon proxmox pour telecharger et stocker les iso ( il a une pate sur le LAN en 192.168.9.1 mais meme depuis une machine sur le lan je ne peu pas l’attaquer) mais impossible de monter mon NFS. Je ne sais pas ou cela bloc.
    Les idées sont les bien venu

    Merci
    Steph

  12. Bonjour à tous,

    En effet c’est un peu compliqué entre mis de l’ancien iptables et le nouveau, quelqu’un pourrai-t-il publier le ficher complet sans son ip public évidemment ^^

    Merci d’avance aux personnes participant à ce sujet, je pense que le problème est associé à la modification du port ssh

    Dans l’attente je vais essayer de reproduire ce script dans un shorewall

  13. Hello !

    Je passe pour répondre aux questions des commentaires précédents.

    En préambule, je précise que pour le script iptables, le mieux à faire est vraiment d’essayer de comprendre ce qui se passe plutôt que de tester d’ajouter/retirer des règles un peu au pif. C’est important parce que ce script est la première ligne de défense du serveur, donc on veut être sûr de bien le paramétrer. À la fin du tutorial, j’ai donné des outils qui permettent de débugger, notamment :
    – le sniffage de paquets
    – l’activation des logs dans les iptables

    @Fabulous Fab’s : Normalement autoriser les paquets 22/8006 en OUTPUT n’est pas nécessaire parce que la connexion est déjà établie (si on a bien ajouté les lignes RELATED,ESTABLISHED). Mais a priori je ne vois pas d’inconvénient à les autoriser non plus. Dans mon fichier iptables je n’ai PAS de règles SSH/8006 en OUTPUT.

    @zona : Tu cites la ligne que je demande d’enlever. La ligne est : « iptables -A OUTPUT -o $PrxVmWanVBR -s $ProxVmWanIP -p tcp –dport 22 -j ACCEPT ». Et tu as raison, c’est une coquille de ma part. Cette ligne fait référence à l’ouverture des ports depuis l’hyperviseur vers le WAN (c’est l’étape juste après la tête de Denis Brogniart pour te situer). Et la ligne que j’avais rajouté ne spécifie pas le port 22, donc c’est : « iptables -A OUTPUT -o $PrxVmWanVBR -s $ProxVmWanIP -p tcp -j ACCEPT ».

    @Christian : Tu peux nous en dire plus sur l’accès à la console NoVNC sur les containers ? Je n’ai pas du tout utilisé les containers de mon côté, et je ne suis pas sûr de bien saisir ce que tu veux dire. Quelle règle as-tu rajouté ?

    @Fabulous Fab’s : Pour les certificats TLS sur les services. Si le service est interne (accessible uniquement par VPN), déjà c’est moins important, puisque ta connexion vers le serveur est sécurisé par le VPN, et ensuite les paquets circulent en HTTP sur la machine virtuelle seulement. Mais on peut quand même générer un certificat manuellement via l’interface de PFSense (comme on a fait pour le VPN) puis ensuite l’attacher au service (cette étape dépend de la config du service en question). Vu que le certificat a une durée de 10 ans, cette manipulation n’est à faire qu’une fois. Et il faut rajouter le certificat de ta « Certificate Authority » sur ton navigateur/OS.

    Si le service est public, alors j’ai mis une VM avec un serveur nginx qui fait office de reverse proxy, et qui s’occupe de servir des certificats TLS. Ensuite, ça dialogue en HTTP entre la VM nginx et la VM du service.

    Et pour certains services, c’est les deux, et selon que tu y accèdes via le VPN ou en public, le certificat affiché sera pas le même, mais c’est transparent.

    @Christian : La règle que tu veux rajouter en OUTPUT pour accès depuis le VPN est cohérente par rapport aux règles que vous aviez besoin de rajouter précédemment. De nouveau, je n’en ai pas eu besoin, c’est un peu étrange.

    Pour la perte de débit, je n’en ai pas subit du tout, mais c’est un commentaire qui revenait parfois sur l’ancienne version du tuto.

    Pour les services qui tournent, perso pour l’instant j’ai un reverse proxy nginx, un RStudio Server (c’est un IDE pour faire du R), un Shiny Server, un MySQL, un Gitlab, un Gitlab Runner (pour CI/CD), et un site en Jekyll. J’ai pas mal d’autres services à déménager encore, mais ça çe prend un temps fou parce que j’essaie de déployer avec Ansible. Et puis j’ai un peu peur du déménagement du Nextcloud :D

    @brusezot : C’est bon de voir que la mise à jour s’est déroulée sans pépin ! Bravo o/

    Je peux remettre une version du script iptables, mais en regardant la version que j’ai actuellement en production, elle n’est pas très différente (les différences sont que j’ai ajouté l’ipv6 et j’ai ouvert quelques ports depuis l’hyperviseur pour exporter des backups avec borgbackup automatiquement).

  14. Voici mon iptables
    #!/bin/sh

    # ---------
    # VARIABLES
    # ---------

    Proxmox bridge holding Public IP

    PrxPubVBR= »vmbr0″

    Proxmox bridge on VmWanNET (PFSense WAN side)

    PrxVmWanVBR= »vmbr1″

    Proxmox bridge on PrivNET (PFSense LAN side)

    PrxVmPrivVBR= »vmbr2″

    Network/Mask of VmWanNET

    VmWanNET= »10.0.0.0/30″

    Network/Mmask of PrivNET

    PrivNET= »192.168.9.0/24″

    Network/Mmask of VpnNET

    VpnNET= »10.2.2.0/24″

    Public IP => Set your own

    PublicIP= »192.168.0.XX »
    ## Proxmox IP on the same network than PFSense WAN (VmWanNET)
    ProxVmWanIP= »10.0.0.1″

    Proxmox IP on the same network than VMs

    ProxVmPrivIP= »192.168.9.1″

    PFSense IP used by the firewall (inside VM)

    PfsVmWanIP= »10.0.0.2″

    # ---------------------
    # CLEAN ALL & DROP IPV6
    # ---------------------

    Delete all existing rules.

    iptables -F
    iptables -t nat -F
    iptables -t mangle -F
    iptables -X

    This policy does not handle IPv6 traffic except to drop it.

    ip6tables -P INPUT DROP
    ip6tables -P OUTPUT DROP
    ip6tables -P FORWARD DROP

    # --------------
    # DEFAULT POLICY
    # --------------

    Block ALL !

    iptables -P OUTPUT DROP
    iptables -P INPUT DROP
    iptables -P FORWARD DROP

    # ------
    # CHAINS
    # ------

    Creating chains

    iptables -N TCP
    iptables -N UDP

    UDP = ACCEPT / SEND TO THIS CHAIN

    iptables -A INPUT -p udp -m conntrack –ctstate NEW -j UDP

    TCP = ACCEPT / SEND TO THIS CHAIN

    iptables -A INPUT -p tcp –syn -m conntrack –ctstate NEW -j TCP

    # ------------
    # GLOBAL RULES
    # ------------

    Allow localhost

    iptables -A INPUT -i lo -j ACCEPT
    iptables -A OUTPUT -o lo -j ACCEPT

    Don’t break the current/active connections

    iptables -A INPUT -m conntrack –ctstate RELATED,ESTABLISHED -j ACCEPT
    iptables -A FORWARD -m conntrack –ctstate RELATED,ESTABLISHED -j ACCEPT

    Allow Ping – Comment this to return timeout to ping request

    iptables -A INPUT -p icmp –icmp-type 8 -m conntrack –ctstate NEW -j ACCEPT

    # --------------------
    # RULES FOR PrxPubVBR
    # --------------------

    INPUT RULES

    —————

    Allow SSH server

    iptables -A TCP -i $PrxPubVBR -d $PublicIP -p tcp –dport 22 -j ACCEPT

    Allow Proxmox WebUI

    #iptables -A TCP -i $PrxPubVBR -d $PublicIP -p tcp –dport 80 -j ACCEPT

    OUTPUT RULES

    —————

    Allow ping out

    iptables -A OUTPUT -p icmp -j ACCEPT

    Allow LAN to access internet

    iptables -A OUTPUT -o $PrxPubVBR -s $PfsVmWanIP -d $PublicIP -j ACCEPT

    Proxmox Host as CLIENT

    Allow SSH

    iptables -A OUTPUT -o $PrxPubVBR -s $PublicIP -p tcp –dport 22 -j ACCEPT

    Allow DNS

    iptables -A OUTPUT -o $PrxPubVBR -s $PublicIP -p udp –dport 53 -j ACCEPT

    Allow Whois

    iptables -A OUTPUT -o $PrxPubVBR -s $PublicIP -p tcp –dport 43 -j ACCEPT

    Allow HTTP/HTTPS

    iptables -A OUTPUT -o $PrxPubVBR -s $PublicIP -p tcp –dport 80 -j ACCEPT
    iptables -A OUTPUT -o $PrxPubVBR -s $PublicIP -p tcp –dport 443 -j ACCEPT

    Proxmox Host as SERVER

    Allow SSH

    iptables -A OUTPUT -o $PrxPubVBR -s $PublicIP -p tcp –sport 22 -j ACCEPT

    Allow PROXMOX WebUI

    iptables -A OUTPUT -o $PrxPubVBR -s $PublicIP -p tcp –sport 8006 -j ACCEPT

    FORWARD RULES

    —————-

    Allow request forwarding to PFSense WAN interface

    iptables -A FORWARD -i $PrxPubVBR -d $PfsVmWanIP -o $PrxVmWanVBR -p tcp -j ACCEPT
    iptables -A FORWARD -i $PrxPubVBR -d $PfsVmWanIP -o $PrxVmWanVBR -p udp -j ACCEPT

    Allow request forwarding from LAN

    iptables -A FORWARD -i $PrxVmWanVBR -s $VmWanNET -j ACCEPT

    MASQUERADE MANDATORY

    Allow WAN network (PFSense) to use vmbr0 public adress to go out

    iptables -t nat -A POSTROUTING -s $VmWanNET -o $PrxPubVBR -j MASQUERADE

    Redirect (NAT) traffic from internet

    All tcp to PFSense WAN except 22, 8006

    iptables -A PREROUTING -t nat -i $PrxPubVBR -p tcp –match multiport ! –dports 22 -j DNAT –to $PfsVmWanIP

    All udp to PFSense WAN

    iptables -A PREROUTING -t nat -i $PrxPubVBR -p udp -j DNAT –to $PfsVmWanIP

    # ----------------------
    # RULES FOR PrxVmWanVBR
    # ----------------------

    INPUT RULES

    —————

    SSH (Server)

    iptables -A TCP -i $PrxVmWanVBR -d $ProxVmWanIP -p tcp –dport 22 -j ACCEPT

    Proxmox WebUI (Server)

    iptables -A TCP -i $PrxVmWanVBR -d $ProxVmWanIP -p tcp –dport 8006 -j ACCEPT

    OUTPUT RULES

    —————

    Allow SSH server

    iptables -A OUTPUT -o $PrxVmWanVBR -s $ProxVmWanIP -p tcp –sport 22 -j ACCEPT

    Allow PROXMOX WebUI on Public Interface from Internet

    iptables -A OUTPUT -o $PrxVmWanVBR -s $ProxVmWanIP -p tcp –sport 8006 -j ACCEPT

    # -----------------------
    # RULES FOR PrxVmPrivVBR
    # -----------------------

    NO RULES => All blocked !!!

    iptables -A TCP -i $PrxVmWanVBR -d $ProxVmWanIP -p tcp –dport 8006 -j ACCEPT

    service fail2ban restart

  15. @Charles Salut ! Lorsque j’essaie d’accéder à la console NoVNC d’un container depuis la GUI de Proxmox ça me plantait toute l’interface pendant quelques secondes et je n’avais pas accès à la console. Je me suis pas encore penché sur le problème parce que comme toi j’ai plutôt utilisé des VM.

    Ensuite au niveau du débit j’ai de très grosses pertes, j’ai une seedbox transmission qui tourne à environ 90Mbit/s en download alors que mon hyperviseur est tourne autour de 1200Mbit/s en down. Je sais pas d’où provient cette perte..
    De plus, lorsque j’ai de fortes charges réseau sur la seedbox il arrive que PfSense plante complètement. Je perds alors l’accès au VPN et je suis forcé à redémarrer la VM en SSH.

    @Fabulous Fab’s je vois t’as mis pas mal de services derrière ! ton serveur en galère pas trop ?

  16. Merci pour ces excellents tutos! Clair et présenté avec humour.

    Bon j’en suis arrivé à bout et j’ai quasiment tout fonctionnel, cad:
    – vpn ok.
    – ssh depuis client vpn vers proxmox ok.
    – interface sur 8006 proxmox accessible depuis mon client vpn ok.
    – reboot et resilience des iptables ok.

    Sauf que…
    La proxmox n’accède plus à internet.
    Depuis la session ssh proxmox un ping google.com = Operation not permitted.
    Depuis l’interface impossible de loader les mises à jours.

    Auriez-vous une idée?

    Merci

  17. @Everybody, pour info est-ce normal que lorsque l’on fait un ping vers google.fr depuis la CLI du proxmox on obtient ceci :

    ping: google.fr: Échec temporaire dans la résolution du nom

  18. Bonjour,

    Je m’auto réponds sur le sujet.
    Rien à changer du côté de iptable and co…

    Si vous prenez une conf chez Hetzner en raid 1 proxmox non supporté…(c’est peut être valable pour du disque simple et d’ailleurs je ne vois pas pourquoi cela ne le serait pas) alors l’install ne fait pas de resize du disque pour prendre l’espace restant.

    Bref, il faut surveiller ses basiques et celui-ci en fait partie. Car sinon vous vous retrouvez avec un disque plein très rapidement et tout se met à dérailler tranquillement.

    Dans ma configuration précise, difficile de généraliser là, j’ai fait dans l’ordre:

    Pour comprendre les dégats:

    df -h

    fdisk -l |grep -i Disk

    Pour étendre:

    lvextend /dev/mapper/vg0-root /dev/md1

    Pour vérifier:

    fsck -nv /dev/mapper/vg0-root

    Pour étendre le filesystem:

    resize2fs -F /dev/mapper/vg0-root

    Pour regarder le résultat:

    df -h

    Je ne suis pas un as des explications comme l’équipe qui s’occupe de ce blog, mais j’espère que cela pourra aider.

    Merci

  19. Bonjour à tous,

    Je réponds à mon propre commentaire concernant le problème de ping ipv6

    Pour reprendre le message d’un certain @Krickk de l’ancien tuto Proxmox VE 5 :

    «  » » » » » » » » » » » » »
    Salut à tous,

    D’abord, merci pour ce tuto vraiment pas mal détaillé.

    J’ai juste un petit commentaire à faire :
    Si comme moi après l’application du script pour l’iptables (à faire sur proxmox), vous ne parvenez plus a résoudre des URL, que ce soit avec apt ou ping ou wget, il faut désactiver l’IPv6 comme ceci en root :
    sysctl -w net.ipv6.conf.all.disable_ipv6=1
    sysctl -w net.ipv6.conf.default.disable_ipv6=1

    Une fois OK, vous pourrez a nouveau résoudre des adresses DNS :)

    Bonne journée ;)

    «  » » » » » » » » » » » » » »

    Merci encore à lui pour cette découverte

  20. Bonjour à tous et bravo pour ce super tuto très détaillé.
    En ce qui me concerne, à chaque fois que j’exécutais le script iptables, je me faisais dégager (mon lien ssh et ma connexion web 8006 étaient rejetés). Je n’arrivais pas à comprendre pourquoi.
    Et puis j’ai commencé à épluché des tuto de base sur iptables. Et là, déclic quand j’ai lu la chose suivante :
    « Starting with Debian Buster, nf_tables is the default backend when using iptables, by means of the iptables-nft layer (i.e, using iptables syntax with the nf_tables kernel subsystem). This also affects ip6tables, arptables and ebtables. You can switch back and forth between iptables-nft and iptables-legacy by means of update-alternatives (same applies to arptables and ebtables).  »
    Ben oui, je pense que la dernière mouture de proxmox est bâtie sur debian 10. Du coup j’ai testé iptables en mode « lagacy », et miracle, je ne me suis plus fait jeté. Donc, si ça peut servir voici les commandes pour passer iptables en mode legacy :

    update-alternatives –set iptables /usr/sbin/iptables-legacy

    update-alternatives –set ip6tables /usr/sbin/ip6tables-legacy

    update-alternatives –set arptables /usr/sbin/arptables-legacy

    update-alternatives –set ebtables /usr/sbin/ebtables-legacy

    Bon courage à tous en cette période difficile.
    * confirmation : sur le site officiel de proxmox il est écrit : « The new version of Proxmox VE (6.1) is based on Debian Buster (10.2)

  21. Bonsoir à tous.
    Merci pour ce super tuto.
    Pour ma part j’ai juste un petit problème, c’est que les vm mettent une plombe avant d’avoir accès à internet.
    En fait quand je redémarre une VM, elle n’a même pas accès au pfsense. au début j’ai cru avoir merdé dans la config. Je me suis dit que j’allais faire une pose et en revenant devant mon pc, la vm avait soudain accès au pfsense et donc à internet.
    Pour en avoir le coeur net, je l’ai relancé et idem, plus de réseau… J’ai attendu un long moment, sans rien toucher et soudain le réseau est de nouveau accessible.
    Le phénomène se produit pour toute les vm sans exception.
    J’ai repris tout depuis le début mais rien à faire, même phénomène. J’ai essayé les cartes VirtIO et Intel, réinstaller pfsense, réinstaller/créer de nouvelles vm, toujours pareil.
    Le ping ne répond ni de la vm vers le pfsense ni du pfsense vers la vm. :-(
    Puis soudain tout se met à répondre parfaitement avec des débits nickels (Nperf à l’appui)
    Une idée? Je n’ai pas chronométré mais le temps d’attente est toujours le même à priori…. environ 15/20 minutes.
    Merci de vos lumières!
    Pour la config, serveur SoYouStart avec une seul carte réseau.

    Stef

    1. Ça c’est super bizarre…
      Un problème de routage mais qui se résoudrait tout seul au bout d’un certain temps ?

      J’ai vu qu’il y avait beaucoup de choses dans les commentaires, je pense louer un serveur pour un mois pour dérouler le tuto complet et faire d’éventuelles adaptations en fonction de ce que les gens disent dans les commentaires justement.
      Peut-être que je tomberai dessus aussi ?

  22. Salut déjà merci pour ton tuto tout marche super (sauf la partie iptables) perso j’ai récupérer l’iptables de ton ancien tuto et ça à marcher nickel

    j’aurait une demande à te faire es que suivant ce tuto tu pourrait montrer comment mettre en place une dmz ? le problème c’est que ci quelle un à accès a une vm bah il tombe sur tout ton réseaux :-/

    ou si ta une solution pour isolé chaque vm est qui rendu public ?
    Voilà je te remercie par avance.

  23. Bonjour
    J’ai toujours mon problème de partage sur mon lan :
    impossible d’acceder à proxmox depuis une VM dans le LAN et du coup impossible de faire un partage NFS entre mon Xpnology et Proxmox, plutot embêtant vu que mes iso sont sur le NAS. J’aurais vraiement besoin d’une solution . Sinon le reste c’est parfait.

    Gasper

  24. Hello,
    Après 2 installations avec succès suite à ta méthode très bien faite, je souhaite passer sur ansible.
    Sysadmin ansible, je serais partisan d’initier toutes ces etapes pour une installation sur un serveur dédié.
    Comme j’ai lu que tu utilises ansible, que penses-tu de cette initiative?
    Le code serait bien sûr disponible sur un gît.

    1. Dans l’absolu moi, je suis forcément d’accord !

      Après, est ce qu’on pourra TOUT automatiser avec Ansible ?

      Les scripts et la configuration du serveur + création des users, facile, j’ai déjà bossé dessus en partie sur github.com/zwindler/ansible-proxmoxve. Les créations de VMs, ça devrait le faire. La configuration du pfsense, je savais pas qu’il y avait des modules pour ça mais a priori oui (et on a des exemples ici).

      Cool :)

      Si tu veux qu’on en parle ensemble, contacte moi sur l’email renseigné dans les mentions légales du site

  25. Hello !
    Merci pour ce tuto, très détaillé !
    Tout fonctionne de mon côté mais je bloque sur un point :
    je me connecte sur mon LAN à une machine virtuelle (sur proxmox of course !) en SSH (IP-A). Sur cette machine, je créé un tunnel VPN vers mon pfsense. Je ping le réseau 192.168.9.0 et vois bien ma machine IP-A dans les logs OpenVPN de pfsense.
    Par contre, j’ai perdu ma connexion SSH et je dois entrer mes commandes de ping depuis le shell de Proxmox !
    Comment avoir d’un côté ma connexion SSH ouverte depuis mon PC perso vers ma VM (IP-A) et en même temps cette machine VM (IP-A) connecté au tunnel VPN ?

  26. Super tuto, j’ai profité du confinement pour m’y mettre et tout va plutôt bien dans le déroulement !
    pour que ca continue comme çà je préfère poser cette petite question :
    dans ton point
    Host Name Resolution : Other – et on renseigne l’IP publique de notre serveur : je pense partir sur la PUBIP ?

    merci pour ton aide et bonne reprise !

  27. hello !
    ca avance mais je vais avoir une nouvelle question
    chap : Note de zwindler : On préfèrera plutôt ajouter une règle similaire à la précédente qui autorise 10.0.0.1 à accéder à 192.168.9.254 sur le port 443. Ceci nous permettra de refaire marcher notre tunnel SSH (qui ne marche plus depuis qu’on a ajouté la route en tout début de ce 2ème article) pour avoir la console pfsense en local sur votre machine Linux ou Windows.
    => j’ai bien créé la règle sous pfsense mais oups je n’arrive pas à me connecter ou ne vois pas encore ce qu’elle permet… (à ce stade mais je continue le tuto)
    bon we!

  28. bon à ce stade j’ai réussi à contourner en modifiant la rule :
    Note de zwindler : On préfèrera plutôt ajouter une règle similaire à la précédente qui autorise 10.0.0.1 à accéder à 192.168.9.254 sur le port 443
    ce que j’ai fait :
    en pass/wan/ipv4/TCP/source : mon ip « vraie » PC/ destination 10.0.0.2 sur le 443 en destination
    et ca marche : je suis content mais je ne suis pas sur de ce que j’ai fait ;o) question de neophyte la valeur aprés le / de l’IP permet d’ouvrir et restreindre les IP concernée ? si on met rien c’est 1 ?
    beaucoup de question, I know.
    ca marchouille en tout cas mais avec un blocage HTTP_REFERER contournable dans l’interface mais je ne sais pas trop si c’est à faire..
    sinon autre question : j’ai essayé le VPN depuis mon PC principal sous windows 10 en installant le VPN client et important le fichier de config : mais ca ne marche pas. juste pour retour d’EXP. j’espère ne pas polluer ton blog

  29. Bonjour,

    Tout d’abord merci pour cette mise à jour !

    J’ai effectué pas mal de tests mais impossible de trouver une solution alors je poste ici mon problème, que certains ont peut-être également (eu) ?
    J’ai suivi toutes les étapes, mes VMs fonctionnent parfaitement, elles peuvent accéder à internet, internet peut accéder également à ces machines, cependant les machines virtuelles, pfsense et mon hôte proxmox ne peut pas accéder aux services sur sa propre adresse IP.
    Pour info, j’ai choisi le subnet 172.16.0.1/24 plutôt que 192.168.9.1/24. (J’ai adapté tout ce qu’il fallait évidemment)

    Pour être plus précis, lorsque je fais un « curl http://mon_ip_publique« , ce dernier ne se résoud jamais
    Trace d’un curl en mode verbose :
    https://pastebin.com/YvjTxx7D

    J’ai essayé de regarder les logs de pfsense, de sniffer le réseau avec tcpdump sur le pfsense et l’hôte, de mettre des LOG dans les règles iptables mais impossible de trouver la provenance du problème…

    Le résultat d’un traceroute me donne ceci :
    https://pastebin.com/6KfakDkD

    Du coup je pense que le problème vient de ma pfsense ou des règles iptables de la machine proxmox (qui sont les même que celles du tutoriel). Par contre, je peux ping mon ip publique depuis les machines sur mon LAN.

    Est-ce que vous arrivez à accéder aux services sur votre IP publique depuis les machines de votre LAN ?

    Comme solution je pourrais utiliser les adresses ip locales (du subnet 172.16.0.1/24) avec les ports des services plutôt que de passer par des noms de domaines mais c’est pas vraiment idéal comme solution… (Si je veux déplacer un service sur un VPS par exemple, je vais devoir reconfigurer entièrement le service avec les bonnes informations)

    Du coup voilà, je manque de pistes de réflexions, je n’ai plus aucune idée pour essayer de résoudre le problème.

    Merci d’avance !

  30. Bonjour,
    un grand merci pour ce tuto, plutôt habitué à HyperV et un peu ESXi je suis bien content de vous avoir trouvé pour faire mes premières armes sur ProxMox.

    j’héberge des services voix, qui souffrent beaucoup de tout ‘délais’.

    du coup je souhaite gérer un pool de VMs ‘à côté’ du PFSense, c’est à dire que gros
    – 1 IP pour ProxMox host (8006 & 22) & le PFSENSE (et donc toutes les VMs derrière)
    – 1 IP Pub pour chaque VM VOIX

    Est-ce que intellectuellement ca vous choque ?
    En gros l’idée est de dire : les perf seront meilleur en directe que via la surcouche pfsense, si le PFSense tombe les VM Voix ne sont pas impactées.
    Ca veut peut-être dire qu’il faut activer le parefeu sur ProxMox .. ca peut cohabiter avec la conf actuelle ?
    Point bonus : je veux isoler les VM ‘derrière’ le pfsense les unes des autres, du coup il faut jouer du vlan ?

    voila, mon message n’attend pas forcément de réponse, c’est plus une bouteille à la mer, je suis convaincu que je ne suis pas le seul à imaginer ce genre d’infra, autant partager les idées, expériences, on est la pour ca après tout.

    ps : @Christian VDZ : j’ai eu le même pb de débit catastrophique, tout est ok depuis que j’ai désactivé le Hardware Offload pfsense comme évoqué à la fin du tuto.

    bonne continuation.

  31. Bonjour,
    me revoilà avec mes questions de débutant ! promis j’ai lu et relu avant de la poser
    bravo encore pour la démarche et le tuto.
    tout fonctionne comme tu l’indiques : c’est à dire acces ou pas acces avec/sans la vpn comme ton check l’indiques.
    Tout …sauf l’accés SSH aux Vm : si je retire la regle du FireWall ca ne marche plus, je la remets ca marche… mystère, et pour l’instant pas bloquant dans la démarche.
    et puis cette question qui trotte : est ce que je peux utiliser ce FW pfSense en amont des autres laptop actuellement connecté au routeur principal, un vieux R7000 sur une plage d’IP « Publique » en forcant l’IP fixe et la passerelle : petit test raté, j’ai peut être ma réponse mais vos avis ou conseil me serait utile pour aller plus loin : faut il que je fasse sauter mon routeur R7000 ou que je l’utilise différemment (il m’est nécessaire à la bonne diffusion du wifi). (peut être via un autre VPN ?) voilà pour ma question du soir ! Espoir…

  32. Super article, c’est cool.
    Par contre je comprend que c’est marrant les partie fun. Mais c’est super relou quand tu fais ta config en meme temps.
    Quand tu dis tu peux tester ton vpn. Je teste moi.
    Et juste après tu dis a en faite non…. C’est marrant, mais c’est super relou, moi en attendant j’ai perdu ma console, mon pfsense faut que je relance tout.
    Je me souviens plus mais tu m’as deja fait le coup plusieurs fois deja. lol
    Mais merci énormément !

  33. J’ajouterais que les partie concernant la protection de l’interface web du Proxmox devraient etre au debut, comme sur l’article originale :)

  34. bonjour, j’ai finis le tuto et il est tres bien detaille et explique, j’en suis a installe mes services mais j’ai un probleme avec le vpn. j’arrive a me connecter mais au bouts d’un moments je suis deco et j’ai ca dans les logs :
    [X.X.X.X] Inactivity timeout (–ping-restart), restarting

    impossible de me reconnecter je suis obliger de redemarrer ma VM pfsense quelqu’un a une idee pour regle le probleme ? merci d’avance

  35. Bonjour,

    Tout d’abord merci pour ce super blog et ces articles de qualité ! :)
    J’utilise cette architecture depuis la première version.
    Après avoir suivi un cours sur Ansible, je me demande comment faire pour automatiser cette installation.
    L’idée serai de pouvoir déployer cette infrastructure sur un serveur dédié fraichement loué.
    Malheureusement beaucoup de tâches ne me semble pas automatisables, notamment la configuration de pfSense.

    Je serai heureux de pouvoir en discuter avec quelqu’un qui aurait creusé le sujet ou qui serai intéressé par l’automatisation d’une telle installation :D

  36. Hello la compagnie, je tiens à tous vous remercier pour cette magnifique série concernant proxmox. C’est un travail fabuleux. Je me suis amusé à monter un petit serveur proxmox à mon domicile. Histoire de m’amuser un peu. Cependant, j’ai un souci avec la partie VPN. Celui-ci est fonctionnel mais impossible de me connecter dessus. Evidemment, la connexion au VPN fonctionne à partir d’une VM sur proxmox (normal). En revanche, ça ne fonctionne pas quand je veux établir une connexion depuis un PC (client GNU/Linux) qui est sur le même réseau que le serveur proxmox. Par ailleurs, j’ai fait des petites recherches. J’ai une erreur lors de la tentative de connexion: » TLS Error: TLS handshake failed ». J’imagine que le problème vient des règles du pare-feu sur pfsense. Mais, je n’arrive pas à trouver une solution. J’ai bien suivi le tuto. Tout fonctionne sauf cette partie. Quelqu’un aurait une suggestion ? :)

  37. salut vraiment très bon tuto mais j’ai un problème qui me ronge depuis plus d’un mois.
    en effet j’ai un serveur physique avec deux cartes réseaux ( WAN et LAN). j’ai suivi le tuto a la lettre mais le problème est que lorsque je lance les scripts j’arrive pas a accédé à l’interface de proxmox à partir du LAN, mais au niveau du WAN c’est possible avec IP public. besoin aide merci.

  38. Bonjour a tous , super tuto qui correspond exactement a ce que je recherche .
    Je vous decrit ma config actuelle , une machine dell precision T3500 avec 20 Go de RAM 4 To sur 2 disque .
    Fournisseur d’acces internet , box orange .
    Pour ne pas etre bridé j’ai mis l’ip de mon proxmox dans la DMZ de ma livebox .
    Mon probleme :
    tout ce deroule correctement , cependant lorsque je souhaite router le traffic vers la pfsense apres avoir creer le pfsense-route.sh . j’execute le script . mais le ping de l’hyperviseur est toujours accessible .
    Pouvez vous m’aider .
    Par avance merci

  39. Bonjour,

    Merci pour ce tuto fort intéressant. Je suis en train de monter un serveur et je bloque à l’étape de la mise en places des règles iptables. J’ai crée le fichier /root/iptables.sh mais quand je tente de l’exécuter j’ai une série d’erreur iptables: not found, avez-vous eu ce problème ? Merci par avance

    Sylv1

    1. Essai, dans ton fichier iptables.sh, de mettre dès le début :
      export PATH=$PATH:/usr/sbin # Pour que les commandes iptables fonctionnent !

      c’est probablement que dans ta distribution le binaire d’iptables ne se trouve pas dans /usr/bin mais dans /usr/sbin…

      En espérant t’avoir aidé…

  40. Merci infiniment pour ce tuto indispensable! Grâce à toi j’ai pu monter l’infra de notre startup. Sans ce tuto je ne pense pas que j’aurais pu installer pfSense et configurer NetFilter.
    D’ailleurs pour info j’ai été obligé de garder cette ligne :
    iptables -A OUTPUT -o $PrxVmWanVBR -s $ProxVmWanIP -p tcp -j ACCEPT

  41. Bonjour,
    J’ai un grand mystère qui m’a fait ramer pas mal de temps : j’avais déjà l’expérience d’un proxmox 5 monté avec l’ancien tuto qui tournait très bien et sur lequel je n’avais pas changé le port ssh. je me relance dans une install sur un nouveau serveur avec Proxmox 6 et ce nouveau tuto, cette fois je change le port ssh en 20141, tout va bien jusqu’au script iptables, dés que je le lance je perds toutes les connexions au serveur (ssh et https), reset hard obligatoire…
    J’ai testé des tas de trucs (y compris reinstall complète) avec le « nouveau » script et l’ancien (qui a marché 2 ans sans problème sur mon autre config) sans succès…
    En désespoir de cause je remets le ssh en port 22 pour pouvoir reprendre mon ancien script à l’identique, et la ça marche ! Je teste avec le nouveau script toujours ssh en 22 ça marche toujours, je remets mon ssh en 20141 et ça replante méchant.
    Bon je me dit je vais suivre le tuto à la lettre et je mets le ssh en port 22153 et la ça marche et avec les deux versions de scripts !
    Si je reviens en 20141 ça replante…
    Alors bon, ça marche en 22153, mais quand meme, si quelqu’un a une piste d’explication je suis preneur, je n’aime pas trop rester sur un mystere comme ça.
    J’ai fouillé un peu partout, le port 20141 est indiqué « Unassigned », je ne comprends pas…

  42. Bonjour,

    J’ai une petite question qui peu paraître assez idiote mais je préfère la poser avant de taper dans les Iptables
    Jusque là le tuto ne m’a posé aucun problème et pour le coup chapeau

    Mais a mon arrivé sur les IPtables je suis confronté à un dilemme :
    De ce que j’ai compris on modifie les iptables du pfsense.
    Le problème étant (si j’ai pas louper une section) qu’on ne s’est pas connecté en ssh directement au PFSense et que les interfaces noVNC ne permettent pas le copier/coller (en tout cas chez moi).
    Du coup je me dit que les iptables sont a appliquer à l’hyperviseur mais si c’est le cas, a quoi bon avoir installer une VM pfsense

    Voilà mon dilemme, si vous avez une réponse je suis preneur

    Cordialement

    1. Bonjour Thomas DV,
      je ne suis pas le plus légitime pour te répondre mais comme j’ai 5min…
      Tu ne modifies pas l’iptable de la pfSense mais l’iptable de l’hyperviseur. Ces règles iptables autorisent certains comportement et interdisent tous les autres, en particulier elles permettent de rediriger les flux vers pfSense.
      C’est ensuite dans pfSense qu’on va pouvoir, simplement, gérer les règles de pare-feu selon les besoins.
      Tu dois donc te connecter en SSH à l’hyperviseur pour paramétrer ses iptables puis en WebUI sur la pfSense pour paraméter les règles de pare-feu (le VPN, etc).
      En espérant t’avoir éclairé. Bonne continuation.

  43. Bonjour,

    Merci pour ce super tuto, tout fonctionne au poil mais j’aurais aimé avoir la possibilité de me connecter en SSH depuis mon serveur dédié vers mon NAS Synology à la maison pour faire des backups des VM mais ça ne passe pas, y’a t-il une règle à ajouter ?
    Merci par avance pour vos réponses
    Sylv1

  44. Bonsoir, je me permets de vous demander de l’aide car je bloque depuis plusieurs jours sur le script « iptables.sh ». J’ai suivi un tuto similaire pour l’installation d’un proxmox 5.4 sur un kimsufi. J’ai pris un nouveau serveur Kimsufi KS-11 pour faire une nouvelle installation directement en 6.2. mais à chaque fois que je lance le script , je me coupe ma session SSH l’interface du proxmox est ko, seul le ping sur l’IP public fonctionne encore. Obligé de faire un reboot depuis mon interface de gestion …
    Si quelqu’un à une idée je suis preneur merci pour votre aide.

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.