harvey0815
Goto Top

Remoteinwahl per VPN auf eine FritzBox und Remotedesktop

Ein sonnigen Nachmittag zusammen!

Ich habe schon etliche Threats gelesen auch in verschiedenen Foren und das Problem ist wohl nicht ganz unbekannt allerdings habe ich alle Lösungen schon ausprobiert und nie hat es zum Erfolg geführt....

Zum Problem:
Es werden in einem Netzwerk 192.168.178.0 drei Fritzboxen betrieben. Alle samt 7490 OS 6.51
192.168.178.1 , 192.168.178.2 und 192.168.178.13
DHCP ist bei allen deaktiviert. Das übernimmt ein Windows Server 2012.
Auf allen drein ist DynDNS aktiviert und es sind VPN Nutzer eingerichtet.
So weit so gut.

Nun will ich mich in eine der drei FritzBoxen per VPN einwählen und das funtkioniert auch auf den ersten Blick.
Will ich dann aber eine RDP Session zu einem PC hinter der FB starten kann diese nicht aufgebaut weden.
Komischweise nur zu einigen PCs, bei anderen klappt es.
Dieses Verhalten beobachte ich bei zwei FB bei der dritten nicht!

Ich kann das Problem auch auf einem anderen Gerät reproduzieren.
Also baue ich die selbe Verbindung mit dem selben Nutzer auf einem anderen sich zu verbindenden Gerät (z.B. Android Handy mit LTE Internet) auf und verbinde mich mit einer der beiden fehlerhaften FBs kann ich danach kein RDP aufbauen.
Mit der dritten und dem selben Handy geht es schon.

Baue ich ein VPN zu der dritten Fritte auf, kann ich sofort auf jeden PC per RDP zugreifen.

Ich schlussfolgere daraus, dass es nicht am PC liegt, denn mit der dritten FB klappt es ja zu jeder Zeit.
Ausserdem schlussfolgere ich, dass es nicht an Firewalleinstellungen der PCs liegt und auch nicht an dem Router oder Internetzugang auf der anderen Seite, denn ich habe es mit zwei verschiedenen Geräten an zwei verschiedenen Internzugängen versucht und bekomme haargenau das selbe Ergebnis.

Es macht auch keinen Unterschied ob ich nun einen VPN Nutzer direkt in der FB anlege oder per "FritzFernzugang einrichten" oder per VPN Assistent ....

Was meint Ihr?
Ist euch so eine Problematik schon mal über den Weg gelaufen?

Fragt verzweifelt

Harvey

Content-Key: 300723

Url: https://administrator.de/contentid/300723

Ausgedruckt am: 28.03.2024 um 18:03 Uhr

Mitglied: Lochkartenstanzer
Lochkartenstanzer 02.04.2016 aktualisiert um 18:14:46 Uhr
Goto Top
Moin,

Du hast ein Routing-problem.

vermutlich hast Du eine default-route hinterlegt, die auf genau eine der drei FBs zeigt. Und wenn Du mit den "falschen" zwei FB reinkommst, funktioniert der "Rückweg" nicht.

Für Deine Fall dürfte es sinnvoller sein, "hinter" den Fritzboxen eine VPN-Server einzurichten udn damit das VPN zu machen. Oder Du ersetzt die fritzboixen gelcih durch einen ordentlichen Multi-WAN-Router (Cisco, LAncom, Microtik, etc.), der auch das VPN machen kann.

lks
Mitglied: Harvey0815
Harvey0815 02.04.2016 um 18:31:27 Uhr
Goto Top
Danke für deine Antwort.
Also ein neues VPN Gateway einzurichten kommt erstmal nicht in Frage.
Es muss doch mit den Fritten möglich sein.
Vorher gab es genau das selbe Setup mit DrayTek und Cisco Routern.
Diese habe ich nur wegen Umstieg auf VDSL und VoIP abgelöst.

Wenn das mit der default Route stimmt, warum kann ich dann manche Clients erreichen und manche nicht?
Mit der dritten Fritte geht es immer sofort.

Ein Default-Routeneintrag wird immer beim Aufbau neu erzeugt und sofort entfernt, wenn das VPN abgebaut wird.
Mitglied: Lochkartenstanzer
Lochkartenstanzer 02.04.2016 um 19:34:20 Uhr
Goto Top
Zitat von @Harvey0815:

Vorher gab es genau das selbe Setup mit DrayTek und Cisco Routern.

Glaube ich nixht. Da war garantiert etwas anders. ggf. haben die die entweder den Client maskiert oder der Client hat IP-Adressen aus dem LAN bekommen.

Diese habe ich nur wegen Umstieg auf VDSL und VoIP abgelöst.

Das reicht als Grund Auch Drayteks und Ciscos können VDSL (ggf anderes Modem) und Voip funktioniert auch hinter denen.


Wenn das mit der default Route stimmt, warum kann ich dann manche Clients erreichen und manche nicht?

Vermutlich abhäöngig davon, ob der Client mit eienr IP-Adresse aus dem LAN komtm doer miteiner anderen Adresse.

Mit der dritten Fritte geht es immer sofort.

Vermutlich ist die default route auf diese gestellt.

Ein Default-Routeneintrag wird immer beim Aufbau neu erzeugt und sofort entfernt, wenn das VPN abgebaut wird.

Ich glaube nicht, daß der Server, auf den Du per VPN gehst jedesmal seine default route ändert, wenn jemand sich per vpn einwählt.


du soltlest mit traceroute und ipconfig mal die Konfiguratin des Servers und der Client überprüfen.

lks
lks
Mitglied: Harvey0815
Harvey0815 02.04.2016 um 19:46:06 Uhr
Goto Top
Zitat von @Lochkartenstanzer:

Zitat von @Harvey0815:

Vorher gab es genau das selbe Setup mit DrayTek und Cisco Routern.

Glaube ich nixht. Da war garantiert etwas anders. ggf. haben die die entweder den Client maskiert oder der Client hat IP-Adressen aus dem LAN bekommen.

Kannst du mir ruhig glauben face-smile mit selbem Setup meine ich, ich habe nur die Router gewechselt. Server, Clients, Firewalleinstellungen dieser, RDP -Settings alles das selbe geblieben. Natürlich funktionieren die Router an sich bestimmt alle anders. Bei DrayTek und Cisco konnte ich z.B. eine IP Range für die zu verbindenden Clients vergeben. Also auch keine Maskierung oder dergleichen. Bei der Fritte kann ich keine Range vergeben.

Diese habe ich nur wegen Umstieg auf VDSL und VoIP abgelöst.

Das reicht als Grund Auch Drayteks und Ciscos können VDSL (ggf anderes Modem) und Voip funktioniert auch hinter denen.
Jetzt habe ich aber die Fritten und alles weitere (TK Anlage hinter der FB, analog Fax VDSL, VoIP zur TK Umsetzung als ISDN) funtkioniert tadellos.


Wenn das mit der default Route stimmt, warum kann ich dann manche Clients erreichen und manche nicht?

Vermutlich abhäöngig davon, ob der Client mit eienr IP-Adresse aus dem LAN komtm doer miteiner anderen Adresse.
Wlechen Client meinst du? Der sich verbindende Client kommt natürlcih mit einer IP aus dem Netz in das er sich verbindet, immer.

Mit der dritten Fritte geht es immer sofort.

Vermutlich ist die default route auf diese gestellt.

Ein Default-Routeneintrag wird immer beim Aufbau neu erzeugt und sofort entfernt, wenn das VPN abgebaut wird.

Ich glaube nicht, daß der Server, auf den Du per VPN gehst jedesmal seine default route ändert, wenn jemand sich per vpn einwählt.
Der sich zu verbindende Client erstellt Routing Einträge in seiner Routing Tabelle. Warum sollte der Server auf der anderen Seite seine Routing Tabelle ändern?
Mit der dritten Fritte kann ich alle Ziele erreichen.
Mit den anderen beiden nur manche.... das gibt es kein Muster, leider.


du soltlest mit traceroute und ipconfig mal die Konfiguratin des Servers und der Client überprüfen.
Ich kann gar kein Protokoll erreichen, weder per RDP, Ping, Tracert, da geht gar nichts.
Oder welchen Server meinst du?
Auf den Clients in dem Netzwerk auf das sich verbunden wird gibt es keine Probleme mit der dritten Fritte geht alles sofort.

lks
lks
Mitglied: aqui
aqui 02.04.2016 aktualisiert um 20:47:28 Uhr
Goto Top
Will ich dann aber eine RDP Session zu einem PC hinter der FB starten kann diese nicht aufgebaut weden.
Das ist auch logisch das das passieren kann. Denk mal etwas nach...
Kommt der VPN User via Fritzbox 1 rein und geht auf den PC und diese PC hat aber die Fritzbox 2 als Default Gateway gehen alle PDP Antwortpakete von diesem PC zur Fritzbox 2 und damit ins Nirwana.
Du kannst in deinem Konstrukt per VPN nur einzig auf die PCs per RDP im internen netz gehen die auch exakt die Fritzbox als Gateway eingetragen haben über die du als VPN User reinkommst...logisch.
Kollege LKS hats ja schon angesprochen.
Nimm einen Wireshark Sniffer und sieh dir das auf dem per RDP zu steuernden PC an, dann hast du es schwarz auf weiss und musst nicht die technisch richtige Argumentation des Kollegen LKS anzweifeln !
Ich schlussfolgere daraus, dass es nicht am PC liegt,
Doch, denn das Gefault Gateway des betreffenden PCs ist hier der entscheidende Knackpunkt...!
Leuchtet einem auch eigentlich ein wenn man nur mal ein klein wenig über die IP Paketkommunikation im Netzwerk nachdenkt.

Generell ist dein Konstrukt mit 3 einzelnen Boxen nicht gut und eine gruselige Bastellösung mit billigen Consumer Routern. Besser wäre hier ein Multi WAN Port Router, der ein Balancing mit Backup über die 3 Leitungen macht, dann stellt sich dieses Problem gar nicht erst.
Mitglied: ChriBo
ChriBo 02.04.2016 um 20:58:53 Uhr
Goto Top
Hi Aqui,
ich hatte in die gleiche Richtung wie du und Lochkartenstanzer gedacht.
Gilt aber nur wenn der VPN Client eine IP Adresse aus einem anderen Bereich als von dem internen Netz erhält, hierbei ist ein Routing über das richtige Gateway notwendig.
Die Fritzbox vergibt aber (so wie ich eben auf die Schnelle gelesen habe) die Adressen aus dem internen Bereich, also kein Routing sondern nur Bridging.
Kann also sein, daß keine Routen notwendig sind.
-
Ohne die Ausgaben von ipconfig und tracerts ist die Fehlersuche und ggf. eine mögliche Fehlerbehebung fast sinnlos.

Gruß
CH
Mitglied: Harvey0815
Harvey0815 02.04.2016 um 21:00:17 Uhr
Goto Top
Das Default Gateway hat damit nichts zu tun.
Das ist leider nicht so wie du es sagst!
Das wäre ja dann sehr einfach zu lösen, das habe ich mir auch schon gedacht.
Leider klappt es so nicht.

Die dritte FritzBox ist bei keinem der beteiligten PCs in dem sich zu verbindenden Netzwerk das Gateway und trotzdem kann ich mich darüber mit jedem PC in der Firma verbinden.... was sagt ihr dazu?

Ich zweifle keine Argumente an.
Ich sitze davor und ich sehe das das was ihr da schreibt falsch ist.

PC1 hat Gateway2 (FB2)
PC2 hat Gateway1 (FB1)
Verbindung über VPN zu PC1 und PC2 per RDP geht über FB3 aber nicht über FB1 und FB2
Mitglied: Harvey0815
Harvey0815 02.04.2016 um 21:02:12 Uhr
Goto Top
Danke dir.
Von nach wo soll ich ein traceroute machen?
ipconfig ipconfig von wem?
Mitglied: aqui
aqui 04.04.2016 aktualisiert um 09:49:55 Uhr
Goto Top
Kann also sein, daß keine Routen notwendig sind.
Nein, dem ist nicht so. Relevant ist doch einzig WELCHE der 3 FBs den VPN Tunnel hält. Das Endgerät MUSS also zwangsweise die Antwortpakete auf die FB schicken die auch den korrespondierenden Tunnelendpunkt für die VPN Verbindung hält.
Die FBs kommunizieren ja NICHT miteinander wer für welchen Client einen Tunnel offen hat !
Sendet das angesprochene Endgerät im lokalen LAN also die Antwortpakete durch seinen Default Gateway Einstellung an eine FB die gar keinen Client VPN Tunnel hat versanden die Pakete im Nirwana...logisch !
Das Design des TOs ist generell falsch und laienhaft und kann so in der Konstellation niemals richtig laufen. Oder eben nur wenn man die VPNs auf eine FB kumuliert.
Mitglied: Lochkartenstanzer
Lochkartenstanzer 04.04.2016 um 09:55:24 Uhr
Goto Top
Zitat von @Harvey0815:

Danke dir.
Von nach wo soll ich ein traceroute machen?

Von den Kisten auf die Du per RDP gehst zu den RDP-Clients, von denen aus Du Dich zu verbinden versuchst.

ipconfig ipconfig von wem?

Von allen beteiligten systemen.

lks
Mitglied: Lochkartenstanzer
Lochkartenstanzer 04.04.2016 um 09:59:11 Uhr
Goto Top
Zitat von @aqui:

Kann also sein, daß keine Routen notwendig sind.
Nein, dem ist nicht so. Relevant ist doch einzig WELCHE der 3 FBs den VPN Tunnel hält.

Das was aqui sagt, habe ich Dir ein paar Postings weiter oben auch schon zu sagen versucht:

Der Client weiß nicht, von welcher der drei Fritzbüxen deas Paket reinkommt, genauer gesagt, er merkt es sich nicht, auch über die MAC-Adresse es nachvollziehbar wäre. Alelrdings wird die Schicht-1 Information beim eiterreichen im TCP/IP-Stack entfernt und so weiß die Schicht 4 nicht mehr,. wo das Paket herkam. Daher wird die Antowrt an das default-gateay des systems, auf dem der RDP-Server läuft geschickt, was in 2 von drei Fällen der falsche sein wird.

lks
Mitglied: Harvey0815
Harvey0815 04.04.2016 um 19:48:55 Uhr
Goto Top
Läuft jetzt alles so wie geplant und das sehr stabil danke euch !
Mitglied: Lochkartenstanzer
Lochkartenstanzer 04.04.2016 aktualisiert um 20:45:29 Uhr
Goto Top
Sagst Du uns auch, was genau das Problem gelöst hat.
Mitglied: aqui
aqui 05.04.2016 um 10:09:24 Uhr
Goto Top
...was ja auch der Sinn eines Forums ist um ggf. anderen mit ähnlichem Problem zu helfen !
Die Lösung wäre also schon interessant.