Quels ports VPN ouvrir sur un pare-feu : protocole par protocole

Deux règles distinctes décident si un tunnel VPN survit à un pare-feu : le port que le client appelle et le protocole qui transporte la charge utile. N'ouvrez que la première et le tunnel s'authentifie, puis ne déplace plus aucune donnée. Le minimum est un port TCP plus GRE pour PPTP, deux ports UDP plus ESP pour L2TP/IPsec et IKEv2, et un seul port pour SSTP, OpenVPN et WireGuard. Le sens, le suivi d'état et le NAT décident du reste.

Partez du port que le client appelle

Chaque famille a un point d'entrée que le client contacte en premier, et c'est ce point d'entrée que votre règle d'autorisation doit nommer. Les clients PPTP se connectent à TCP 1723. L2TP/IPsec lance IKE sur UDP 500 et passe à UDP 4500 dès que la traversée NAT est utilisée, la trame L2TP elle-même étant sur UDP 1701 à l'intérieur du tunnel. SSTP enveloppe la session dans TLS sur TCP 443, IKEv2 négocie sur UDP 500 et 4500, OpenVPN utilise UDP 1194 par défaut mais est souvent déplacé vers TCP 443, et WireGuard écoute sur UDP 51820.

Traitez ces numéros comme des valeurs par défaut et non comme des propriétés fixes. Une interface WireGuard utilise le port d'écoute que sa configuration déclare, et un serveur OpenVPN peut se trouver sur n'importe quel port choisi par l'administrateur. Lisez la configuration du serveur avant d'écrire la règle, car un pare-feu ouvert pour 1194 ne fait rien pour un serveur déplacé vers 443.

La troisième colonne est l'endroit où la plupart des tickets de changement tournent mal. La règle existe, mais elle pointe vers la mauvaise destination, le mauvais sens ou le mauvais transport.

GRE et ESP sont des numéros de protocole, pas des ports

GRE et ESP n'ont aucun port, donc un formulaire de pare-feu qui n'accepte que des numéros de port ne peut pas les exprimer. GRE est le protocole IP 47 et ESP le protocole IP 50, tous deux mis en correspondance via le champ protocole de l'en-tête IP. Une règle écrite comme port TCP 47 ne correspond à rien, et c'est ainsi qu'une politique PPTP paraît correcte et laisse quand même tomber chaque paquet après la poignée de main.

Les routeurs grand public cachent cela derrière une case de transit qui installe la règle de protocole et, pour GRE, l'assistant NAT nécessaire pour cartographier le flux. Sur un vrai pare-feu vous ajoutez le protocole vous-même : autorisez le protocole IP 47 vers le serveur PPTP, autorisez le protocole IP 50 vers la passerelle IPsec. Là où la plateforme n'offre pas de champ protocole, l'encapsulation est la sortie, c'est pourquoi IKEv2 peut retomber sur UDP 4500 et pourquoi OpenVPN et WireGuard ne rencontrent jamais le problème.

Vérifiez à quoi la règle correspond réellement avant de blâmer le client. Un compteur de paquets qui reste à zéro sur la passerelle dit que la règle n'a jamais été déclenchée, et aucune réinstallation côté client n'y change rien.

Le sens, l'état et le NAT changent la réponse

Un client qui appelle vers l'extérieur et une passerelle qui écoute vers l'intérieur sont des exigences différentes, et la même liste de ports peut être correcte dans un sens et fausse dans l'autre. Un pare-feu à états suit le flux UDP sur 500 et 4500 et laisse revenir les réponses sans seconde règle. ESP et GRE ne portent aucun port, donc un équipement NAT n'a rien à quoi s'accrocher et a besoin d'un assistant ou d'une encapsulation pour suivre la session.

La traversée NAT est la partie qu'on oublie. IKEv2 commence sur UDP 500, détecte un équipement NAT et continue sur UDP 4500, donc une politique qui n'autorise que 500 donne un tunnel qui s'établit puis se tait. L2TP/IPsec fait le même mouvement. Si votre capture montre le premier échange mais pas de trafic soutenu, cherchez une règle qui s'arrête à 500.

Notez le sens avec chaque règle. « Autoriser UDP 4500 » ne veut rien dire tant que vous ne dites pas d'où vers où, et une règle correcte pour un client itinérant est généralement fausse pour un pair site à site.

Vérifiez chaque chemin avec une capture

Lancez la capture sur la passerelle, pas sur le client : un client n'enregistre que ce qui est arrivé. Ces filtres couvrent les familles ci-dessus et montrent quelle étape manque :

sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50

Lisez la sortie comme une séquence. Quand la négociation apparaît mais pas le protocole de charge, la perte se produit quelque part entre le client et la passerelle. Quand les deux apparaissent et que la page échoue encore, le pare-feu n'est plus le suspect ; regardez le routage, le DNS ou le pool d'adresses remis au client.

Sur une machine sans tcpdump, les mêmes preuves viennent des compteurs d'interface et de règles. Des octets qui entrent mais ne sortent pas sur l'interface du tunnel indiquent le chemin de retour plutôt que la règle d'autorisation initiale.

Laissez un jeu de règles que vous pouvez défendre

SSTP sur TCP 443 est indiscernable d'un HTTPS ordinaire pour tout filtre basé sur les ports, et c'est justement l'intérêt quand un réseau n'autorise que le trafic web. C'est aussi pourquoi la règle du 443 doit nommer la passerelle comme destination plutôt que tout Internet. Supprimez les règles temporaires de n'importe-quoi-vers-n'importe-quoi dès que le tunnel fonctionne. Notez quelle règle a correspondu, le numéro de protocole là où il y en a un, et le sens, pour que la personne suivante parte de preuves.

Les passerelles cloud de point à site rendent le choix visible : le profil téléchargé utilise soit SSTP sur 443, soit IKEv2 sur 500 et 4500, et vous ne devez ouvrir que celui que le profil choisit réellement. PPTP ne vaut pas l'exception GRE sur un réseau moderne, car les opérateurs mobiles abandonnent souvent le protocole 47 quel que soit votre pare-feu. Avant de fermer le ticket, confirmez que la règle correspond au port de la configuration du serveur, que le champ protocole est défini là où la famille en a besoin et que la destination est la passerelle et non n'importe quelle adresse.