Probleme mit PPPOE über WLAN
Moderator: Lancom-Systems Moderatoren
-
- Beiträge: 16
- Registriert: 28 Nov 2006, 00:32
Probleme mit PPPOE über WLAN
Hallo Ihr.
Bin fast am verzweifeln weil ich nun einfach nicht mehr weiter weiß und hoffe ihr könnt mir helfen. Habe bereits alle gefundenen Dokumente, Forumeinträge und Dokumente aus der Knowledgebase entnommen aber dennoch nicht am Zeil angekommen.
Besitze einen L-54ag.
Konfiguration:
DMZ-IP: 192.168.24.21
DMZ-Interface: WLAN
IP-Adressenvergabe manuell.
Intranet-IP: 192.168.23.21
Intranet-Interface: LAN
IP-Adressenvergabe manuell.
geroutet wird alles auf meine Fritz!Box ( 192.168.23.30 )
und diese übernimmt den Verkehr im 192.168.23.0/27 Netz und
ins Internet.
Wireless Interface und LAN Interface im isolierten Modus und werden wie gewünscht geroutet.... also Internet und Firewall Richtlinien funktionieren so weit.
Bekomme aber keinen PPPOE Server zum laufen.
Habe folgende Konstellation
192.168.23.0/27 | FRITZ!BOX - - - - LANCOM L-54ag - Antenne
(( FUNK ))
192.168.24.0/24 | Antenne - AP (als client bzw bridge) - - - - LAN Client(s)
Möchte mich nun Gerne mit den (LAN)-Clients im 192.168.24.0/24 Netz per PPPOE Einwahl am Lancom einloggen um dann Internetdienste nutzen zu können die zuvor durch eine DENY-ALL Regel blockiert waren. Regeln wurden alle eingerichtet und Funktionieren nur die PPPOE einwahl funzt nicht.
KA wieso.
Unter Adressen wurde der Adresspool eingegeben fürr die Einwahl Zugänge. DNS und Gateway wurden auch hinterlegt.
Bin fast am verzweifeln weil ich nun einfach nicht mehr weiter weiß und hoffe ihr könnt mir helfen. Habe bereits alle gefundenen Dokumente, Forumeinträge und Dokumente aus der Knowledgebase entnommen aber dennoch nicht am Zeil angekommen.
Besitze einen L-54ag.
Konfiguration:
DMZ-IP: 192.168.24.21
DMZ-Interface: WLAN
IP-Adressenvergabe manuell.
Intranet-IP: 192.168.23.21
Intranet-Interface: LAN
IP-Adressenvergabe manuell.
geroutet wird alles auf meine Fritz!Box ( 192.168.23.30 )
und diese übernimmt den Verkehr im 192.168.23.0/27 Netz und
ins Internet.
Wireless Interface und LAN Interface im isolierten Modus und werden wie gewünscht geroutet.... also Internet und Firewall Richtlinien funktionieren so weit.
Bekomme aber keinen PPPOE Server zum laufen.
Habe folgende Konstellation
192.168.23.0/27 | FRITZ!BOX - - - - LANCOM L-54ag - Antenne
(( FUNK ))
192.168.24.0/24 | Antenne - AP (als client bzw bridge) - - - - LAN Client(s)
Möchte mich nun Gerne mit den (LAN)-Clients im 192.168.24.0/24 Netz per PPPOE Einwahl am Lancom einloggen um dann Internetdienste nutzen zu können die zuvor durch eine DENY-ALL Regel blockiert waren. Regeln wurden alle eingerichtet und Funktionieren nur die PPPOE einwahl funzt nicht.
KA wieso.
Unter Adressen wurde der Adresspool eingegeben fürr die Einwahl Zugänge. DNS und Gateway wurden auch hinterlegt.
Hi,
ich werde aus der beschriebenen Konstallation nicht schlau, vermute aber, dass du deine Netze segmentiert (also ein Router zwischen den Netzen ist)hast und dementsprechend kein Layer-2 Produkt wie es PPPoE nunmal ist mehr funktioniert. Mit reinem Briding wuerde es funktionieren, sodass alles auf einem "Strang" transparent ist oder du nutzt den internen PPPoE-Server deines AP, mit ueber dne sich deine Clients ins WLAN einloggen.
ich werde aus der beschriebenen Konstallation nicht schlau, vermute aber, dass du deine Netze segmentiert (also ein Router zwischen den Netzen ist)hast und dementsprechend kein Layer-2 Produkt wie es PPPoE nunmal ist mehr funktioniert. Mit reinem Briding wuerde es funktionieren, sodass alles auf einem "Strang" transparent ist oder du nutzt den internen PPPoE-Server deines AP, mit ueber dne sich deine Clients ins WLAN einloggen.
12x 1621 Anx. B-21x 1711 VPN-3x 1722 Anx. B-7x 1723 VoIP-1x 1811 DSL, 1x 7011 VPN-1 x 7111 VPN-1x 8011 VPN-10er Pack Adv. VPN Client (2x V1.3-3x 2.0)-Hotspot Option-Adv. VoIP Client/P250 Handset-Adv.VoIP Option-4x VPN-Option-2x L-54 dual-2x L54ag-2x O-18a
-
- Beiträge: 16
- Registriert: 28 Nov 2006, 00:32
Hi Blackplanet000
- ist sichergestellt, daß die APs PPPoE auch durchlassen?
- hast du im LANCOM die PCs mit ihren MAC-Adressen im PPPoE-Server eingetragen?
- falls nicht: hast du einen Default-Eintrag mit MAC-Adresse 000000000000 eingetragen?
- was sagt ein PPP-Trace, wenn ein Client versucht sich einzuwählen?
Gruß
Backslash
- ist sichergestellt, daß die APs PPPoE auch durchlassen?
- hast du im LANCOM die PCs mit ihren MAC-Adressen im PPPoE-Server eingetragen?
- falls nicht: hast du einen Default-Eintrag mit MAC-Adresse 000000000000 eingetragen?
- was sagt ein PPP-Trace, wenn ein Client versucht sich einzuwählen?
Gruß
Backslash
-
- Beiträge: 16
- Registriert: 28 Nov 2006, 00:32
danke für deine antwort. habe in meinen aps nichts geperrt also sodasss eigentlich alles durchgelassen werden sollte. hab mich testweise auch schon direkt zum lancom verbunden mit meinem notebook um den ap als feherquelle auszuschliesen. geht auch so nichts.... der default eintrag damit jede mac zugelassen wird ist eigetragen. wie kann ich ein ppp-trace starten?
thx
thx
-
- Beiträge: 16
- Registriert: 28 Nov 2006, 00:32
gut thx habs geschafft, aber mir isses nicht ganz verständlich
habe im pppoe server das session limit auf 1 gesetzt weil sich jeder nur einmal einloggen darf.
dann sagt er aber im trace das die session anzahl schon überschritten ist.... bin aber nicht eingewählt........ wird schon das alleinige connecten zum ap als session gewertet?
habe im pppoe server das session limit auf 1 gesetzt weil sich jeder nur einmal einloggen darf.
dann sagt er aber im trace das die session anzahl schon überschritten ist.... bin aber nicht eingewählt........ wird schon das alleinige connecten zum ap als session gewertet?
-
- Beiträge: 16
- Registriert: 28 Nov 2006, 00:32
Hallo,
ich muss das Session-Limit auch immer auf zwei setzen, damit ich eine Verbindung (die Einzig erlaubte) aufbauen kann.
Ferner gibt mir der WinXP PPPoE-CLient nach dem Disconnect immer einen fehler aus.
Die Verbindung mit "xxx" konnte nicht hergestellt werden. Es wird versucht, die Verbindung nochmals herzustellen...
Vielleicht musst du an den Prioritaeten der FW-Regeln "schrauben".
Hier mein trace dazu:
[PPP] 2006/11/29 13:02:38,300
Received PADR frame from peer 00:e0:7d:7f:b2:bd for session 0000
PPPoE control channel: session limit exceeded for 00:e0:7d:xx:xx:xx
und beim Session-Limit 2:
[PPP] 2006/11/29 13:13:48,200
Received PADR frame from peer 00:e0:7d:7f:b2:bd for session 0000
Service: User_Authentifizierung
Host-ID: 12 00 00 00 24 00 00 00
Transmit PADS frame to peer 00:e0:7d:7f:b2:bd for session 0019
AC-Name: xxx
Service: User_Authentifizierung
Host-ID: 12 00 00 00 24 00 00 00
EOL
[PPP] 2006/11/29 13:13:48,240
Received LCP frame from peer xxx (channel 0)
Stop waiting for connection
Stopping LCP restart timer
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer xxx
Inserting local MRU 1492
Inserting local magic number dbbeba5c
Inserting local MRRU 1492
Inserting local EPDO = 03 00 a0 57 11 a8 be
Sending LCP configure-request with ID 00 and length 27 to peer xxx (ch
annel 0)
Starting LCP restart timer with 3000 milliseconds
Evaluate configure-request with ID 00 and size 14
Peer MRU 1480 accepted
Peer magic number 2bbf5f79 accepted
Positive Configure-Request-Received event for LCP
Sending LCP configure-ack with ID 00 and length 38 to peer xxx (channe
l 0)
[PPP] 2006/11/29 13:13:48,340
Received LCP frame from peer xxx (channel 0)
Evaluate configure-reject with ID 00 and size 17
MRRU was rejected - giving up bundling
EPDO was rejected - giving up bundling
Configure-Nak/Rej-Received event for LCP
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer xxx
Inserting local MRU 1492
Inserting local magic number dbbeba5c
Sending LCP configure-request with ID 02 and length 14 to peer xxx (ch
annel 0)
Starting LCP restart timer with 3000 milliseconds
[PPP] 2006/11/29 13:13:48,360
Received LCP frame from peer xxx (channel 0)
Evaluate configure-ack with ID 02 and size 14
Configure-Ack-Received event for LCP
Initializing LCP restart timer to 3000 milliseconds
This-Layer-Up action for LCP
Change phase to AUTHENTICATE
This-Layer-Up action for LCP
Change phase to CALLBACK
This-Layer-Up action for LCP
Change phase to NETWORK
Lower-Layer-Up event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer xxx
Inserting IP address 192.168.1.254
Inserting primary DNS address 0.0.0.0
Inserting secondary DNS address 0.0.0.0
Inserting primary NBNS address 0.0.0.0
Inserting secondary NBNS address 0.0.0.0
Sending IPCP configure-request with ID 00 and length 34 to peer xxx (c
hannel 0)
Starting IPCP restart timer with 3000 milliseconds
Stopping LCP restart timer
[PPP] 2006/11/29 13:13:48,360
Received IPCP frame from peer xxx (channel 0)
Evaluate configure-request with ID 01 and size 34
Peer requests IP address 0.0.0.0, NAK with 192.168.4.32
Peer requests primary DNS address 0.0.0.0, NAK with 192.168.1.254
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary DNS address 0.0.0.0, NAK with 192.168.2.254
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 01 and length 16 to peer xxx (ch
annel 0)
[PPP] 2006/11/29 13:13:48,380
Received IPCP frame from peer xxx (channel 0)
Evaluate configure-reject with ID 00 and size 28
Peer rejects primary DNS address 0.0.0.0, discard local option
Peer rejects secondary DNS address 0.0.0.0, discard local option
Peer rejects primary NBNS address 0.0.0.0, discard local option
Peer rejects secondary NBNS address 0.0.0.0, discard local option
Configure-Nak/Rej-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer xxx
Inserting IP address 192.168.1.254
Sending IPCP configure-request with ID 02 and length 10 to peer xxx (c
hannel 0)
Starting IPCP restart timer with 3000 milliseconds
[PPP] 2006/11/29 13:13:48,400
Received IPCP frame from peer xxx (channel 0)
Evaluate configure-request with ID 02 and size 22
Peer requests IP address 0.0.0.0, NAK with 192.168.4.32
Peer requests primary DNS address 0.0.0.0, NAK with 192.168.1.254
Peer requests secondary DNS address 0.0.0.0, NAK with 192.168.2.254
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-nak with ID 02 and length 22 to peer xxx (chann
el 0)
[PPP] 2006/11/29 13:13:48,410
Received IPCP frame from peer xxx (channel 0)
Evaluate configure-ack with ID 02 and size 10
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
[PPP] 2006/11/29 13:13:48,420
Received IPCP frame from peer xxx (channel 0)
Evaluate configure-request with ID 03 and size 22
Peer requests IP address 192.168.4.32, accepted
Peer requests primary DNS address 192.168.1.254, accepted
Peer requests secondary DNS address 192.168.2.254, accepted
Positive Configure-Request-Received event for IPCP
Sending IPCP configure-ack with ID 03 and length 38 to peer xxx (chann
el 0)
Stopping IPCP restart timer
This-Layer-Up action for IPCP
Beim selbst initiertem Disconnect (ansonsten betreagt die Haltezeit 9,999)
[PPP] 2006/11/29 13:17:53,470
Received LCP frame from peer xxx (channel 0)
Terminate-Request-Received event for LCP
[PPP] 2006/11/29 13:17:53,470
This-Layer-Down action for LCP
Lower-Layer-Down event for BACP
Stopping BACP restart timer
Lower-Layer-Down event for CCP
Stopping CCP restart timer
Lower-Layer-Down event for IPCP
This-Layer-Down action for IPCP
Stopping IPCP restart timer
Lower-Layer-Down event for IPXCP
Stopping IPXCP restart timer
Resetting LCP restart timer with 3000 milliseconds
Change phase to TERMINATE
Sending LCP terminate-request with ID 03 and length 4 to peer xxx (cha
nnel 0)
Starting LCP restart timer with 3000 milliseconds
Sending LCP terminate-ack with ID a7 and length 4 to peer xxx (channel
0)
[PPP] 2006/11/29 13:17:53,470
Change phase to DEAD
Stopping LCP restart timer
Stopping IPXCP restart timer
Stopping IPCP restart timer
Stopping CCP restart timer
Stopping BACP restart timer
[PPP] 2006/11/29 13:17:53,470
PPPoES: Disconnect info: remote-disconnected (0x4301) for xxx
[PPP] 2006/11/29 13:17:53,470
call destroyed
[PPP] 2006/11/29 13:17:55,130
Received PADT frame from peer 00:e0:7d:7f:b2:bd for session 001a
unknown host, discard
[PPP] 2006/11/29 13:18:10,990
connect timeout for 00:e0:7d:xx:xx:xx
ich muss das Session-Limit auch immer auf zwei setzen, damit ich eine Verbindung (die Einzig erlaubte) aufbauen kann.
Ferner gibt mir der WinXP PPPoE-CLient nach dem Disconnect immer einen fehler aus.
Die Verbindung mit "xxx" konnte nicht hergestellt werden. Es wird versucht, die Verbindung nochmals herzustellen...
Vielleicht musst du an den Prioritaeten der FW-Regeln "schrauben".
Hier mein trace dazu:
[PPP] 2006/11/29 13:02:38,300
Received PADR frame from peer 00:e0:7d:7f:b2:bd for session 0000
PPPoE control channel: session limit exceeded for 00:e0:7d:xx:xx:xx
und beim Session-Limit 2:
[PPP] 2006/11/29 13:13:48,200
Received PADR frame from peer 00:e0:7d:7f:b2:bd for session 0000
Service: User_Authentifizierung
Host-ID: 12 00 00 00 24 00 00 00
Transmit PADS frame to peer 00:e0:7d:7f:b2:bd for session 0019
AC-Name: xxx
Service: User_Authentifizierung
Host-ID: 12 00 00 00 24 00 00 00
EOL
[PPP] 2006/11/29 13:13:48,240
Received LCP frame from peer xxx (channel 0)
Stop waiting for connection
Stopping LCP restart timer
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer xxx
Inserting local MRU 1492
Inserting local magic number dbbeba5c
Inserting local MRRU 1492
Inserting local EPDO = 03 00 a0 57 11 a8 be
Sending LCP configure-request with ID 00 and length 27 to peer xxx (ch
annel 0)
Starting LCP restart timer with 3000 milliseconds
Evaluate configure-request with ID 00 and size 14
Peer MRU 1480 accepted
Peer magic number 2bbf5f79 accepted
Positive Configure-Request-Received event for LCP
Sending LCP configure-ack with ID 00 and length 38 to peer xxx (channe
l 0)
[PPP] 2006/11/29 13:13:48,340
Received LCP frame from peer xxx (channel 0)
Evaluate configure-reject with ID 00 and size 17
MRRU was rejected - giving up bundling
EPDO was rejected - giving up bundling
Configure-Nak/Rej-Received event for LCP
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer xxx
Inserting local MRU 1492
Inserting local magic number dbbeba5c
Sending LCP configure-request with ID 02 and length 14 to peer xxx (ch
annel 0)
Starting LCP restart timer with 3000 milliseconds
[PPP] 2006/11/29 13:13:48,360
Received LCP frame from peer xxx (channel 0)
Evaluate configure-ack with ID 02 and size 14
Configure-Ack-Received event for LCP
Initializing LCP restart timer to 3000 milliseconds
This-Layer-Up action for LCP
Change phase to AUTHENTICATE
This-Layer-Up action for LCP
Change phase to CALLBACK
This-Layer-Up action for LCP
Change phase to NETWORK
Lower-Layer-Up event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer xxx
Inserting IP address 192.168.1.254
Inserting primary DNS address 0.0.0.0
Inserting secondary DNS address 0.0.0.0
Inserting primary NBNS address 0.0.0.0
Inserting secondary NBNS address 0.0.0.0
Sending IPCP configure-request with ID 00 and length 34 to peer xxx (c
hannel 0)
Starting IPCP restart timer with 3000 milliseconds
Stopping LCP restart timer
[PPP] 2006/11/29 13:13:48,360
Received IPCP frame from peer xxx (channel 0)
Evaluate configure-request with ID 01 and size 34
Peer requests IP address 0.0.0.0, NAK with 192.168.4.32
Peer requests primary DNS address 0.0.0.0, NAK with 192.168.1.254
Peer requests primary NBNS address 0.0.0.0, rejected
Peer requests secondary DNS address 0.0.0.0, NAK with 192.168.2.254
Peer requests secondary NBNS address 0.0.0.0, rejected
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-reject with ID 01 and length 16 to peer xxx (ch
annel 0)
[PPP] 2006/11/29 13:13:48,380
Received IPCP frame from peer xxx (channel 0)
Evaluate configure-reject with ID 00 and size 28
Peer rejects primary DNS address 0.0.0.0, discard local option
Peer rejects secondary DNS address 0.0.0.0, discard local option
Peer rejects primary NBNS address 0.0.0.0, discard local option
Peer rejects secondary NBNS address 0.0.0.0, discard local option
Configure-Nak/Rej-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer xxx
Inserting IP address 192.168.1.254
Sending IPCP configure-request with ID 02 and length 10 to peer xxx (c
hannel 0)
Starting IPCP restart timer with 3000 milliseconds
[PPP] 2006/11/29 13:13:48,400
Received IPCP frame from peer xxx (channel 0)
Evaluate configure-request with ID 02 and size 22
Peer requests IP address 0.0.0.0, NAK with 192.168.4.32
Peer requests primary DNS address 0.0.0.0, NAK with 192.168.1.254
Peer requests secondary DNS address 0.0.0.0, NAK with 192.168.2.254
Negative Configure-Request-Received event for IPCP
Sending IPCP configure-nak with ID 02 and length 22 to peer xxx (chann
el 0)
[PPP] 2006/11/29 13:13:48,410
Received IPCP frame from peer xxx (channel 0)
Evaluate configure-ack with ID 02 and size 10
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
[PPP] 2006/11/29 13:13:48,420
Received IPCP frame from peer xxx (channel 0)
Evaluate configure-request with ID 03 and size 22
Peer requests IP address 192.168.4.32, accepted
Peer requests primary DNS address 192.168.1.254, accepted
Peer requests secondary DNS address 192.168.2.254, accepted
Positive Configure-Request-Received event for IPCP
Sending IPCP configure-ack with ID 03 and length 38 to peer xxx (chann
el 0)
Stopping IPCP restart timer
This-Layer-Up action for IPCP
Beim selbst initiertem Disconnect (ansonsten betreagt die Haltezeit 9,999)
[PPP] 2006/11/29 13:17:53,470
Received LCP frame from peer xxx (channel 0)
Terminate-Request-Received event for LCP
[PPP] 2006/11/29 13:17:53,470
This-Layer-Down action for LCP
Lower-Layer-Down event for BACP
Stopping BACP restart timer
Lower-Layer-Down event for CCP
Stopping CCP restart timer
Lower-Layer-Down event for IPCP
This-Layer-Down action for IPCP
Stopping IPCP restart timer
Lower-Layer-Down event for IPXCP
Stopping IPXCP restart timer
Resetting LCP restart timer with 3000 milliseconds
Change phase to TERMINATE
Sending LCP terminate-request with ID 03 and length 4 to peer xxx (cha
nnel 0)
Starting LCP restart timer with 3000 milliseconds
Sending LCP terminate-ack with ID a7 and length 4 to peer xxx (channel
0)
[PPP] 2006/11/29 13:17:53,470
Change phase to DEAD
Stopping LCP restart timer
Stopping IPXCP restart timer
Stopping IPCP restart timer
Stopping CCP restart timer
Stopping BACP restart timer
[PPP] 2006/11/29 13:17:53,470
PPPoES: Disconnect info: remote-disconnected (0x4301) for xxx
[PPP] 2006/11/29 13:17:53,470
call destroyed
[PPP] 2006/11/29 13:17:55,130
Received PADT frame from peer 00:e0:7d:7f:b2:bd for session 001a
unknown host, discard
[PPP] 2006/11/29 13:18:10,990
connect timeout for 00:e0:7d:xx:xx:xx
12x 1621 Anx. B-21x 1711 VPN-3x 1722 Anx. B-7x 1723 VoIP-1x 1811 DSL, 1x 7011 VPN-1 x 7111 VPN-1x 8011 VPN-10er Pack Adv. VPN Client (2x V1.3-3x 2.0)-Hotspot Option-Adv. VoIP Client/P250 Handset-Adv.VoIP Option-4x VPN-Option-2x L-54 dual-2x L54ag-2x O-18a
-
- Beiträge: 16
- Registriert: 28 Nov 2006, 00:32
Hi ittk
welchen Fehler meinst du? Die Angabe "remote-disconnected" ist kein Fehler, sondern nur ein Hinweis darauf, wer abgebaut hat.
Der Timeout dürfte daher rühren, daß der WinXP-Client die Verbindung nicht korrekt schließt: Die PPP-Verhandlung wird mit einer Session-ID 0019 gefahtren, während das PADT mit der ID 001a kommt. Das ist aber eindeutig ein Fehler des Clients...
Auch das Problem mit dem Session-Limit, würde ich dem Client zuorden. Mach doch mal den Trace von Anfang an... In deinem Trace schlägt das Limit erst beim PADR zu - eigentlich müßte es bereits beim PADI soweit sein. Das deutet darauf hin, daß der Client zwei Sessions aufmachen will
@Blackplanet000
Wie hast du denn die Regeln für die PPPoE-Clients eingerichtet? Letztendlich muß das so aussehen:
Gruß
Backslash
welchen Fehler meinst du? Die Angabe "remote-disconnected" ist kein Fehler, sondern nur ein Hinweis darauf, wer abgebaut hat.
Der Timeout dürfte daher rühren, daß der WinXP-Client die Verbindung nicht korrekt schließt: Die PPP-Verhandlung wird mit einer Session-ID 0019 gefahtren, während das PADT mit der ID 001a kommt. Das ist aber eindeutig ein Fehler des Clients...
Auch das Problem mit dem Session-Limit, würde ich dem Client zuorden. Mach doch mal den Trace von Anfang an... In deinem Trace schlägt das Limit erst beim PADR zu - eigentlich müßte es bereits beim PADI soweit sein. Das deutet darauf hin, daß der Client zwei Sessions aufmachen will
@Blackplanet000
korrekt.höhere priorität greift als erstes.... oder anderes rum`?
Wie hast du denn die Regeln für die PPPoE-Clients eingerichtet? Letztendlich muß das so aussehen:
Code: Alles auswählen
Quelle: Gegenstelle <Name des Clients>
Ziel: alle Stationen
Aktion: übertragen.
Backslash
-
- Beiträge: 16
- Registriert: 28 Nov 2006, 00:32
hey thx backslash....
hatte die regel falsch konfiguriert.....
quelle war die gegenstelle und als ziel hatte ich auch die gegenstelle und nicht alles augweählt. ist ja eigentlich logisch hate mich da irgendwie verfangen.
aber nun noch das problem das ittk auch hat.
kann man da irgendwas tun. ist etwas unschön das immer ne fehlermeldung am client komm wenn dieser sich disconnectet....
dann noch was anderes hab in meinem router nur eine ip-route eingegeben und das ist die die default-route.... zu meinem router der die internetverbindung aufbaut. wenn ich jetzt allerdings bei der firewall deny-all regel nur für default route wähle wird gar nichts blockiert.....
hatte die regel falsch konfiguriert.....
quelle war die gegenstelle und als ziel hatte ich auch die gegenstelle und nicht alles augweählt. ist ja eigentlich logisch hate mich da irgendwie verfangen.
aber nun noch das problem das ittk auch hat.
kann man da irgendwas tun. ist etwas unschön das immer ne fehlermeldung am client komm wenn dieser sich disconnectet....
dann noch was anderes hab in meinem router nur eine ip-route eingegeben und das ist die die default-route.... zu meinem router der die internetverbindung aufbaut. wenn ich jetzt allerdings bei der firewall deny-all regel nur für default route wähle wird gar nichts blockiert.....
Hi Blackplanet000,
Oder aber du erstellst eine Deny-All Route, die immer greift und zusätzlich eine Route, die den Traffic ins Intranet immer erlaubt (ich gehe jetzt mal davon aus, daß die User das Intranet immer sehen dürfen und das Internet nur nach Einwahl über PPPoE...)
Gruß
Backslash
einen anderen Client nehmen (siehe mein letztes posting), denn der scheint irgendwie zu versuchen zwei Sessions aufzumachen statt einer...kann man da irgendwas tun. ist etwas unschön das immer ne fehlermeldung am client komm wenn dieser sich disconnectet....
Das Problem dürfte sein, das das Flag "nur auf Defaultroute" nur greift, wenn die Defaultroute ins WAN zeigt. Abhilfe schafft hier die Verwendung des DSLoL-Interfaces...dann noch was anderes hab in meinem router nur eine ip-route eingegeben und das ist die die default-route.... zu meinem router der die internetverbindung aufbaut. wenn ich jetzt allerdings bei der firewall deny-all regel nur für default route wähle wird gar nichts blockiert.....
Oder aber du erstellst eine Deny-All Route, die immer greift und zusätzlich eine Route, die den Traffic ins Intranet immer erlaubt (ich gehe jetzt mal davon aus, daß die User das Intranet immer sehen dürfen und das Internet nur nach Einwahl über PPPoE...)
Gruß
Backslash
-
- Beiträge: 16
- Registriert: 28 Nov 2006, 00:32
Hi Blackplanet000,
ich hab mir mal angeschaut, was da schief geht:
Der XP PPPoE-Client erhöht während der PPPoE Verhandlung das Host-Unique-Tag, wodurch das LANCOM dies als zweite Session wertet. In der Nächsten Firmware wird das erkannt, so daß ein Session-Limit von 1 auch greift (korrekt ist das aber nicht...)
Völlig unsinnig ist aber die Fehlermeldung: "Die Verbindung konnte nicht AUFgebaut werden". Diese Meldung kommt dann, wenn der Access-Concentrator nach dem Ende des Session (also einem korrekten Verbindungs-ABbau) kein PADT schickt. Das PADT ist aber nach RFC 2516 optional und sollte nur gesendet werden, wenn ein normaler PPP-Abbau nicht möglich ist (der ist hier aber sauber durchgelaufen).
Aber gut... die nächste Firmware sendet auch ein PADT
Gruß
Backslash
ich hab mir mal angeschaut, was da schief geht:
Der XP PPPoE-Client erhöht während der PPPoE Verhandlung das Host-Unique-Tag, wodurch das LANCOM dies als zweite Session wertet. In der Nächsten Firmware wird das erkannt, so daß ein Session-Limit von 1 auch greift (korrekt ist das aber nicht...)
Völlig unsinnig ist aber die Fehlermeldung: "Die Verbindung konnte nicht AUFgebaut werden". Diese Meldung kommt dann, wenn der Access-Concentrator nach dem Ende des Session (also einem korrekten Verbindungs-ABbau) kein PADT schickt. Das PADT ist aber nach RFC 2516 optional und sollte nur gesendet werden, wenn ein normaler PPP-Abbau nicht möglich ist (der ist hier aber sauber durchgelaufen).
Aber gut... die nächste Firmware sendet auch ein PADT
Gruß
Backslash