Configurer et vérifier un WAN PPPoE sur Sophos Firewall

PPPoE doit être configuré sur Sophos Firewall lorsqu’un modem ou un ONT placé en amont transmet la connexion de manière transparente en mode bridge ou passthrough. Le pare-feu établit alors la connexion avec l’opérateur et reçoit l’adresse WAN attribuée.

Si l’équipement de l’opérateur établit la session PPPoE, Sophos Firewall reçoit normalement derrière lui une adresse WAN statique ou attribuée par DHCP. Si les deux équipements effectuent du NAT, cela crée un double NAT. Dans cette architecture, une connexion PPPoE supplémentaire sur le pare-feu est généralement inutile et peut être refusée en tant que deuxième session.

⚠️ Avant la modification, il faut clairement savoir quel équipement établit la session PPPoE. Une connexion simultanée depuis l’équipement de l’opérateur et le pare-feu n’a de sens que si l’opérateur prend explicitement en charge plusieurs sessions. La modification nécessite un accès administrateur local ou indépendant, car un réglage incorrect coupe immédiatement la connexion Internet.

Rassembler les informations de l’opérateur avant de commencer

Les valeurs suivantes doivent être disponibles avant la fenêtre de maintenance :

• Nom d’utilisateur et mot de passe PPPoE, ou exigence d’authentification exacte de l’opérateur
• Mode bridge ou passthrough du modem ou de l’ONT
• ID de VLAN opérateur facultatif
• Nom d’Access Concentrator ou de service facultatif
• Exigence concernant une adresse IP dynamique, fixe ou préférée
• Paramètres DNS et particularités connues concernant la MTU ou la reconnexion
• Nombre de sessions PPPoE autorisées et informations sur le CGNAT

L’aide Sophos prévoit le nom d’utilisateur et le mot de passe du compte PPPoE. Toute exigence différente de l’opérateur doit être confirmée avant la fenêtre de maintenance ; il ne faut pas supposer qu’un mot de passe vide est accepté. WebAdmin accepte un nom d’utilisateur de 50 caractères maximum. Si l’identifiant est plus long, ce point doit être clarifié avec Sophos Support avant la modification.

La préparation comprend également une sauvegarde de configuration récente, une fenêtre de maintenance et un plan de retour arrière. En cas de modification à distance, l’unique accès d’administration ne doit pas passer précisément par le port WAN qui est reconfiguré.

Configurer l’interface PPPoE

L’exemple suivant utilise Port2 pour une connexion avec un ONT en mode bridge. L’opérateur exige un nom d’utilisateur, un mot de passe et le VLAN 7, mais aucune Preferred IP ni aucun nom de service. Le VLAN 7 n’est qu’un exemple et ne doit pas être repris sans vérification pour une connexion réelle.

1. Ouvrir Network > Interfaces.
2. Ouvrir le menu du port WAN prévu et sélectionner Edit interface.
3. Définir un nom explicite tel que WAN-PPPoE et la zone WAN.
4. Activer IPv4 et sélectionner PPPoE comme IP assignment.
5. Sous Username, saisir par exemple firma@example.net, puis la valeur correspondante de l’opérateur sous Password. Ne pas copier de véritables identifiants dans des captures d’écran ou des tickets.
6. Laisser Preferred IP vide si l’opérateur n’a pas indiqué d’adresse PPPoE fixe.
7. Attribuer un Gateway name explicite tel que gw-pppoe et saisir la Gateway IP address exigée par l’opérateur pour une interface PPPoE physique. Sur un VLAN PPPoE, ce champ affiche au contraire l’adresse de passerelle configurée.
8. Laisser Access concentrator/service name vide, sauf si l’opérateur exige un nom exact.
9. Conserver LCP echo interval à 20 secondes et LCP failure à 3.
10. Activer une reconnexion planifiée uniquement si l’opérateur ou l’exploitation l’exige.
11. Si l’opérateur exige un VLAN pour PPPoE, choisir l’une des variantes décrites dans la section suivante.
12. Enregistrer, puis vérifier l’interface, la passerelle, le DNS et le trafic réel d’un client.

Une Preferred IP n’est qu’une demande adressée à l’opérateur. Même si une adresse est saisie, le serveur PPPoE peut attribuer une autre adresse IP. Pour garantir une adresse fixe, l’opérateur doit fournir le service correspondant.

Un nom d’Access Concentrator ou de service limite la connexion à un point d’accès correspondant. Une valeur inventée ou mal orthographiée peut empêcher la connexion dès la phase de découverte. Le champ doit donc rester vide en l’absence d’indication explicite de l’opérateur.

Mettre en œuvre correctement le VLAN opérateur

Un VLAN opérateur peut être configuré de deux manières. Les deux méthodes sont valides, mais elles ne doivent pas être combinées pour la même connexion.

Variante 1 : réglage VDSL sur le port PPPoE physique

PPPoE est configuré directement sur le port WAN physique. Sous DSL settings, activer VDSL et saisir l’ID de VLAN de l’opérateur. SFOS assure ainsi le traitement VLAN nécessaire à la session PPPoE.

La désignation VDSL ne signifie pas que le pare-feu remplace un modem DSL ou un ONT. L’équipement placé en amont reste responsable de la ligne physique et de la synchronisation.

Dans cet exemple, le VLAN 7 est défini sur le port PPPoE. Il ne faut ensuite pas créer sur la même connexion un VLAN 7 manuel supplémentaire avec une deuxième configuration PPPoE.

Variante 2 : PPPoE sur un VLAN WAN manuel

Sous Network > Interfaces > Add interface > Add VLAN, commencer par créer un VLAN sur le port physique de l’opérateur. Attribuer à ce VLAN la zone WAN, l’ID de VLAN de l’opérateur et PPPoE comme affectation IPv4. Saisir les identifiants sur cette interface VLAN.

Cette architecture est utile lorsque l’interface VLAN doit apparaître explicitement et porter un nom distinct dans la conception des interfaces. Configurer un VLAN sur Sophos Firewall explique les principes de l’interface parente et du marquage VLAN.

Si un VLAN est déjà configuré sur une interface physique, SFOS ne peut pas simplement modifier l’affectation IP de cette interface de Static à PPPoE ou DHCP. Il faut d’abord examiner la conception existante. Une modification peut aussi affecter les configurations DNS, de passerelle, SD-WAN, d’hôtes d’interface, de VLAN et de Dynamic DNS dépendantes. Off conserve la configuration ; la suppression d’une interface virtuelle peut également supprimer des règles et objets dépendants.

Comprendre LCP et la reconnexion

Les échos LCP vérifient si le pair PPP répond toujours. Avec les valeurs par défaut, le pare-feu envoie un contrôle toutes les 20 secondes et considère la session comme inaccessible après 3 réponses manquantes.

Ces valeurs constituent un point de départ pertinent. Un intervalle plus court détecte les pannes plus tôt, mais peut provoquer des reconnexions inutiles sur une ligne instable. LCP ne doit donc être modifié qu’en raison d’une exigence de l’opérateur ou d’un problème documenté. Décocher le réglage ne désactive pas LCP, mais rétablit les valeurs par défaut.

Schedule time for reconnect coupe la session PPPoE à une heure définie, puis la rétablit. Cette option peut être utile lorsque l’opérateur impose une déconnexion régulière, mais ce n’est pas une fonction de réparation générale. Les connexions actives sont interrompues et, avec une attribution dynamique, l’adresse IP publique peut changer. Une reconnexion nécessaire doit donc être planifiée en dehors des heures de production.

Valider l’ensemble de la connexion

La seule attribution d’une adresse WAN ne prouve pas que les clients peuvent accéder à Internet. Après l’enregistrement, vérifier les différents niveaux dans l’ordre suivant.

Interface et passerelle

Sous Network > Interfaces, l’interface PPPoE doit afficher Connected et une adresse attribuée. Connecting indique que l’adresse est encore en cours d’obtention ; Disconnected qu’elle a été libérée. La passerelle WAN physique associée apparaît automatiquement sous Network > WAN link manager.

Une nouvelle passerelle WAN est Active par défaut. Avec plusieurs connexions Internet, elle peut donc participer immédiatement à l’équilibrage de charge. Si la nouvelle connexion PPPoE ne doit servir que de secours, configurer directement la passerelle comme Backup, puis la tester de manière contrôlée. La procédure complète est décrite dans Configurer et tester le basculement WAN.

DNS

Sous Network > DNS, utiliser Obtain DNS from PPPoE ou configurer délibérément un DNS statique. Test name lookup permet de vérifier directement la résolution.

Avec plusieurs connexions PPPoE, il ne faut pas supposer un ordre non documenté des serveurs DNS reçus. Des serveurs DNS choisis délibérément et des tests séparés assurent une conception Multi-WAN prévisible.

Règle de pare-feu, NAT et test client

Le trafic LAN vers WAN nécessite une règle de pare-feu adaptée et généralement du masquerading ou du SNAT. Comprendre le NAT sur Sophos Firewall explique l’interaction de ces composants.

Tester ensuite au moins les fonctions suivantes depuis un client :

1. Accessibilité d’une adresse IP externe.
2. Résolution d’un nom DNS.
3. Accès à une page HTTPS.
4. Une application importante pour l’exploitation.
5. Une entrée de journal avec la règle de pare-feu et l’interface WAN attendues.

La réussite d’un ping ne suffit pas. Le DNS, HTTPS, le NAT ou une application peuvent toujours échouer même si de petits paquets ICMP fonctionnent.

Si Log Viewer ne montre pas clairement où le chemin s’interrompt, appliquer sous Diagnostics > Packet capture un filtre étroit sur l’adresse IP et le protocole du client. Pour les paquets transférés, In interface, Out interface, Rule ID, NAT ID, Status et Gateway ID doivent correspondre au chemin prévu. La vue ne prouve que les paquets capturés ; le tampon est limité à 2048 KB et s’arrête lorsqu’il est plein, sauf si son bouclage est activé.

Revenir en arrière après une modification infructueuse

Si aucune session PPPoE n’est établie, rétablir l’état antérieur documenté via l’accès administrateur indépendant. Pour un VLAN PPPoE ajouté, le placer d’abord sur Off afin de conserver sa configuration pour l’analyse. Rétablir ensuite l’équipement opérateur et l’ancien chemin WAN statique ou DHCP avec sa passerelle et son DNS. Si le port physique a été modifié, restaurer ses valeurs relevées. Ne pas supprimer précipitamment le VLAN : la suppression d’une interface virtuelle peut enlever des règles et d’autres configurations dépendantes. Ne poursuivre qu’après une nouvelle validation complète de l’ancien chemin.

Diagnostiquer méthodiquement les erreurs PPPoE

Vérifier d’abord la ligne et la configuration, puis la MTU ou les autres valeurs spéciales :

1. Contrôler l’état du lien, la synchronisation du modem ou de l’ONT, le câblage et le mode bridge/passthrough.
2. Comparer le VLAN opérateur aux données du contrat et vérifier qu’il n’est pas défini à la fois par l’option VDSL et par un VLAN manuel.
3. Vérifier exactement le nom d’utilisateur, le mot de passe facultatif et la casse.
4. Effacer Preferred IP ainsi que le nom de l’Access Concentrator ou du service si l’opérateur n’a pas explicitement fourni ces valeurs.
5. Enregistrer et vérifier si l’interface reçoit une adresse IP et une passerelle.
6. Tester d’abord le DNS avec Test name lookup, puis depuis un client.
7. Vérifier la règle de pare-feu, le NAT et Log Viewer.

Pour un diagnostic approfondi dans 5. Device Management > 3. Advanced Shell, commencer par observer les événements des interfaces :

tail -f /log/networkd.log

networkd.log affiche les événements des interfaces physiques et virtuelles. La passerelle WAN et les éventuels événements de basculement figurent dans dgd.log :

tail -f /log/dgd.log

Arrêter chaque sortie en cours avec Ctrl+C. Des messages système supplémentaires peuvent être affichés dans 4. Device Console à l’aide d’une commande en lecture seule :

system diagnostics show syslog

La correspondance officielle attribue networkd.log aux interfaces physiques et virtuelles et dgd.log aux événements de lien WAN, de passerelle et de basculement. system diagnostics show syslog affiche des messages système supplémentaires, mais ne fournit pas automatiquement une cause PPPoE complète. Documenter le message exact avec l’heure, l’interface, la version et une nouvelle tentative. Si ces sources ne suffisent pas, capturer le test reproductible avec un filtre étroit ; Journaux de service de Sophos Firewall présente les autres fichiers.

Schémas typiques :

• Aucun pair PPPoE trouvé : vérifier le lien, le mode bridge/passthrough, le VLAN opérateur et le nom de service facultatif.
• Authentification refusée : vérifier les identifiants, leur longueur, le compte opérateur et le nombre de sessions autorisées.
• La session est établie, puis interrompue : examiner la ligne, les événements de l’opérateur, LCP et la reconnexion planifiée.
• Une adresse WAN est présente, mais sans accès Internet : vérifier la passerelle, le DNS, la règle de pare-feu, le NAT et le routage.
• Seuls les gros paquets ou le trafic VPN échouent : n’examiner MTU/MSS qu’après un test reproductible.

Ne pas modifier globalement la MTU et le MSS

PPPoE ajoute une surcharge. Cela ne signifie toutefois pas que chaque connexion doit être réglée manuellement sur une MTU de 1492 ou un MSS de 1452. Les valeurs par défaut fonctionnent dans de nombreux environnements, et les VLAN, VPN ou technologies de l’opérateur supplémentaires modifient le chemin réel.

Une adaptation n’est pertinente que si, par exemple, les petits paquets fonctionnent, les transferts HTTPS volumineux se bloquent ou les captures de paquets révèlent des problèmes de fragmentation répétés. Vérifier la MTU et le MSS sur Sophos Firewall explique la mesure et le calcul.

Multi-WAN, Dynamic DNS et HA

Une connexion PPPoE établie se comporte dans WAN Link Manager comme une autre passerelle WAN physique. Lors d’une reconnexion ou d’un basculement, l’adresse publique et toutes les connexions associées peuvent toutefois changer. Cela concerne notamment IPsec, DNAT, les listes d’autorisation externes et Remote Access. Pour les adresses dynamiques, Dynamic DNS sur Sophos Firewall est utile, mais ne remplace pas le test des services entrants.

Si l’opérateur n’attribue qu’une adresse CGNAT privée ou partagée, le pare-feu n’est normalement pas directement accessible depuis Internet. Dynamic DNS se contente de mettre à jour le nom et ne supprime pas le CGNAT. Les services entrants nécessitent une adresse publique ou transférée par l’opérateur.

PPPoE est autorisé dans un cluster HA Active-Passive, mais Sophos indique qu’il n’y a pas de session failover. Le nouveau Primary doit donc rétablir la connexion opérateur. Le lien HA dédié et les deux ports d’administration exigent des adresses statiques. Active-Active exige des adresses statiques sur toutes les interfaces et ne prend donc pas en charge un WAN PPPoE. La conception physique doit permettre aux deux appliances d’atteindre l’accès après un changement de rôle. Variantes HA de Sophos Firewall explique les autres limites.

IPv6 relève d’une décision distincte de l’opérateur. Si la connexion fournit Prefix Delegation, IPv6 Prefix Delegation sur Sophos Firewall présente la configuration séparée.

Écarter les erreurs propres à une version

SFOS 22.0 MR1 Build 490 corrige des problèmes PPPoE précisément identifiés : NC-174437 pour Policy Test via PPPoE, NC-173201 pour la synchronisation des licences en HA Active-Passive avec PPPoE et NC-167806 pour les pertes de paquets et les faibles performances d’envoi avec une file TX de longueur 3. Sophos Known Issues classe aussi NC-181526 comme résolu dans MR2 Build 546 : sur les équipements XGS Appliance autres que XGS 88/88w, 108/108w, 118/118w et 128/128w, les tunnels IPsec utilisant une IP d’alias sur un WAN PPPoE pouvaient s’établir sous GA et MR1 sans transmettre de trafic lorsque l’accélération IPsec était activée.

Si l’un de ces symptômes apparaît sur une ancienne version de SFOS 22, planifier d’abord une mise à jour contrôlée vers une Maintenance Release actuellement prise en charge. Contrôle de mise à niveau SFOS 22 décrit la préparation. Les anciens contournements, tels que la désactivation globale de l’accélération IPsec, n’ont pas leur place dans une nouvelle configuration standard.

FAQ