PPPoE-WAN auf Sophos Firewall einrichten und prüfen
PPPoE gehört auf die Sophos Firewall, wenn ein vorgeschaltetes Modem oder ONT den Anschluss transparent im Bridge- beziehungsweise Passthrough-Modus weiterreicht. Die Firewall baut dann die Providerverbindung auf und erhält die zugewiesene WAN-Adresse.
Baut das Providergerät die PPPoE-Sitzung auf, erhält die Sophos Firewall dahinter normalerweise eine statische oder per DHCP zugewiesene WAN-Adresse. Wenn beide Geräte NAT ausführen, entsteht Double NAT. Eine zusätzliche PPPoE-Einwahl auf der Firewall ist in diesem Aufbau meist unnötig und kann als zweite Sitzung abgewiesen werden.
⚠️ Vor der Umstellung muss klar sein, welches Gerät die PPPoE-Sitzung aufbaut. Eine parallele Einwahl auf Providergerät und Firewall ist nur sinnvoll, wenn der Provider mehrere Sitzungen ausdrücklich unterstützt. Für die Änderung braucht es lokalen oder unabhängigen Admin-Zugriff, weil eine falsche Einstellung die Internetverbindung sofort trennt.
Vor dem Start die Providerangaben sammeln
Die folgenden Werte sollten vor dem Wartungsfenster vorliegen:
- PPPoE-Benutzername und gegebenenfalls Passwort
- Bridge- oder Passthrough-Modus des Modems beziehungsweise ONT
- optionale Provider-VLAN-ID
- optionaler Access-Concentrator- oder Service-Name
- Vorgabe zu dynamischer, fester oder bevorzugter IP-Adresse
- DNS-Vorgaben und bekannte Besonderheiten zu MTU oder Reconnect
- Anzahl der erlaubten PPPoE-Sitzungen und Information zu CGNAT
Der Benutzername ist erforderlich. Ob auch ein Passwort benötigt wird, hängt vom Provider und seinem Authentifizierungsverfahren ab. Der WebAdmin akzeptiert für den Benutzernamen maximal 50 Zeichen. Ist der Provider-Login länger, sollte dies vor der Umstellung mit Sophos Support geklärt werden.
Zusätzlich gehören ein aktuelles Konfigurationsbackup, ein Wartungsfenster und ein Rückfallplan zur Vorbereitung. Bei einer Remote-Änderung darf der einzige Verwaltungszugang nicht über genau den WAN-Port laufen, der neu konfiguriert wird.
PPPoE-Interface einrichten
Das folgende Beispiel verwendet Port2 für einen Anschluss mit Bridge-ONT. Der Provider verlangt Benutzername, Passwort und VLAN 7, aber keine Preferred IP und keinen Service-Namen. VLAN 7 ist nur ein Beispiel und darf nicht ungeprüft für einen echten Anschluss übernommen werden.
- Network > Interfaces öffnen.
- Beim vorgesehenen WAN-Port das Menü öffnen und Edit interface wählen.
- Einen eindeutigen Namen wie
WAN-PPPoEund die Zone WAN setzen. - IPv4 aktivieren und als IP assignment den Wert PPPoE wählen.
- Unter Username beispielsweise
firma@example.neteintragen. Das Feld Password nur dann mit dem Providerwert füllen, wenn der Anschluss ein Passwort verlangt. - Preferred IP leer lassen, wenn der Provider keine feste PPPoE-Adresse vorgegeben hat.
- Einen verständlichen Gateway name wie
gw-pppoevergeben. Eine Gateway-IP nur eintragen, wenn der Provider einen konkreten Wert nennt. - Access concentrator/service name leer lassen, sofern der Provider keinen exakten Namen verlangt.
- LCP echo interval auf
20Sekunden und LCP failure auf3belassen. - Einen geplanten Reconnect nur aktivieren, wenn der Provider oder der Betrieb dies verlangt.
- Falls der Provider für PPPoE ein VLAN fordert, eine der im nächsten Abschnitt beschriebenen Varianten wählen.
- Speichern und anschliessend Interface, Gateway, DNS und echten Clienttraffic prüfen.
Eine Preferred IP ist nur eine Anfrage an den Provider. Auch wenn dort eine Adresse eingetragen ist, kann der PPPoE-Server eine andere IP zuweisen. Für eine verbindlich feste Adresse muss der Provider den passenden Dienst bereitstellen.
Ein Access-Concentrator- oder Service-Name schränkt die Einwahl auf eine passende Gegenstelle ein. Ein erfundener oder falsch geschriebener Wert kann die Verbindung bereits in der Discovery-Phase verhindern. Deshalb bleibt das Feld ohne ausdrückliche Providerangabe leer.
Provider-VLAN richtig umsetzen
Ein Provider-VLAN kann auf zwei Arten konfiguriert werden. Beide Wege sind gültig, dürfen für denselben Anschluss aber nicht kombiniert werden.
Variante 1: VDSL-Einstellung am physischen PPPoE-Port
PPPoE wird direkt auf dem physischen WAN-Port eingerichtet. Unter DSL settings wird VDSL aktiviert und die Provider-VLAN-ID eingetragen. SFOS übernimmt dadurch die benötigte VLAN-Verarbeitung für die PPPoE-Sitzung.
Die Bezeichnung VDSL bedeutet hier nicht, dass die Firewall ein DSL-Modem oder ONT ersetzt. Das vorgeschaltete Gerät bleibt für die physische Leitung und Synchronisation zuständig.
Im Beispiel wird am PPPoE-Port VLAN 7 gesetzt. Auf demselben Anschluss darf danach kein zusätzliches manuelles VLAN 7 mit einer zweiten PPPoE-Konfiguration entstehen.
Variante 2: PPPoE auf einem manuellen WAN-VLAN
Unter Network > Interfaces > Add interface > Add VLAN wird zuerst ein VLAN auf dem physischen Providerport angelegt. Dieses VLAN erhält die Zone WAN, die Provider-VLAN-ID und als IPv4-Zuweisung PPPoE. Die Zugangsdaten werden auf diesem VLAN-Interface eingetragen.
Dieser Aufbau ist sinnvoll, wenn die VLAN-Schnittstelle im Interface-Design ausdrücklich sichtbar und separat benannt werden soll. Die Grundlagen zum Parent Interface und VLAN-Tagging erklärt VLAN auf Sophos Firewall einrichten.
Ist auf einem physischen Interface bereits ein VLAN konfiguriert, kann SFOS die IP-Zuweisung dieses physischen Interfaces nicht einfach von Static auf PPPoE oder DHCP umstellen. Dann muss das vorhandene Interface- und VLAN-Design zuerst geprüft werden.
LCP und Reconnect verstehen
LCP-Echos prüfen, ob die PPP-Gegenstelle noch antwortet. Mit den Standardwerten sendet die Firewall alle 20 Sekunden eine Prüfung und bewertet die Sitzung nach 3 fehlgeschlagenen Antworten als nicht mehr erreichbar.
Diese Werte sind ein sinnvoller Ausgangspunkt. Ein kürzeres Intervall erkennt Fehler früher, kann bei einer instabilen Leitung aber unnötige Neuverbindungen auslösen. LCP sollte deshalb nur aufgrund einer Provideranforderung oder eines dokumentierten Fehlerbilds angepasst werden. Das Abwählen der Einstellung deaktiviert LCP nicht, sondern stellt die Standardwerte wieder her.
Schedule time for reconnect trennt die PPPoE-Sitzung zu einer festgelegten Zeit und baut sie neu auf. Das kann bei einem Provider mit regelmässiger Zwangstrennung helfen, ist aber keine allgemeine Reparaturfunktion. Laufende Verbindungen brechen ab und bei einer dynamischen Zuweisung kann sich die öffentliche IP-Adresse ändern. Ein notwendiger Reconnect gehört daher ausserhalb der produktiven Zeit.
Verbindung vollständig abnehmen
Eine zugewiesene WAN-Adresse allein beweist noch nicht, dass Clients das Internet nutzen können. Nach dem Speichern werden die beteiligten Ebenen in dieser Reihenfolge geprüft.
Interface und Gateway
Unter Network > Interfaces muss das PPPoE-Interface verbunden sein und eine IP-Adresse erhalten haben. Das zugehörige physische Gateway erscheint automatisch unter Network > WAN link manager.
Ein neues WAN-Gateway ist standardmässig Active. Bei mehreren Internetleitungen kann es deshalb sofort am Load Balancing teilnehmen. Soll der neue PPPoE-Anschluss nur als Reserve dienen, muss das Gateway direkt als Backup konfiguriert und anschliessend kontrolliert getestet werden. Der vollständige Ablauf steht unter WAN-Failover einrichten und testen.
DNS
Unter Network > DNS kann Obtain DNS from PPPoE verwendet oder ein bewusster statischer DNS-Aufbau konfiguriert werden. Mit Test name lookup lässt sich die Auflösung direkt prüfen.
Bei mehreren PPPoE-Verbindungen sollte keine nicht dokumentierte Reihenfolge der bezogenen DNS-Server vorausgesetzt werden. Für ein berechenbares Multi-WAN-Design sind bewusst gewählte DNS-Server und getrennte Tests sinnvoll.
Firewall-Regel, NAT und Clienttest
Für LAN-zu-WAN-Traffic braucht es eine passende Firewall-Regel und in der Regel Masquerading beziehungsweise SNAT. Die Zusammenhänge erklärt NAT auf Sophos Firewall verstehen.
Von einem Testclient werden anschliessend mindestens diese Funktionen geprüft:
- Erreichbarkeit einer externen IP-Adresse.
- Auflösung eines DNS-Namens.
- Aufruf einer HTTPS-Seite.
- Eine für den Betrieb wichtige Anwendung.
- Logeintrag mit der erwarteten Firewall-Regel und WAN-Schnittstelle.
Ein erfolgreicher Ping reicht nicht. DNS, HTTPS, NAT oder eine Anwendung können weiterhin scheitern, obwohl kleine ICMP-Pakete funktionieren.
Bei einer fehlgeschlagenen Umstellung zurückkehren
Kommt keine PPPoE-Sitzung zustande, wird die Umstellung über den unabhängigen Adminzugang zurückgenommen: Providergerät auf den zuvor dokumentierten Betriebsmodus zurückstellen, das WAN-Interface wieder auf die bisherige statische oder per DHCP zugewiesene Adresse setzen und den bisherigen Gateway- und DNS-Pfad aktivieren. Danach Interface, Gateway, DNS und einen echten Clienttest erneut prüfen. Erst wenn der alte Pfad wieder funktioniert, wird weiter an PPPoE gearbeitet.
PPPoE-Fehler systematisch eingrenzen
Zuerst werden Leitung und Konfiguration geprüft, erst danach MTU oder weitere Spezialwerte:
- Linkstatus, Modem- beziehungsweise ONT-Synchronisation, Verkabelung und Bridge-/Passthrough-Modus kontrollieren.
- Provider-VLAN mit den Vertragsdaten vergleichen und sicherstellen, dass es nicht gleichzeitig per VDSL-Option und manuellem VLAN gesetzt wurde.
- Benutzername, optionales Passwort und Gross-/Kleinschreibung exakt prüfen.
- Preferred IP sowie Access-Concentrator-/Service-Name leeren, wenn der Provider diese Werte nicht ausdrücklich vorgibt.
- Speichern und kontrollieren, ob das Interface eine IP-Adresse und ein Gateway erhält.
- DNS zuerst mit Test name lookup und danach von einem Client prüfen.
- Firewall-Regel, NAT und Log Viewer kontrollieren.
Für eine tiefere Diagnose in 5. Device Management > 3. Advanced Shell zuerst die Interface-Ereignisse beobachten:
tail -f /log/networkd.log
networkd.log zeigt Ereignisse zu physischen und virtuellen Interfaces. Das WAN-Gateway und mögliche Failover-Ereignisse stehen in dgd.log:
tail -f /log/dgd.log
Die laufende Ausgabe wird jeweils mit Ctrl+C beendet. Zusätzliche Systemmeldungen lassen sich in 4. Device Console mit einem lesenden Befehl anzeigen:
system diagnostics show syslog
pppd-Meldungen in der Ausgabe können Discovery-, Authentifizierungs- oder Sitzungsfehler sichtbar machen. Die genaue Fehlermeldung sollte zusammen mit Uhrzeit, Interface, Firmwareversion und einem erneuten Verbindungsversuch dokumentiert werden. Die Einordnung weiterer Dateien steht unter Sophos Firewall Service Logs.
Typische Muster:
- Keine PPPoE-Gegenstelle gefunden: Link, Bridge-/Passthrough-Modus, Provider-VLAN und optionaler Service-Name prüfen.
- Authentifizierung abgewiesen: Zugangsdaten, Zeichenlänge, Providerkonto und erlaubte Sitzungszahl prüfen.
- Sitzung wird aufgebaut und fällt wieder aus: Leitung, Providerereignisse, LCP und geplanten Reconnect einordnen.
- WAN-Adresse vorhanden, aber kein Internet: Gateway, DNS, Firewall-Regel, NAT und Routing prüfen.
- Nur grosse Pakete oder VPN-Traffic scheitern: MTU/MSS erst nach einem reproduzierbaren Test untersuchen.
MTU und MSS nicht pauschal ändern
PPPoE fügt zusätzlichen Overhead hinzu. Daraus folgt aber nicht, dass jede Verbindung manuell auf MTU 1492 oder MSS 1452 gesetzt werden muss. Standardwerte funktionieren in vielen Umgebungen, und zusätzliche VLANs, VPNs oder Providertechniken verändern den tatsächlichen Pfad.
Eine Anpassung ist erst sinnvoll, wenn beispielsweise kleine Pakete funktionieren, grosse HTTPS-Transfers hängen oder Packet Captures wiederholte Fragmentierungsprobleme zeigen. Die Messung und Berechnung steht unter MTU und MSS auf Sophos Firewall prüfen.
Multi-WAN, Dynamic DNS und HA
Ein aufgebauter PPPoE-Anschluss verhält sich im WAN Link Manager wie ein anderes physisches WAN-Gateway. Beim Reconnect oder Failover können sich jedoch die öffentliche Adresse und alle daran gebundenen Verbindungen ändern. Das betrifft insbesondere IPsec, DNAT, externe Allowlisten und Remote Access. Bei dynamischen Adressen hilft Dynamic DNS auf Sophos Firewall, ersetzt aber keinen Test der eingehenden Dienste.
Weist der Provider nur eine private oder gemeinsam genutzte CGNAT-Adresse zu, ist die Firewall aus dem Internet normalerweise nicht direkt erreichbar. Dynamic DNS aktualisiert lediglich den Namen und hebt CGNAT nicht auf. Für eingehende Dienste braucht es eine öffentliche beziehungsweise vom Provider weitergeleitete Adresse.
In einem Active-Passive-HA-Cluster ist PPPoE erlaubt, die bestehende PPPoE-Sitzung wird beim Failover aber nicht übernommen. Der neue Primary muss sie erneut aufbauen. Active-Active verlangt statische IP-Adressen auf allen Interfaces und unterstützt PPPoE deshalb nicht. Das physische Providerdesign muss ausserdem sicherstellen, dass beide Appliances den Anschluss nach einem Rollenwechsel erreichen können. Weitere Grenzen erklärt Sophos Firewall HA-Varianten.
IPv6 ist eine eigene Providerentscheidung. Wenn der Anschluss Prefix Delegation bereitstellt, zeigt IPv6 Prefix Delegation auf Sophos Firewall den separaten Aufbau.
Versionsabhängige Fehler ausschliessen
SFOS 22.0 MR2 Build 546 behebt mehrere PPPoE-Probleme aus GA und MR1, darunter Policy Test über PPPoE, Lizenzsynchronisierung in Active-Passive-HA und schlechte Upload-Performance durch eine zu kurze TX-Queue. MR2 behebt ausserdem einen Fehler, bei dem IPsec-Tunnel mit einer Alias-IP auf einem PPPoE-WAN aufgebaut wurden, aber keinen Traffic übertrugen.
Tritt eines dieser Symptome auf einer älteren SFOS-22-Version auf, sollte zuerst ein kontrolliertes Update auf eine aktuelle unterstützte Maintenance Release geplant werden. Die Vorbereitung beschreibt der SFOS-22-Upgrade-Check. Alte Workarounds wie das pauschale Abschalten der IPsec-Beschleunigung gehören nicht in eine neue Standardkonfiguration.