Problème de NAT sortant suite deco/reco session PPPoE


  • Bonjour,

    Contexte :
    Je déploie la solution PfSense dans le domaine professionnel, principalement pour de la téléphonie IP.
    Je gère actuellement un parc de plus de 100 PfSense.

    Solution actuelle pour le dépannage :
    Un redémarrage du PfSense ou de l'autocom interne résout le problème.

    Spécificités du PfSense :
    Sur nos PfSense est ajouté le package Zabbix pour les monitorer.
    Il n'y a pas de règles de filtrage avancé, éventuellement un second lien WAN pour du Failover.

    Problématique :
    Lorsqu'une déco/reco de la session PPPoE est constatée, PfSense ne fait plus le NAT sortant.
    Mes paquets présentent l'IP privée de mon équipement comme IP Source. De ce fait, le site distant ne répond pas aux requêtes.
    Cette problématique n'est présente que sur les flux UDP.

    Ce problème est constaté sur les liens xDSL avec un modem en amont configuré en bridge.

    Je n'ai pas constaté cela sur les lien FTTH ou FTTO, même si la session PPPoE etait gérée par le PfSense.

    Pistes :

    J'ai activé la purge de la table des états lors d'une perte de connexion.
    Malheureusement, la coupure n'est que de quelques secondes et à aucun moment le système ne considère la passerelle comme down (uniquement des pertes de paquets)

    J'ai également pensé à affiner les paramètre de temporisation d'état dans les paramètres avancés mais ne maitrisant pas ces notions, je crains qu'il y'ai des effets de bords sur les trunk SIP.

    Demande :
    Étant dans une impasse, je fais appelle à la communauté qui j’espère aura un retour d'expérience similaire avec une solution à mon problème.

    Merci d'avance à ceux qui prendrons du temps sur ce sujet.


  • Bravo pour la présentation claire du problème.
    (Je suis aussi fan de Zabbix ...)

    Je ne serais pas surpris que le pb vienne du module PPPoE.

    Je n'ai jamais eu autant de pfSense.
    Pour les sites SDSL, le fournisseur apporte une routeur avec les adresses ip publiques (un range /29 soit 5 adresses dispo), donc pas de PPPoE.
    Pour les sites ADSL, je passais sur un modem DLink Dsl320b (le classique) configuré en Bridge RFC1483 typiquement, et donc avec PPPoE sur le pfSense,
    Il me semble que ce boitier peut-être configuré en mode routeur qui évite le PPPoE sur le pfSense.


  • Bonjour,

    Je vous remercie d'avoir pris le temps de me répondre.

    Presque toutes les sessions PPPoE sont portées par les PfSense directement quelque soit le support du lien (xDSL / FTTH / FTTO / SDSL) mais je n'ai ma problématique que sur les liens ADSL et VDSL.
    Pour ma part (mais je n’écarte pas cette hypothèse), le module PPPoE n'est pas en défaut.

    En revanche, le point commun de chaque cas est la référence du modem qui est en bridge.
    Il est possible que ce modem perturbe le PfSense où qu'il soit mal configuré.

    Je vais tester avec une autre référence et ne manquerais par de faire un retour.

    Si d'autres pistes sont à envisager je suis preneur avant d'aller sur site client.

    Merci.


  • Le module PPPoE fait normalement son boulot, y compris lors de la reconnexion. Toutefois, il parait étonnant que la reco ne se fait que sur les protocoles basés TCP et non pour ceux basés sur UDP ; UDP est un protocole 'non connecté', il ne devrait pas être influencé en cas de 'perturbations', au pire les proto basés sur UDP renverraient un paquet. C'est donc troublant.

    J'ignore si 'pf' recharge sa config lors de la reconnexion PPPoE (car cela me semblerait nécessaire, tout en laissant les sessions actives (tcp) se continuer). Mais je peux me tromper ... (J'ai tendance à considérer que je n'ai pas à gérer au niveau de MON firewall un pb de fournisseur, mais on fait avec ce qui est proposé, ça coute le routeur du fai et une des ip publiques : 5 ip pour un /29 au lieu de 6).

    Il peut être intéressant de tester via un routeur intermédiaire. Toutefois, bien évidemment, pfSense n'aura pas l'info de la perte de connexion !


  • Bonjour,

    J'ai avancé sur mon problème.

    Le remplacement du modem en bridge par une autre référence n'a pas solutionné mon problème.
    Le défaut est toujours le même... le NAT sortant ne se fait pas.

    Ma configuration habituelle :
    Habituellement, je configure le NAT sortant en mode hybride et je crée une règle spécifique pour mon autocom pour que le port source soit statique pour les flux UDP (prérequis au bon fonctionnement des trunk SIP).

    Il reste donc les règles par défaut pour les autres flux sortants, qui eux, on l'air de fonctionner après une déco/reco.

    Mes tests en cours :
    Sur 2 sites où je rencontre le soucis, j'ai passé le mode NAT sortant en manuel et j'ai modifié la règle générique qui englobe tous les flux depuis mon réseau privé pour coché la case "port statique".

    Je vous ferai un retour avec les résultats obtenus.

    Bonne journée.