OpenVPN Client hinter 1821+ ?

[Michael76]

Hallo,
muss hier an einigen pcs eine fernwartungslösung einrichten die auf OpenVPN basiert...
aber schon das "initial packet" vom remote server kommt nicht mehr beim client an (TLS key negotiation failed)
mit pc direkt am dsl (also ohne lancom) geht es.

tests mit deaktivierter firewall, diversen port forwards und dmz einträgen haben alle nichts gebracht.
bin kein vpn guru, daher frage an die experten hier: gibt es irgendeinen grund warum das nicht gehen sollte hinter einem lancom?
router: 1821+ mit LCOS 8.62

vielen dank für euere hilfe!
Michael

[MariusP]

Hi,
Ohne deinen Aufbau direkt zu kennen und ohne OpenVPN zu nutzen, würde ich erstmal vermuten das Du ein NAT laufen hast und daher daher die Addressen nicht aufgelöst werden können.

Schau dir doch bitte mal einen IP-Router trace "tr # ip-r" an was genau mit dem eingehenden Paket passiert.
Gruß

[Cytor]

Hi,

ist der PC hinter dem LANCOM OpenVPN-Client oder -Server?
Für den Serverbetrieb muss bloß der Port 1194 UDP am LANCOM an den PC geforwardet werden. Wenns der Client ist, musst du nichts weiter einrichten (ausser den Port ggf. in der Firewall frei machen, wenn Deny-All gefahren wird).
Ich habe das hier genau so laufen, Server und Client jeweils hinter einem LANCOM. Prinzipiell gibt es also da erstmal kein Problem.

[Michael76]

Guten Morgen und danke euch für die schnellen antworten!!
das lässt ja schonmal hoffen wenn es grundsätzlich klappen sollte...

@Cytor: der pc hier hinter lancom ist der client und darf firewallmässig uneingeschränkt nach draussen rufen...

@MariusP: hab den trace nochmal laufen lassen: ich sehe nur die ausgehenden pakete von meinem client an den externen host, kein einziges eingehendes
dein hinweis bzgl. NAT hab ich leider nicht verstanden - der hostname des externen server wird jedenfalls korrekt aufgelöst, es kommt nur nix zurück...

bin für alle vorschläge dankbar!
viele grüße,
Michael

[MariusP]

Hi,
Probiers mal mit dem Firewall-Trace und dem Ethernet Trace.
Der Firewall trace zeigt dir wenn Pakete durch die Firewall blockiert wurden, aber nicht die erlaubten Pakete.
Bei Ethernet Trace aufpassen, das du dir keinen Trace-loop machst, der dir traced dass du traced dass du traced.^^
Also die IP angeben die aufgezeichnet werden soll.
http://www2.lancom.de/kb.nsf/1276/37221 ... enDocument
VIelleicht dir auch mal nen Wiresharktrace anschauen, ob du Daten deine PC richtig verlassen.

Gruß

[Michael76]

Hallo,
nix, nix, nix.... da kommt absolut nix zurück ; verstehe es selber nicht.
wenn ich wie gesagt den pc direkt ans dsl hänge geht es (das ist auch übrigens die "empfehlung" des techsupport für dieses grandiose produkt... sehr praxistauglich! )
naja, werde noch ein bissl rumprobieren und wenn ich was finde mich melden.
danke trotzdem für euere hilfe und tipps!
Gruß,
Michael

[MariusP]

Hi,
nix, nix, nix.... da kommt absolut nix zurück ; verstehe es selber nicht.
Heißt das nichtmal der Ethernet-trace etwas anzeigt? (Deine Antwort war leider unpräzise formuliert.)
Weil dann scheint das Problem nicht beim Lancom zu liegen sondern bei der Art wie der Client die Gateway-Adresse bestimmt.
Gruß

[Michael76]

Hi,
ja richtig das sollte es heissen, entschuldige die ungenaue formulierung.
vom externen vpn gateway kommt nichts zurück.
haben heute mal nen test gemacht mit einem zweiten lancom router in grundkonfiguration ohne jeden schnickschnack also nur dsl eingerichtet, client dran: geht auch nicht. dann einen 30€ d-link router ebenfalls eingerichtet und getestet: geht!
liegt also der schluß nahe daß hier im lancom irgendwas mit dem ausgehenden paket gemacht wird so daß der externe gateway es nicht mehr akzeptiert bzw. gar nicht erst darauf antwortet???
Gruß,
Michael

[MariusP]

Hi,
Was hast du denn beim Ethernet-Trace genau getraced? Falsche Filter oder so vielleicht?
Damit meine ich Ausgabe des trace-Kommandos und die Ausgabe des Traceverlaufs.
Könntest du das bitte hier posten.

"initial packet" vom remote server kommt nicht mehr beim client an (TLS key negotiation failed)

Nochmal bitte zur Klarstellung, da

vom externen vpn gateway kommt nichts zurück.

dem Ganzen etwas widerspricht:
Der Server (der irgendwo im Internet liegt) schickt ein initial Paket zur öffentlichen IP des Router (in dem fall ein Lancom) dieser soll dann das Paket an den Client weiterleiten.
Und der Client gibt den Fehler aus "TLS key negotiation failed"?

Heißt das nun, dass das Paket beim Client ankommt aber kaputt? (Was ja bedeutet das der Ethernet-trace etwas anzeigen müsste wenn der Trace richtig gestartet wurde.)
In dem Fall: Was ergab denn dann der Wiresharktrace nach dem ich gefragt hatte?

liegt also der schluß nahe daß hier im lancom irgendwas mit dem ausgehenden paket gemacht wird so daß der externe gateway es nicht mehr akzeptiert bzw. gar nicht erst darauf antwortet???

Es liegt dieser Schluss nahe, was aber nicht heißt das es der richtige ist.

Gruß