pfSense OpenVPN : atteindre un réseau derrière un autre routeur

Votre ordinateur portable atteint le LAN pfSense via le VPN et n’arrive toujours pas à joindre un service deux sauts plus loin, et la différence tient à une décision de routage par propriétaire. Trois équipements doivent s’accorder avant qu’un paquet termine son aller-retour : le client, le pare-feu et le routeur qui possède réellement le réseau de destination. Qu’il en manque un seul et le symptôme semble identique.

Suivez un paquet à travers ces trois décisions avant de changer une règle, car chaque propriétaire a un contrôle différent et un mode de défaillance différent.

Un paquet, trois décisions de routage

Le client décide si la destination appartient au tunnel, et il ne peut décider qu’à partir de ce qu’il sait : une route poussée, une route locale ou une route par défaut qui couvre déjà tout. pfSense décide où envoyer le paquet ensuite, ce qui, pour un réseau derrière un autre routeur, signifie une route statique via une passerelle joignable sur la bonne interface. Le routeur en aval décide s’il connaît un chemin de retour vers le pool VPN, et s’il ne le connaît pas, la réponse est abandonnée ou envoyée ailleurs inutilement. Chaque décision est indépendante des deux autres.

La défaillance de l’une d’elles produit le même rapport utilisateur. C’est pourquoi l’ordre de débogage compte plus que les outils.

Donnez au client un préfixe, pas une supposition

Sur un serveur pfSense SSL/TLS dont le réseau de tunnel IPv4 est plus grand qu’un /30, le champ IPv4 Local network(s) distribue des routes aux clients lors de la connexion. Ajoutez-y le préfixe aval au lieu de compter sur le client pour en inventer un. Lisez ensuite la table réelle du client après connexion, car un profil avec route-nopull ou un filtre de routes peut ignorer ce que le serveur a envoyé. Le serveur peut être parfaitement correct pendant que le client n’installe rien.

D’autres modes de serveur et topologies ont des limites différentes, et une politique par client ou par connexion peut modifier ce que reçoit un client donné. Vérifiez sur le client qui compte, pas sur celui que vous avez testé en premier par hasard.

Pointez pfSense vers le routeur interne

Une route statique dans pfSense exige une passerelle définie et joignable, et l’interface choisie pour cette passerelle doit être celle qui l’atteint réellement, comme le décrit le guide des routes statiques de Netgate. Dans une disposition illustrative, le lien de transit est 192.168.77.1 sur le pare-feu et 192.168.77.2 sur le routeur interne, le réseau de services étant en 172.16.30.0/25 derrière. La route nomme alors le préfixe et le prochain saut, pas l’adresse du service. Utiliser une adresse du réseau distant comme passerelle est une façon courante de construire une route qui paraît correcte et ne transmet nulle part.

Donner un nom à une interface ne décrit pas les réseaux situés derrière. La route statique est cette description.

Le côté distant doit connaître le pool

Le routeur en aval a besoin d’une route de retour pour le pool, dans cet exemple 10.55.0.0/24 via 192.168.77.1, sauf si une route par défaut ou un protocole dynamique en fournit déjà une. La passerelle de l’hôte de service lui-même doit mener vers ce routeur, ce qui est normalement vrai lorsque le routeur est sa passerelle par défaut et faux lorsque l’hôte a été configuré à la main. Le routage par politique sur le pare-feu peut aussi outrepasser la table pour un trafic donné, alors vérifiez si une règle sélectionne une autre passerelle avant de conclure que la route est mauvaise.

Aucune traduction n’est nécessaire pour cette conception, et garder l’adresse source du client visible permet au réseau aval d’appliquer sa propre politique.

Pour la recette, suivez une nouvelle requête à travers l’entrée du tunnel, la sortie interne du pare-feu et la réponse de la destination. Si une traduction est délibérément utilisée à la place, notez quelle source le réseau aval voit et comment la réponse est censée revenir.

Enregistrez le plan des trois propriétaires à côté de l’application autorisée, afin que l’administrateur suivant puisse reconstruire le chemin au lieu de le redécouvrir.