subsee
Goto Top

Site to Site VPN (Kein Zugriff von Client auf Remote Server)

Moin,

ich habe folgendes Problem.
Ich hab 2 Standorte mittels Site to Site VPN verbunden. Routing und Ras (Wählen bei Bedarf) auf zwei Windows Server 2012 R2.
Wenn ich direkt auf dem Server bin kann ich jeden Client des Verbundenen Netzwerkes erreichen.
Wenn ich jedoch vom Client aus den Remote Server oder einen anderen Client erreichen will.. Ping timeout.

Standort A - 192.168.100.0
Standort A Server: 192.168.100.250 DHCP Aktiv.
Clients Per DHCP 192.168.100.100-192.168.100.199 - Gateway und DNS macht der Server (192.168.100.250)


Standort B 192.168.50.0
Standort B Server: 192.168.50.250 DHCP Aktiv.
Clients Per DHCP 192.168.50.100-192.168.50.199 - Gateway und DNS macht der Server (192.168.50.250)

Folgendes geht.
Von Server A jeden Host von Standort B erreichen geht! Anders herum ebenso.

Was nicht geht.
Vom Client Standort A einen Host in Standort B zu erreichen.


PS: Wenn ich eine normal VPN Verbindung vom Client PC zum Server herstelle gehts. Nur das soll verschwinden face-smile

Content-Key: 333017

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

Ausgedruckt am: 19.03.2024 um 05:03 Uhr

Mitglied: aqui
Lösung aqui 23.03.2017, aktualisiert am 24.03.2017 um 19:38:58 Uhr
Goto Top
Wenn ich jedoch vom Client aus den Remote Server oder einen anderen Client erreichen will.. Ping timeout.
Das ist vermutlich klar und logisch und du hast es versäumt mal über den IP Paket Flow im Netz und VPN nachzudenken denn dann wärst du sofort selber auf die Lösung gekommen.... Stichwort: IP Routing !

Hier kommt der Erklärbär warum dein Client Ping scheitert:
Nehmen wir mal an ein Client 192.168.100.100 an Standort A will den Server oder einen Client in Standort B pingen 192.168.50.x
Dann hat das abgesendete ICMP Paket (Ping ist ICMP Echo) ja eine Absender IP 192.168.100.100 und eine Ziel IP 192.168.50.x.
Der Client muss also in seine Routing Tabelle sehen da er das Ziel (.50er Netz) ja nicht im lokalen IP Netz erreichen kann.
In seiner Tabelle steht vermutlich als Default Gateway die 192.168.100.1, also der lokale Internet Router.
Leider machst du dazu keinerlei Angaben (wie auch zum verwendeten VPN Protokoll) so das wir das hier mal im freien Fall raten müssen. face-sad
Also weiter...
Er schickt das ICMP Paket nun an den Internet Router in der Hoffnung das der weiss wie man zum 192.168.50.0 /24 Netzwerk kommt.
Der Router empfängt das Paket und sieht auch wieder in seine Routing Tabelle um den Weg zum .50er IP Netz zu suchen....
Hier kommt jetzt der magische Punkt, denn zu 98% hast du hier im Router die statische IP Route ins 192.168.50er Netz vergessen ?!?

Was der Router dann macht aufgrund dieser fehlenden Route, ist das IP Paket zum Internet Provider zu schicken. Was soll er auch anderes machen ohne spezifische Route zum Ziel, denn so ist immer der Provider ja sein Default Gateway.
Da das 192.168.50er Netz aber ein privates RFC 1918 IP Netz ist was im Internet nicht geroutet wird, schmeisst der Providerrouter das Paket sofort wech und das Resultat ist bei dir dann ein Ping Timeout genau wie oben beschrieben !
Es arbeitet also alles wie es soll.

Fazit:
Statische IP Route im Internet Router nachtragen!

Standort A:
Zielnetz: 192.168.50.0, Maske: 255.255.255.0, Gateway: 192.168.100.250

Standort B:
Zielnetz: 192.168.100.0, Maske: 255.255.255.0, Gateway: 192.168.50.250

Fertisch !
Da die Server ja die VPN Tunnel halten routen die also ins jeweils andere Netz und das muss man logischerweise dem Default Gateway für die Clients mit einer statischen Route mitteilen. Woher sollten sie es sonst auch wissen...!
Wie immer sind hier Traceroute (tracert) und Pathping deine besten Freunde. Das hätte dir dann vermutlich auch diesen Thread erspart.
Mitglied: subsee
subsee 23.03.2017 um 12:00:39 Uhr
Goto Top
Zitat von @aqui:
Hier kommt jetzt der magische Punkt, denn zu 98% hast du hier im Router die statische IP Route ins 192.168.50er Netz vergessen ?!?

Wie recht du doch hast face-smile Verdammt daran habe ich nun überhaupt nicht gedacht.

Vielen Danke für deinen Denk-Anstoß =)
Mitglied: aqui
aqui 23.03.2017 aktualisiert um 16:01:10 Uhr
Goto Top
Immer gerne wieder face-smile
Übrigens: Netztechnisch sinnvoller wäre es gewesen die VPN Site2Site Verbindung über die Router zu realisieren. Dann wäre das erheblich sicherer: Das VPN Port Forwarding direkt a.d. Server ins interne Netz fällt weg und die statischen Routen wären überflüssig...
VPNs terminiert ein verantwortungsvoller Netzwerker immer an der Peripherie.