Hallo zusammen,
ich habe seit längerer Zeit Probleme mit sporadischen PPPoE-Abbrüchen auf meiner OPNsense-Firewall und hoffe auf Tipps aus der Community.
Setup:
- Anbieter: NetCologne (Deutschland)
- Anschluss: VDSL2, benötigt VLAN 7 für PPPoE
- Gebuchte Option: feste öffentliche IP-Adresse
- Bandbreite: 100/40 Mbit DSL-Profil
- Modem: DrayTek Vigor 167 im Full-Bridge-Modus (über separates Subnetz erreichbar, zeigt auch während der Ausfälle eine stabile DSL-Synchronisation mit Up-/Downstream)
- Firewall: OPNsense auf Intel i5 Appliance (igc0 = WAN, igc1 = LAN)
- WAN mit PPPoE konfiguriert:
- MTU: 1492
- MRU: aktuell nicht auf 1492 gesetzt (wahrscheinlich Default 1500)
- MSS Clamping: unsicher, ob aktiviert
- Idle Timeout: 0 (deaktiviert)
- LCP Echo aktiv (Intervall 10s, 5 Fehlversuche)
Problem:
Die PPPoE-Verbindung bricht in unregelmäßigen Abständen ab.
Manchmal läuft die Verbindung wochenlang stabil.
Dann gibt es wieder 2–3 Tage mit täglichen Abbrüchen, oder sogar mehrere Abbrüche am Tag.
Wenn der Fehler auftritt:Das Modem zeigt weiterhin stabile DSL-Synchronisation (Leitung ist up, Up-/Downstream aktiv).
OPNsense verliert jedoch die PPPoE-Session.
Wiederholte Verbindungsversuche schlagen fehl mit ,,PPPoE connection timeout after 9 seconds".
Es sieht so aus, als würde OPNsense PADIs senden, aber keine PADO-Antworten mehr erhalten.
Das Modem bleibt im Management-Subnetz erreichbar.
Ein Neustart der OPNsense behebt das Problem sofort.
Einen reinen Modem-Neustart habe ich in der Situation noch nicht getestet.
Wichtiger Hintergrund:
Dieses Problem habe ich schon seit längerer Zeit.
Unter pfSense 2.7.2 trat es mit identischem Verhalten regelmäßig auf.
Aufgrund dessen bin ich auf OPNsense umgestiegen – und dort lief die Verbindung zunächst über 60-80 Tage ohne einen einzigen Ausfall.
Ich dachte, das Problem sei damit gelöst – leider ist es seit ca. 4-6 Wochen erneut aufgetreten.
Auszug aus den Logs:
Aug 29 10:56:45 ppp: [wan_link0] LCP: no reply to 1 echo request
Aug 29 10:57:25 ppp: [wan_link0] LCP: no reply to 5 echo requests
Aug 29 10:57:25 ppp: [wan_link0] LCP: peer not responding to echo requests
Aug 29 10:57:25 ppp: [wan_link0] Link: Down event
Aug 29 10:57:25 ppp: [wan_link0] PPPoE connection lost
Aug 29 10:57:25 ppp: [wan_link0] PPPoE connection timeout after 9 seconds
Aug 29 10:57:34 ppp: [wan_link0] PPPoE connection timeout after 9 seconds
Aug 29 10:57:43 ppp: [wan_link0] PPPoE connection timeout after 9 seconds
Mein Verdacht:
Eventuell handelt es sich um eine ,,hängende PPPoE-Session" (Ghost Session) beim Provider, besonders da ich eine feste IP habe.
OPNsense (und auch pfSense früher) scheint die alte Session nicht sauber zu beenden, während ein kompletter Neustart das Problem sofort löst.
Zusätzlich könnten die falsche MRU (nicht auf 1492 gesetzt) und/oder fehlendes MSS Clamping eine Rolle spielen.
Meine Fragen an die Community:
Hat jemand von euch ähnliche PPPoE-Probleme (keine PADO-Antwort nach Disconnect) mit OPNsense oder pfSense erlebt?
Sollte man MRU explizit auf 1492 setzen, zusätzlich zur MTU?
Sollte MSS Clamping bei PPPoE-Verbindungen generell aktiviert sein?
Gibt es eine bewährte Lösung mit Monit/Cron/Watchdog, die automatisch PPPoE neu lädt, wenn keine PADO-Antwort kommt?
Könnte das Verhalten mit der festen IP von NetCologne zusammenhängen (Session-Handling beim Reconnect)?
Ich freue mich über jeden Hinweis oder Erfahrungsaustausch – vielen Dank schon einmal!
Viele Grüße
Was für eine Hardware? Oft genug haben Geräte Probleme mit Schlafzuständen, beispielsweise, wenn man ASPM nicht abgeschaltet hat. Das gilt auch für die ansonsten gut unterstützten Intel-Adapter. Das zeigt sich dann darin, dass die Netzwerkschnittstelle plötzlich "tot" ist.
Ich weiß nicht, ob ASPM abgeschaltet ist. Werde es aber auf jeden Fall prüfen und dann nochmal bescheid geben.
Folgende Hardware habe ich:
- IPU450 System 19 Zoll
- Intel Core i3-5005U 2,1 GHz Broadwell-U Dual Core mit Hyperthreading
- 3 MBytee L3 Cache
- 4x Intel i225-V (B3) 2,5 GBit/s LAN
- DDR3L-1600 SO-DIMM 8GB CL11
- 128GB mSATA SSD
PS: Seit dem Ausfall am 29. ist das Problem nicht mehr aufgetreten, aber es ist nur eine Frage der Zeit, bis es wieder auftritt.
Quote from: meyergru on August 29, 2025, 04:37:37 PMWas für eine Hardware? Oft genug haben Geräte Probleme mit Schlafzuständen, beispielsweise, wenn man ASPM nicht abgeschaltet hat. Das gilt auch für die ansonsten gut unterstützten Intel-Adapter. Das zeigt sich dann darin, dass die Netzwerkschnittstelle plötzlich "tot" ist.
Ich habe mit dem Lieferanten des IPU Boards Rücksprache gehalten. Er konnte mir bestätigen, dass ASPM standardmäßig nicht deaktiviert ist und erwähnte außerdem auch, dass es sich um ein bekanntes Problem mit Intel-Adaptern unter FreeBSD handelt und zu mehr als 90% meist die Lösung darstellt.
Gestern habe ich im BIOS die allgemeine ASPM-Funktion sowie ASPM an allen Root-Ports deaktiviert. Ich werde das die nächsten Wochen/ Monate beobachten in der Hoffnung, dass der Fehler nicht mehr auftritt und im Anschluss Bericht erstatten.
Danke für die Hilfe!