Hallo,

ich habe gestern im Zuge der Umstellung meines Zugangs von Complete Comfort auf Magenta anstelle meines ADSL-Anschlusses einen VDSL-Anschluß bekommen. Im Zuge dessen mußte ich natürlich auch meine Infrastruktur umstellen.

Bis gestern hing am nun ehemaligen ISDN-Anschluß ein Splitter, gefolgt von einem ADSL-Modem, an dessen Ethernet-Port wiederum ein Port meiner Juniper SRX240 die PPPoE-Terminierung erledigte. Dies funktionierte jahrelang einwandfrei.

Bei der gestrigen Umstellung fiel der Splitter weg, stattdessen befindet sich an der Telefonleitung direkt ein Draytek Vigor 130 (im Bridge-Modus) und an diesem wiederum die Juniper SRX240.

Nach der Umschaltung synchronisierte der Draytek einwandfrei (DSL-Kontrolleuchte brennt dauerhaft). Ethernet-Verbindung zur Juniper ist gegeben, aber die PPPoE-Verbindung wird nicht aufgebaut. Laut Anschreiben der Telekom vor der Umstellung sollten die Zugangsdaten gleich bleiben, also habe ich diese auch 1:1 auf die neue Konfiguration übernommen. Auf dem Ethernet-Interface habe ich VLAN-Tagging eingeschaltet und die VLAN-ID 7 konfiguriert.

Anzumerken ist, daß mein Login gemäß einer früheren Konfiguration aus 12 Stellen Anschlußkennung + 12 Stellen T-Online-Nummer (oder wie auch immer die jetzt heißt) + "#" + 4 Stellen Mitbenutzerkennung + "@t-online.de" besteht. Nach neueren Hinweisen ist das "#" bei 12-stelligen T-Online-Nummern obsolet.

Beim Verbindungsaufbau spricht die Juniper laut Interface-Monitor mit der Gegenstelle in Frankfurt, bekommt eine CHAP-Challenge und sendet eine Response zurück, diese wird aber abgewiesen:

17:18:57.103819 Out PPPoE  [ses 25382]LCP, Conf-Request (0x01), id 2, length 16
17:18:57.116103  In PPPoE  [ses 25382]LCP, Conf-Ack (0x02), id 2, length 16
17:18:57.116665  In PPPoE  [ses 25382]LCP, Conf-Request (0x01), id 1, length 20
17:18:57.116990 Out PPPoE  [ses 25382]LCP, Conf-Nack (0x03), id 1, length 11
17:18:57.137314  In PPPoE  [ses 25382]LCP, Conf-Request (0x01), id 2, length 21
17:18:57.137976 Out PPPoE  [ses 25382]LCP, Conf-Ack (0x02), id 2, length 21
17:18:57.151243  In PPPoE  [ses 25382]CHAP, Challenge (0x01), id 1, Value fe9894c3eecadc35f0f4273382e32c93, Name FFMA43-a1
17:18:57.154383 Out PPPoE  [ses 25382]CHAP, Response (0x02), id 1, Value 233be355f2c312f2cfd06a5dde49e1d4, Name xxxxxxxxxxxxxxxxxxxxxxx[|chap]
17:18:57.172063  In PPPoE  [ses 25382]LCP, Term-Request (0x05), id 3, length 6
17:18:57.172167  In PPPoE  [ses 25382]CHAP, Fail (0x04), id 1, Msg 0023 STPR3AU  0000000000 login lock
17:18:57.172374 Out PPPoE  [ses 25382]LCP, Term-Ack (0x06), id 3, length 6

Ein Anruf bei der Hotline erbrachte zwar ein freundliches Gespräch mit einer sehr netten jungen Dame, aber leider keine Lösung. Sie riet mir mehrfach dazu, doch einfach den Router zu rebooten (was ich aus verschiedenen Gründen ablehnte), schickte mir ein neues Paßwort (das auch nicht funktionierte) und meinte auf Nachfrage, der Account sei definitv nicht gesperrt.

Nun bin ich eher geneigt, dem RADIUS -Server der Telekom zu glauben als der jungen Dame, und der sagt nunmal 'login lock' auf meine CHAP-Authentifizierung.

Meine Fragen:

1. Kann ich angesichts der Tatsache, daß ein CHAP-Dialog stattfindet, davon ausgehen, daß bis zum Ethernet-Interface der Juniper (einschließlich VLAN-Tagging) alles sauber ist?

2. Deutet das 'login lock', wie ich annehme, auf eine Sperre des Accounts hin und wo kann ich diesen ggf. zurücksetzen lassen? Geht die Sperre ggf. nach einiger Zeit von selbst weg?

3. Kann das "#" in der aus der alten Konfiguration übernommenen Anschlußkennung den Login-Fehler und letztlich die Sperre des Accounts verursacht haben? Etwas anderes fällt mir im Moment nicht ein.

4. Übersehe ich etwas anderes?

Viele Grüße und vielen Dank im Voraus für jeden Tip.