1722 Bridging zwischen ATM-IF und LAN-IF

ua · Beitrag von ua » 01 Dez 2007, 01:17

Tach Zusammen,

folgendes Scenario:

Splitter --> LC1722
1) --ETH1/Netz1 via Kennung 1 --> Hausnetz
2) --ETH2/Netz2 via Kennung 2 mittels VRF --> SSL-Gateway --> Hausnetz
Die 2te Kennung hat eine feste IP-Adresse, diese wird dann per Portforwarding auf das SSL Gateway geschoben.

Es funktionert auch alles so weit, nur mit dem SSL-VPN gibt es mit manchen Browsern Probleme. Firefox startet zum Beispiel die Startseite nach der Anmeldung geht es nicht mehr weiter, IE hat keine Probleme. Der Fehler konnte auf das Portforwarding eingegegrenzt werden. Sobald das SSL-Gateway direkt mit der offiziellen IP im Netz funktioniert alles.

Da ich kein separates DSL-Modem nebst Switch einsetzen möchte, ist mir folgende Idee gekommen:

Ist es möglich, das ATM Interface (genauer den VPI/VCI 1/32) auf ein LAN IF zu bridgen, um so den "rohen" DSL Verkehr für den weiteren Router abzugreifen?
So aus dem Stegreif ist mir kein Lösungsweg eingefallen.

Viele Grüße

Udo

PS Oder kommt in der Version 8.x auch ein SSL Gateway in das LC

gm · Beitrag von gm » 01 Dez 2007, 09:46

Hi ua,

ua hat geschrieben: Der Fehler konnte auf das Portforwarding eingegegrenzt werden.

Welcher Fehler? Was geht genau nicht? Wieso ist das Portforwarding schuld?

ua hat geschrieben: Sobald das SSL-Gateway direkt mit der offiziellen IP im Netz funktioniert alles.

?!? -> Könntest Du das noch etwas genauer beschreiben?

Wieso sollen eigentlich alle PPPoE-Pakete an das SSL-Gateway weitergeleitet werden? Das Geht z.B. mit dem PPPoE-Server im LCOS.

Gruß
gm

ua · Beitrag von ua » 01 Dez 2007, 15:51

Hi,

Welcher Fehler? Was geht genau nicht? Wieso ist das Portforwarding schuld?

Ganz einfach: Das SSL-VPN arbeitet ohne Problem, sobald ich das SSL-GW direkt an einen DSLer hänge. Die Offizielle IP Adresse liegt dann "direkt im Gateway".
Die Funktionsweise des SSL Gateways beinhaltet einen Redirect bzw. dynamisches Mapping von der offiziellen IP des GW auf die internen http-Diensteanbieter. Da das externe Interface des GW eine private Adresse ist, Transfernetz zwischen LC und GW, wird dem Client im Internet bei einem Redirect die private Adresse mitgeteilt. Der IE hat damit kein Problem, der Firefox will dann aber auch die private Adresse ansprechen.
Die Adresse im GW zu ändern bringt nichts, da der SSL-VPN Dienst auf dieser IP laufen muss.

Wieso sollen eigentlich alle PPPoE-Pakete an das SSL-Gateway weitergeleitet werden? Das Geht z.B. mit dem PPPoE-Server im LCOS.

Der interne PPPoE Server nutzt in diesem Fall überhaupt nix, ich muß die Provider-PPPoE-Session im GW terminieren und möchte nich -wie beschrieben- ein separates Modem mit Switch benutzen.

Viele Grüße

Udo[/b]

backslash · Beitrag von **backslash** » 01 Dez 2007, 17:00

Hi ua

Ist es möglich, das ATM Interface (genauer den VPI/VCI 1/32) auf ein LAN IF zu bridgen, um so den "rohen" DSL Verkehr für den weiteren Router abzugreifen?
So aus dem Stegreif ist mir kein Lösungsweg eingefallen.

nein - selbst wenn das 1722 eine WAN-Bridge hätte, hattest du ein Problem: Einerseits willst du das 1722 als Router verwenden, andereseits willst du es als "Modem" nutzen. Das Problem ist, daß jedesmal VPI/VCI gleich sind und daher eine Trennung nicht möglich ist (woher soll das LANCOM bei einer ATM-Zelle, die über diese VPI/VCI-Kombination empfangen wird, wissen, wie sie zu behanden ist (bridgen oder an den Router weiterleiten)

Firefox startet zum Beispiel die Startseite nach der Anmeldung geht es nicht mehr weiter, IE hat keine Probleme. Der Fehler konnte auf das Portforwarding eingegegrenzt werden. Sobald das SSL-Gateway direkt mit der offiziellen IP im Netz funktioniert alles.

irgendwie kann ich mir nicht vorstellen, daß es einen Unterschied macht, ob das Gateway direkt im Internet hängt oder über ein Portforwarding weitergeleitet wird. Dem SSL ist das völlig egal (sonst würden HTTPS-Zugriffe über einen NAT-Router gar nicht funktionieren).

Die Funktionsweise des SSL Gateways beinhaltet einen Redirect bzw. dynamisches Mapping von der offiziellen IP des GW auf die internen http-Diensteanbieter. Da das externe Interface des GW eine private Adresse ist, Transfernetz zwischen LC und GW, wird dem Client im Internet bei einem Redirect die private Adresse mitgeteilt. Der IE hat damit kein Problem, der Firefox will dann aber auch die private Adresse ansprechen.

Dann ist der Redirect das Problem - ich frage mich nur, wieso das mit dem IE funktionieren soll? Hier mußt du offenbar mit DynDns-Namen arbeiten und im Redirect den Dyndns-Namen angeben, statt der IP-Adresse... (und natürlich die jeweiligen Ports weiterleiten)

Gruß
Backslash

ua · Beitrag von ua » 01 Dez 2007, 21:51

Hallo \,

Das Problem ist, daß jedesmal VPI/VCI gleich sind und daher eine Trennung nicht möglich ist (woher soll das LANCOM bei einer ATM-Zelle, die über diese VPI/VCI-Kombination empfangen wird, wissen, wie sie zu behanden ist (bridgen oder an den Router weiterleiten)

Die Bridge hatte ich mir so an der Stelle zwischen "ATM-Ausgang" und "Etherneteingang" vorgestellt, dort gibt es schon PPPoE und die Adressierung läuft über die MAC-Adresse, somit also Bridge-/Switchbar (analog eines extern angeschlossenen Modems).

irgendwie kann ich mir nicht vorstellen, daß es einen Unterschied macht, ob das Gateway direkt im Internet hängt oder über ein Portforwarding weitergeleitet wird. Dem SSL ist das völlig egal (sonst würden HTTPS-Zugriffe über einen NAT-Router gar nicht funktionieren).

Die Startseite von dem GW wird sowohl bei Mozilla als auch IE angezeigt, die Anmeldung klappt auch und das Menu mit den internen HTTP-Diensten wird angezeigt. Sobald jedoch eine Session auf den Ziel-Server gestartet wird hängt der Mozilla. Der IE startet die neue Session in einem neuem Fenster problemlos. Vermutlich "erbt" der IE die Verbindung für das neue Fenster und der FF wertet die IP Adresse des Redirects aus (welche momentan die exerner IP des SSL-GW ist, d.h. die interne IP aus dem Transfer-Netz zwischen LC und GW.

Hier mußt du offenbar mit DynDns-Namen arbeiten und im Redirect den Dyndns-Namen angeben

Die 2te Verbindung hat sogar eine feste IP. Das SSL Gatewy kann leider keine alternativ IP absenden. Es sendet daher immer seine externe.

Es scheint so, das ich doch ein externes Modem nutzen muss, kann das LC PPPoE Passthrough? Auf die schnelle habe ich nichts gefunden:

Viele Grüße

Udo