Maintenant que nous avons deux connexions vers Internet, il est temps de configurer notre pare-feu pfSense pour les prendre en compte toutes les deux.

Vu la différence de débit (1Gbps vs 5Mbps), l’ADSL ne nous servira qu’en cas de panne. Répartir la charge ne ferait que frustrer les flux qui auraient la malchance de sortir du mauvais côté. Alors plutôt que risquer un incident diplomatique familial, autant mettre tout le monde sur la fibre et laisser l’ADSL, au cas où.

Pour les curieux, voici donc comment nous nous y sommes pris.

Configuration des interfaces

On pourrait configurer toutes les interfaces directement lors de l’installation du système. On est d’ailleurs obligés d‘en configurer certaines (une WAN et une LAN) pour pouvoir se connecter et utiliser le pare-feu. Mais une fois le minimum fait en ligne de commande, je préfère souvent passer par l’interface graphique. Plus complète et intuitive à utiliser.

La première étape est donc de configurer ses interfaces pour que pfSense sache qui est qui. Pour ça, on va dans le menu « Interfaces / Assignements » et on ajoute toutes les cartes réseaux dont on a besoin (on les renommera plus tard).

WAN Free

On va commencer par l’interface vers la freebox. Pour ça, on clique simplement sur l’interface correspondante dans l’écran précédent.

Les possibilités de configuration sont nombreuses, mais pour notre cas, on n’a pas grand chose à changer, juste donner un nom (champ description) et s’assurer qu’elle est en DHCP.

Pour faciliter la configuration de la DMZ côté freebox, il peut être intéressant de configurer un nom d’hôte (champ hostname). Ce nom sera utilisé par pfSense lors de sa requête DHCP, la freebox s’en servant ensuite dans son interface pour nous montrer les périphériques connectés.

Et enfin, puisque notre pare feu est connecté à des réseaux privés (pour rappel, on utilise le mode routeur et non le mode bridge), il faut aussi débloquer les réseaux privés (décocher la case « Block private networks and loopback addresses »).

WAN Red

De même, la configuration de l’interface côté redbox est simplissime, il faut juste s’assurer qu’elle est en DHCP. N’ayant pas configuré l’IPv6, le champ correspondant est laissé vide.

Je ne répète pas les captures, mais n’oubliez pas d’ajouter un nom d’hôte (hostname) et d’autoriser les réseaux privés (case « block private network »).

Détection des pannes

Pour permettre à pfSense de basculer d’une connexion à l’autre automatiquement, il faut lui dire comment surveiller les passerelles. Pour cela, il faut aller dans le menu « System / Routing ». Vous y retrouverez les passerelles correspondantes à vos interfaces en DHCP.

La surveillance d’une passerelle se fait via sa configuration, en cliquant sur l’icone de crayon () en vis à vis. Dans l’écran suivant, nous pouvons alors modifier les champs suivants :

• Décocher « Disable Gateway Monitoring » et « Disable Gateway Monitoring Action » pour activer la surveillance et la prise en compte des défaillances.
• Renseigner « Monitor IP » avec l’adresse IP d’un serveur répondant au requêtes ICMP.

Le choix de l’adresse IP à joindre n’est pas anodin. Si vous prenez l’adresse de votre passerelle (votre box ou le routeur de l’opérateur), vous ne pourrez pas détecter les défaillances en amont. Dans notre cas, nous avons choisi les adresses des serveurs de Google, 8.8.8.8 pour le côté freebox et 8.8.4.4 pour le côté redbox.

Vu à quel point ces deux adresses sont utilisées, le jour où un petit malin leur coupera le trafic ICMP, c’est tout internet qui s’effondrera, les admins réseaux du monde entiers étant persuadés que leurs passerelles sont défaillantes…

Ensuite, pour voir l’état des passerelles, il faudra passer par le menu « Status / Gateways ». Dans le tableau suivant, pfSense nous montre les résultats des requêtes ICMP et l’état correspondant.

Routage

Maintenant que les interfaces sont configurées et surveillée, on peut passer au routage proprement dit, le choix de la passerelle en charge du trafic sortant.

Groupe de passerelles

On commence par grouper les passerelles. Pour cela, on va dans le menu « System / Routing / Gateway Groups » et on ajoute un groupe.

• On lui choisi un nom évocateur (e.g. « WANs »),
• On place la passerelle freebox IPv4 en tier 1,
• On place la passerelle redbox IPv4 en Tier 2,
• On configure le Trigger Level à Member down,
• Une petite description, c’est toujours utile,
• Et on sauvegarde.

C’est la notion de Tier (« étage en français ») qui permet cette notion de l’utilisation « au cas où ». En effet, pfSense réparti la charge entre toutes les passerelles d’un même étage, n’utilisant un étage que si les étages précédent (de valeur inférieure) ont un problème.

De son côté, la détection du problème correspond au réglage Trigger Level précédent. Dans notre cas, Member Down considère la passerelle comme en échec si elle a 100% de perte de paquets lors du monitoring.

On comprend alors l’intérêt de ces trois réglages :

• Monitoring IP : qui permet de prendre en compte une défaillance plus ou moins lointaine en fonction du choix de l’IP cible,
• Trigger Level : qui permet la bascule en fonction des résultats du monitoring,
• Les Tiers : qui organisent les passerelles par ordre de préférence.

Passerelle par défaut

Maintenant que le groupe est créé et configuré, on va l’utiliser en tant que passerelle par défaut. Pour ça, on revient dans l‘écran « System / Routing » et on s’attache à sa deuxième partie, la configuration des passerelles par défaut.

C’est dans ce genre d’interface où l’intérêt d’utiliser des noms et des descriptions prend tout son sens.

Dans notre cas, nous configurons la passerelle IPv4 pour utiliser notre groupe. Ce qui met effectivement en place la bascule automatique en cas de panne.

Résolution DNS

Tous ces réglages sont suffisant pour traiter le routage mais il reste encore un petit détail à régler.

Par défaut, pfSense relaie les requêtes DNS vers les serveurs DNS de ses interfaces réseaux (c’est à dire, les boxes), et le problème, c’est qu’il le fait sans tenir compte de l’état des connexions correspondantes.

Dans notre cas, si quand la fibre tombe, pfSense continuera d’envoyer des requêtes DNS vers cette connexion. La box va bien entendu recevoir la requête mais ne pourra pas la résoudre puisque sa connexion Internet n’est pas disponible. La requêtes va ainsi expirer et pfSense pourra alors la renvoiyer côté ADSL. Croyez moi, le délai induit est visible (et franchement frustrant).

Les détails sont dans un article dédié à la configuration DNS mais si vous êtes pressé, il suffit d’aller dans le menu « Services / DNS Resolver » et d’activer le serveur DNS (cocher la case Enable) puis de forcer la résolution plutôt que la retransmission (décocher la case DNS Query Forwarding), sauvegarder et appliquer.

Et après ?

Pour tester la connexion, on pourrait se satisfaire de couper la fibre manuellement (au sens figuré bien sûr, on est pas équipé pour réparer ensuite), puis surveiller l’état des passerelles et enfin contrôler que la connexion internet fonctionne toujours pour les postes utilisateurs.

C’est d’ailleurs ce que je vous conseille de faire régulièrement : tester vos mécanismes de secours. Ça vous permettra de vous entraîner et de corriger les éventuels problèmes qui peuvent survenir avant une vraie panne.

Les choses étant bien faites, le réseau free a décidé d’avoir un incident pendant la rédaction de cet article…

Il est 16h, on se prépare à lancer une LAN party en famille et, après d’âpres négociations sur le choix du titre, le jeu vidéo décide de se mettre à jour et nous annonce un délai de plusieurs jours… souvenir de l’époque ou nous n’avions que l’ADSL.

Après avoir installé une cellule d’urgence médico-psychologique prioritaire, on peut diagnostiquer le problème. Petit tour sur l’interface de notre pare feu et on confirme le problème : la connexion fibre est tombée.

Mais d’où vient le problème ? Sur son interface de configuration, la freebox n’a rien remarqué mais après un redémarrage, elle reste bloquée à l’étape 6 (l’authentification aux serveurs de free), ça sent le problème du FAI. Problème confirmé en regardant l’état du réseau free : les répartiteurs autour de notre village sont tous tombés.

En fait, la panne avait débuté 5 heures plus tôt mais nous n’avions rien vu car la connexion de secours avait silencieusement pris le relai. La panne a été résolue vers 19h30 mais la LAN party était finie.

Comme on peut s’en rendre compte rapidement, basculer automatiquement sur une connexion de secours, c’est quand même bien confortable voir rassurant. Mais pour vous, très chers lecteurs, ces réglages n’ont pas permis de maintenir l’accès au site merveilleux des arsouyes.