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 Passwort beziehungsweise die exakte Authentifizierungsvorgabe des Providers
• 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

Die Sophos-Hilfe sieht Benutzername und Passwort des PPPoE-Kontos vor. Liefert der Provider davon abweichende Vorgaben, müssen diese vor dem Wartungsfenster bestätigt werden; ein leeres Passwort sollte man nicht auf Verdacht verwenden. 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.

1. Network > Interfaces öffnen.
2. Beim vorgesehenen WAN-Port das Menü öffnen und Edit interface wählen.
3. Einen eindeutigen Namen wie WAN-PPPoE und die Zone WAN setzen.
4. IPv4 aktivieren und als IP assignment den Wert PPPoE wählen.
5. Unter Username beispielsweise firma@example.net und unter Password die zugehörigen Providerwerte eintragen. Keine realen Zugangsdaten in Screenshots oder Tickets übernehmen.
6. Preferred IP leer lassen, wenn der Provider keine feste PPPoE-Adresse vorgegeben hat.
7. Einen verständlichen Gateway name wie gw-pppoe vergeben und beim physischen PPPoE-Interface die vom Provider verlangte Gateway IP address eintragen. Bei einem PPPoE-VLAN ist dieses Feld dagegen eine Anzeige der konfigurierten Gateway-Adresse.
8. Access concentrator/service name leer lassen, sofern der Provider keinen exakten Namen verlangt.
9. LCP echo interval auf 20 Sekunden und LCP failure auf 3 belassen.
10. Einen geplanten Reconnect nur aktivieren, wenn der Provider oder der Betrieb dies verlangt.
11. Falls der Provider für PPPoE ein VLAN fordert, eine der im nächsten Abschnitt beschriebenen Varianten wählen.
12. 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. Zudem können Interface-Änderungen von DNS, Gateway, SD-WAN, Interface-Hosts, VLANs und Dynamic DNS abhängige Konfigurationen beeinflussen. Off erhält die Interface-Konfiguration; ein gelöschtes virtuelles Interface kann dagegen abhängige Regeln und Objekte mit entfernen.

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 den Status Connected und eine zugewiesene Adresse zeigen. Connecting bedeutet, dass noch eine Adresse bezogen wird; Disconnected bedeutet, dass sie freigegeben wurde. Das zugehörige physische WAN-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:

1. Erreichbarkeit einer externen IP-Adresse.
2. Auflösung eines DNS-Namens.
3. Aufruf einer HTTPS-Seite.
4. Eine für den Betrieb wichtige Anwendung.
5. 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.

Wenn Log Viewer nicht eindeutig zeigt, wo der Pfad endet, lässt sich unter Diagnostics > Packet capture ein enger Filter auf IP-Adresse und Protokoll des Testclients setzen. Für weitergeleitete Pakete müssen In interface, Out interface, Rule ID, NAT ID, Status und Gateway ID zum geplanten Pfad passen. Die Anzeige bestätigt nur die tatsächlich erfassten Pakete; der Capture-Puffer ist auf 2048 KB begrenzt und stoppt ohne aktiviertes Überschreiben, sobald er voll ist.

Bei einer fehlgeschlagenen Umstellung zurückkehren

Kommt keine PPPoE-Sitzung zustande, wird über den unabhängigen Adminzugang auf den dokumentierten Vorzustand zurückgekehrt. Bei einem zusätzlichen PPPoE-VLAN wird dieses zunächst auf Off gestellt; so bleibt seine Konfiguration für die Fehleranalyse erhalten. Danach Providergerät und bisherigen statischen oder per DHCP bezogenen WAN-Pfad samt Gateway und DNS reaktivieren. Wurde stattdessen der physische Port selbst geändert, werden dessen zuvor gesicherte Werte wiederhergestellt. Ein PPPoE-VLAN nicht vorschnell löschen: Das Löschen virtueller Interfaces kann abhängige Firewall-Regeln und weitere Konfiguration entfernen. Erst wenn Interface, Gateway, DNS und ein echter Clienttest auf dem alten Pfad wieder funktionieren, wird weiter an PPPoE gearbeitet.

PPPoE-Fehler systematisch eingrenzen

Zuerst werden Leitung und Konfiguration geprüft, erst danach MTU oder weitere Spezialwerte:

1. Linkstatus, Modem- beziehungsweise ONT-Synchronisation, Verkabelung und Bridge-/Passthrough-Modus kontrollieren.
2. Provider-VLAN mit den Vertragsdaten vergleichen und sicherstellen, dass es nicht gleichzeitig per VDSL-Option und manuellem VLAN gesetzt wurde.
3. Benutzername, optionales Passwort und Gross-/Kleinschreibung exakt prüfen.
4. Preferred IP sowie Access-Concentrator-/Service-Name leeren, wenn der Provider diese Werte nicht ausdrücklich vorgibt.
5. Speichern und kontrollieren, ob das Interface eine IP-Adresse und ein Gateway erhält.
6. DNS zuerst mit Test name lookup und danach von einem Client prüfen.
7. 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

Die offizielle Logzuordnung belegt networkd.log für physische und virtuelle Interfaces sowie dgd.log für WAN-Link-, Gateway- und Failover-Ereignisse. system diagnostics show syslog zeigt ergänzende Systemmeldungen, liefert aber nicht automatisch eine vollständige PPPoE-Ursachenanalyse. Die genaue Meldung sollte zusammen mit Uhrzeit, Interface, Firmwareversion und einem erneuten Verbindungsversuch dokumentiert werden. Fehlt in diesen Quellen die Ursache, folgt ein enger Packet Capture des reproduzierbaren Tests; 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, Session failover findet laut Sophos aber nicht statt. Der neue Primary muss die Providerverbindung daher erneut aufbauen. Die dedizierte HA-Verbindung und beide Administrationsports benötigen statische Adressen. Active-Active verlangt statische IP-Adressen auf allen Interfaces und unterstützt ein PPPoE-WAN 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 MR1 Build 490 behebt mehrere klar benannte PPPoE-Probleme: NC-174437 für Policy Test über PPPoE, NC-173201 für Lizenzsynchronisierung in Active-Passive-HA mit PPPoE und NC-167806 für Paketverluste und schlechte Upload-Performance bei einer TX-Queue-Länge von 3. Die Sophos Known Issues führen ausserdem NC-181526 als in MR2 Build 546 gelöst: Auf XGS-Hardware ausser XGS 88/88w, 108/108w, 118/118w und 128/128w konnten IPsec-Tunnel über eine Alias-IP eines PPPoE-WAN in GA und MR1 zwar aufbauen, aber bei aktivierter IPsec-Beschleunigung keinen Traffic übertragen.

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.

FAQ