Moin,
heute morgen hatten wir das Problem, das unsere PPPoE-Verbindung zu unserem Provider plötzlich down war. In der Adminoberfläche war das entsprechende Status der Verbindung in der UTM down (grau).
Ich habe aus der Not heraus die UTM neu gestartet. Nach dem Neustart war die PPPoE-Verbindung zum Provider dann wieder da. Das Hinterlässt aber einen extrem faden Beigeschmack bei mir. Wenn jetzt keiner aus der EDV hier im Hause gewesen wäre, hätte die Fa. kein Internet mehr gehabt. Und von außen hätte ich mich dann logischerweise auch nicht mehr einwählen können...
1. Wie kann ich manuell die PPPoE-Verbindung über die Adminoberfläche der UTM herstellen?
2. Warum wurde die PPPoE-Verbindung nicht automatisch durch die UTM neu hergestellt? Wie muss PPPoE in der UTM V11 konfiguriert sein, damit die Verbindung automatisch wieder hergestellt wird?
3. Wir setzen einen UTM-Cluster ein. Warum ist der Cluster nicht angesprungen und hat auf die 2. UTM umgeschaltet? Kann man irgendwo einstellen, dass bei fehlender PPPoE-Verbindung die 2. UTM anspringt?
Gruß
Dirk
PPPoE Verbindung / UTM Cluster
Moderator: Securepoint
-
monstermania
- Beiträge: 40
- Registriert: Do 27.03.2014, 12:44
- Wohnort: Hamburg
Hallo Dirk,
Einmal zu deinen Fragen:
1.: Zu einem manuellen Neustart eines Interfaces (und damit verbundenem reconnect) reicht unter Netzwerk -> Netzwerkkonfiguration, ein Bearbeiten und Speichern der entsprechenden Schnittstelle.
2.: Damit nach einer Störung oder Zwangstrennung die Verbindung automatisch wieder hergestellt wird (oder es zumindest dauerhaft versucht wird) muss im PPPoE-Interface der Haken bei Link Control Protocol gesetzt sein. Warum die Verbindung nicht wieder neu aufgebaut werden konnte ließe sich im nachhinein nur durch, auf einem Logserver gespeichert/archivierten, Logs nachvollziehen. (Hierfür kann z.B. das SOC verwendet werden.) Gesucht ist dann der Dienst pppd.
3.: Ein Ausfall einer PPPoE-Verbindung führt deshalb nicht zu einem Wechsel, da das physikalische Interface weiterhin UP ist. Das Umswitchen von Master auf Spare soll nur erfolgen wenn in irgendeiner Weise ein Hardware-Defekt vorliegt. (Zum Bsp. wenn ein Interface kaputt ist.) Um bei einem Internetausfall eine Redundanz zu erzeugen muss die Funktion "Fallback" verwendet werden, die bei einem Ausfall einer Leitung dafür sorgt, das Routen sowie Zonen auf eine Backup-Internetleitung umswitchen. Diese Funktion ist allerdings unabhängig vom Cluster zu betrachten und einzurichten. (Benötigt zudem 2 vorhandene Internetanschlüsse)
Gruss
Marcel
Einmal zu deinen Fragen:
1.: Zu einem manuellen Neustart eines Interfaces (und damit verbundenem reconnect) reicht unter Netzwerk -> Netzwerkkonfiguration, ein Bearbeiten und Speichern der entsprechenden Schnittstelle.
2.: Damit nach einer Störung oder Zwangstrennung die Verbindung automatisch wieder hergestellt wird (oder es zumindest dauerhaft versucht wird) muss im PPPoE-Interface der Haken bei Link Control Protocol gesetzt sein. Warum die Verbindung nicht wieder neu aufgebaut werden konnte ließe sich im nachhinein nur durch, auf einem Logserver gespeichert/archivierten, Logs nachvollziehen. (Hierfür kann z.B. das SOC verwendet werden.) Gesucht ist dann der Dienst pppd.
3.: Ein Ausfall einer PPPoE-Verbindung führt deshalb nicht zu einem Wechsel, da das physikalische Interface weiterhin UP ist. Das Umswitchen von Master auf Spare soll nur erfolgen wenn in irgendeiner Weise ein Hardware-Defekt vorliegt. (Zum Bsp. wenn ein Interface kaputt ist.) Um bei einem Internetausfall eine Redundanz zu erzeugen muss die Funktion "Fallback" verwendet werden, die bei einem Ausfall einer Leitung dafür sorgt, das Routen sowie Zonen auf eine Backup-Internetleitung umswitchen. Diese Funktion ist allerdings unabhängig vom Cluster zu betrachten und einzurichten. (Benötigt zudem 2 vorhandene Internetanschlüsse)
Gruss
Marcel
-
monstermania
- Beiträge: 40
- Registriert: Do 27.03.2014, 12:44
- Wohnort: Hamburg
Danke Marcel,
die von Dir genannte Option in der PPPoE-Einwahl 'Link-Control-Protokoll' ist gesetzt. Trotzdem hat die UTM keine PPPoE-Verbindung hergestellt.
Ich muss dazu sagen, dass wir erst seit ca. 6 Wochen die SP UTM einsetzten. Und leider hatten wir massive Probleme mit der Kompetenz unseres Fachhändlers was die Ersteinrichtung der SP UTM anging. Derzeit schauen wir gerade nach einer anderen Möglichkeiten zur Betreuung der SP UTM. Ich habe also derzeit niemanden außer das Forum, den ich mit meinen Fragen nerven kann.
Aber zurück zum Thema. Wie funktioniert die PPPoE-Einwahl genau?
Du hast was vom 'pppd'-Dienst geschrieben. Wo kann ich sehen, ob dieser Dienst auf der UTM läuft? Im Fenster Anwendungsstatus finde ich den Dienst jedenfalls nicht.
Hat die SP UTM keinen 'Watchdog' der prüft, ob ein Dienst noch reagiert und einen Dienst ggf. neu startet?
Ich kenne so etwas von unserer alten Lösung. Wenn dort ein Dienst der UTM (z.B. Proxy) nicht mehr reagiert hat wurde der Dienst automatisch neu gestartet (darüber wurde man dann auch per Email informiert).
Kann man den Status der PPPoE-Verbindung oder den Status der Dienste auf der SP UTM abfragen (z.B. per snmp)?
Ich habe Angst, dass so etwas mal am WE passiert. Dann habe ich nämlich ein echtes Problem, wenn sich niemand mehr per VPN ins Netz einwählen kann! Mit unserer alten Lösung hatten wir nie ein Problem mit der PPPoE-Verbindung.
Gruß
Dirk
die von Dir genannte Option in der PPPoE-Einwahl 'Link-Control-Protokoll' ist gesetzt. Trotzdem hat die UTM keine PPPoE-Verbindung hergestellt.
Ich muss dazu sagen, dass wir erst seit ca. 6 Wochen die SP UTM einsetzten. Und leider hatten wir massive Probleme mit der Kompetenz unseres Fachhändlers was die Ersteinrichtung der SP UTM anging. Derzeit schauen wir gerade nach einer anderen Möglichkeiten zur Betreuung der SP UTM. Ich habe also derzeit niemanden außer das Forum, den ich mit meinen Fragen nerven kann.
Aber zurück zum Thema. Wie funktioniert die PPPoE-Einwahl genau?
Du hast was vom 'pppd'-Dienst geschrieben. Wo kann ich sehen, ob dieser Dienst auf der UTM läuft? Im Fenster Anwendungsstatus finde ich den Dienst jedenfalls nicht.
Hat die SP UTM keinen 'Watchdog' der prüft, ob ein Dienst noch reagiert und einen Dienst ggf. neu startet?
Ich kenne so etwas von unserer alten Lösung. Wenn dort ein Dienst der UTM (z.B. Proxy) nicht mehr reagiert hat wurde der Dienst automatisch neu gestartet (darüber wurde man dann auch per Email informiert).
Kann man den Status der PPPoE-Verbindung oder den Status der Dienste auf der SP UTM abfragen (z.B. per snmp)?
Ich habe Angst, dass so etwas mal am WE passiert. Dann habe ich nämlich ein echtes Problem, wenn sich niemand mehr per VPN ins Netz einwählen kann! Mit unserer alten Lösung hatten wir nie ein Problem mit der PPPoE-Verbindung.
Gruß
Dirk
Hallo Dirk,
Zuerst einmal zu der PPPoE-Einwahl. Diese erfolgt in folgenden Schritten:
1.: PADI (PPPoE Active Discovery Initiation)
Möchte sich ein Internetnutzer über DSL einwählen, so muss der Client (in diesem Fall die Firewall) erst einmal feststellen, ob ein DSL Access Concentrator (DSL-AC) vorhanden ist. Eine Kommunikation ist nur über die MAC-Adressen möglich. Da aber die Firewall, die MAC-Adresse des DSL-AC nicht kennt, sendet sie das PADI-Paket über einen Ethernet-Broadcast (MAC: ff:ff:ff:ff:ff:ff). Das PADI-Paket enthält natürlich die MAC des Absenders.
2.: PADO (PPPoE Active Discovery Offer)
Nachdem die Firewall das PADI-Paket gesendet hat, schickt der DSL-AC ein PADO-Paket. Das ist möglich, da der DSL-AC die Absenderadresse mit dem PADI-Paket bekommen hat. Das PADO-Paket enthält die MAC-Adresse des DSL-AC, seinen Namen sowie die Dienstbezeichnung. Senden mehrere DSL-AC ein PADO-Paket, so wählt ddie Firewall einen DSL-AC über den Namen oder den Dienst aus.
Sollte an dieser Stelle schon kein PADO-Packet von einem DSL-AC zurückkommen wird dies in der Firewall im LIVE-LOG mit einer Timeout waiting for PADO unter dem Dienst pppd angezeigt. Dies kann passieren wenn das vorgeschaltete Modem nicht gesyct ist oder der Anbieter z.B. den Anschluss vorrübergehend gesperrt hat (auf Grund von zu vielen hinter einander erfolgten Fehlversuchen etc.).
3.: PADR (PPPoE Active Discovery Request)
Wie schon erwähnt, muss die Firewall nun einen DSL-AC auswählen. Das erfolgt mit dem PADR-Paket, das an die MAC-Adresse des DSL-AC gesendet wird.
4.: PADS (PPPoE Active Discovery Session-confirmation)
Das PADR-Paket wird vom DSL-AC mit dem PADS-Paket bestätigt sowie eine Session-ID vergeben. Die Verbindung ist mit dem DSL-AC nun aufgebaut und kann verwendet werden.
Im weiteren Verlauf tauschen Firewall und DSL-AC über PPP LCP Informationen aus. Zum Beispiel eine MRU von 1492 Bytes.
Danach informiert der DSL-AC die Firewall über sein Authentication Protocol. Dies kann PAP (unverschlüsselt) oder CHAP sein. Darauf erfolgt dann die Benutzeranmeldung mit den Zugangsdaten.
Schlägt diese Anmeldung fehl wird von der Gegenstelle ein PAP oder CHAP Authentication failed zurück-gemeldet. Dies ist dann auch im LOG der Firewall ebenfalls unter dem Dienst pppd zu sehen.
Nach erfolgreicher Anmeldung bekommt der Router eine IP-Adresse und die Adressen von DNS-Servern mitgeteilt. Ab dieser Stelle ist ein Zugriff auf das Internet möglich.
LCP Echo
Ist der Haken bei LCP im Interface der Firewall gesetzt so wird nach dem erfolgreichen Aufbau der Verbindung ein LCP Echo Request an den DSL-AC gesendet, um die Verbindung in bestimmten Abständen zu überprüfen. Dieser wird mit einem Echo Reply beantwortet. Sollte auf mehrere hinter einander folgende Requests nichts zurück kommen wird die Firewall eigenständig mit dem folgenden Paket die Verbindung beenden und sie danach wieder neu initiiren.
Dies wird im LOG durch die LCP-Echo Timeout Meldung ebenfalls vom pppd angezeigt.
5.: PADT (PPPoE Active Discovery Termination)
Das Paket hat die Aufgabe, die Verbindung zum DSL-AC zu trennen. Es kann vom der Firewall wie auch vom DSL-AC gesendet werden.
Auf der Firewall ist im Moment noch kein "Watchdog" implementiert. Dies ist bei uns als Feature-Request aber bereits erfasst und auf die TO-DO-Liste gesetzt. Der Status des pppd Dienstes lässt sich derzeit nur via "root"-User über einen ssh-Zugang ermitteln. Leichter ist es, dass Interface pppX zu bearbeiten und gleich wieder zu Speichern. Danach sollten sie die Einwahl (fals diese nicht bereits besteht) im LIVE-LOG verfolgen können.
Zudem hier einmal die Liste der OIDs für SNMP: http://wiki.securepoint.de/index.php/SNMP_OIDs
Grüsse
Marcel
Zuerst einmal zu der PPPoE-Einwahl. Diese erfolgt in folgenden Schritten:
1.: PADI (PPPoE Active Discovery Initiation)
Möchte sich ein Internetnutzer über DSL einwählen, so muss der Client (in diesem Fall die Firewall) erst einmal feststellen, ob ein DSL Access Concentrator (DSL-AC) vorhanden ist. Eine Kommunikation ist nur über die MAC-Adressen möglich. Da aber die Firewall, die MAC-Adresse des DSL-AC nicht kennt, sendet sie das PADI-Paket über einen Ethernet-Broadcast (MAC: ff:ff:ff:ff:ff:ff). Das PADI-Paket enthält natürlich die MAC des Absenders.
2.: PADO (PPPoE Active Discovery Offer)
Nachdem die Firewall das PADI-Paket gesendet hat, schickt der DSL-AC ein PADO-Paket. Das ist möglich, da der DSL-AC die Absenderadresse mit dem PADI-Paket bekommen hat. Das PADO-Paket enthält die MAC-Adresse des DSL-AC, seinen Namen sowie die Dienstbezeichnung. Senden mehrere DSL-AC ein PADO-Paket, so wählt ddie Firewall einen DSL-AC über den Namen oder den Dienst aus.
Sollte an dieser Stelle schon kein PADO-Packet von einem DSL-AC zurückkommen wird dies in der Firewall im LIVE-LOG mit einer Timeout waiting for PADO unter dem Dienst pppd angezeigt. Dies kann passieren wenn das vorgeschaltete Modem nicht gesyct ist oder der Anbieter z.B. den Anschluss vorrübergehend gesperrt hat (auf Grund von zu vielen hinter einander erfolgten Fehlversuchen etc.).
3.: PADR (PPPoE Active Discovery Request)
Wie schon erwähnt, muss die Firewall nun einen DSL-AC auswählen. Das erfolgt mit dem PADR-Paket, das an die MAC-Adresse des DSL-AC gesendet wird.
4.: PADS (PPPoE Active Discovery Session-confirmation)
Das PADR-Paket wird vom DSL-AC mit dem PADS-Paket bestätigt sowie eine Session-ID vergeben. Die Verbindung ist mit dem DSL-AC nun aufgebaut und kann verwendet werden.
Im weiteren Verlauf tauschen Firewall und DSL-AC über PPP LCP Informationen aus. Zum Beispiel eine MRU von 1492 Bytes.
Danach informiert der DSL-AC die Firewall über sein Authentication Protocol. Dies kann PAP (unverschlüsselt) oder CHAP sein. Darauf erfolgt dann die Benutzeranmeldung mit den Zugangsdaten.
Schlägt diese Anmeldung fehl wird von der Gegenstelle ein PAP oder CHAP Authentication failed zurück-gemeldet. Dies ist dann auch im LOG der Firewall ebenfalls unter dem Dienst pppd zu sehen.
Nach erfolgreicher Anmeldung bekommt der Router eine IP-Adresse und die Adressen von DNS-Servern mitgeteilt. Ab dieser Stelle ist ein Zugriff auf das Internet möglich.
LCP Echo
Ist der Haken bei LCP im Interface der Firewall gesetzt so wird nach dem erfolgreichen Aufbau der Verbindung ein LCP Echo Request an den DSL-AC gesendet, um die Verbindung in bestimmten Abständen zu überprüfen. Dieser wird mit einem Echo Reply beantwortet. Sollte auf mehrere hinter einander folgende Requests nichts zurück kommen wird die Firewall eigenständig mit dem folgenden Paket die Verbindung beenden und sie danach wieder neu initiiren.
Dies wird im LOG durch die LCP-Echo Timeout Meldung ebenfalls vom pppd angezeigt.
5.: PADT (PPPoE Active Discovery Termination)
Das Paket hat die Aufgabe, die Verbindung zum DSL-AC zu trennen. Es kann vom der Firewall wie auch vom DSL-AC gesendet werden.
Auf der Firewall ist im Moment noch kein "Watchdog" implementiert. Dies ist bei uns als Feature-Request aber bereits erfasst und auf die TO-DO-Liste gesetzt. Der Status des pppd Dienstes lässt sich derzeit nur via "root"-User über einen ssh-Zugang ermitteln. Leichter ist es, dass Interface pppX zu bearbeiten und gleich wieder zu Speichern. Danach sollten sie die Einwahl (fals diese nicht bereits besteht) im LIVE-LOG verfolgen können.
Zudem hier einmal die Liste der OIDs für SNMP: http://wiki.securepoint.de/index.php/SNMP_OIDs
Grüsse
Marcel