Site to Site VPN: Ping geht nur in eine Richtung

[nils50122]

Hallo,

ich habe folgendes Problem, habe gestern einen VPN-Tunnel von unserer Hauptstelle zur Nebenstelle aufgebaut.

Dabei sieht die Konfiguration wie folgt aus:

Hauptstelle:
LANCOM 1781EF+
Business DSL einwahl über DSL-Modem.
schon ein VPN zu einer Supportfirma vorhanden


Funktionstest: Ping auf den Nebenstellen-LANCOM möglich, auf die dahinter hängenden Clients nicht.

Nebenstelle:
LANCOM 1781EF+
Business DSL einwahl über DSL-Modem.


Funktionstest: Ping auf den Hauptstellen-LANCOM möglich, auf die dahinter hängenden Clients ebenfalls.

Firewall ist auf den Nebenstellen-Clients komplett ausgeschaltet. Die Clients sind im Intranet (Nebenstelle) erreichbar.
Ping in beiden LANCOM-Firewalls erlaubt, Firewalls aktiviert. (auch schon mit deaktivierter Firewall getestet)

Wenn ich von einem Windows Client aus der Hauptstelle den Befehl tracert *IP-Nebenstellen-Client* absetze, geht er als erstes über den Hauptstellen-LANCOM, dann über den Nebenstellen-LANCOM, bis hierhin sollte es richtig sein, dann kommt allerdings Zeitüberschreitung der Anforderung.

Vielen Dank für eure Hilfe.

[Bernie137]

Hallo,

poste doch bitte mal von der CLI (mit putty oder telnet auf Router aufschalten) die Ausgabe von "show vpn rules" von beiden Geräten.

Noch eine Anmerkung:
Die Netze sind öffentliche IPs. Ich hoffe es sind nicht Eure echten IPs, die hier stehen. Sonst ändere es bitte in etwas fiktives, denn es steht auch in ein paar Jahren noch hier

Was sich mir gerade nicht erschließt:
1. Die jeweils dahinter liegenden Netze sind jetzt DIE öffentlichen IPs,
2. oder LANs mit privaten IPs? (die für die Problemlösung gerne real gepostet werden können)

vg Bernie

[nils50122]

Hallo,

poste doch bitte mal von der CLI (mit putty oder telnet auf Router aufschalten) die Ausgabe von "show vpn rules" von beiden Geräten.

Noch eine Anmerkung:
Die Netze sind öffentliche IPs. Ich hoffe es sind nicht Eure echten IPs, die hier stehen. Sonst ändere es bitte in etwas fiktives, denn es steht auch in ein paar Jahren noch hier

Was sich mir gerade nicht erschließt:
1. Die jeweils dahinter liegenden Netze sind jetzt DIE öffentlichen IPs,
2. oder LANs mit privaten IPs? (die für die Problemlösung gerne real gepostet werden können)

vg Bernie

Das sind die internen "LAN" IPs, z.B. für einen Windows Client. Wären das öffentliche IPs hätte ich diese niemals hier gepostet.

Wir haben extra externe feste IPs vom ISP. Ich habe noch nie eine öffentliche IP gesehen die mit 164... anfängt?

Oder irre ich mich jetzt.

[Pothos]

Hi nils50122,

ja du irrst dich. 164.x.x.x ist ein öffentlicher Bereich.
Die privaten Adressbereiche sind 10.0.0.0/8 also 10.0.0.0 bis 10.255.255.255, sowie 172.16.0.0/12 also 172.16.0.0 bis 172.31.255.255 und 192.168.0.0/16 also 192.168.0.0 bis 192.168.255.255.

Zu deinem eigentlichen Problem. Wenn du die jeweiligen Endrouter auf deren lokaler IP erreichen kannst (nicht die öffentliche/WANseitige), dann ist erstmal alles richtig konfiguriert. Wenn die Clients dahinter nicht antworten, haben die meistens keinen oder einen falschen Gateway eingetragen, welcher keine entsprechende Rückroute auf das Ursprungsnetz kennt.

[Bernie137]

Hallo,

zu den IPs nochmal...

Noch eine Anmerkung:
Die Netze sind öffentliche IPs. Ich hoffe es sind nicht Eure echten IPs, die hier stehen. Sonst ändere es bitte in etwas fiktives, denn es steht auch in ein paar Jahren noch hier

Ich nahm hier an, dass es sich auf die IPs der WAN Seite der Router bezog. Wenn diese aber im LAN genutzt werden, ist es kein Problem sie zu posten, da sie hinter dem NAT des Routers verborgen sind. Prinzipiell kann es aber sein, dass die gleichen IPs 164... im Internet genutzt werden und man dann aus dem LAN auf diese IPs nicht zugreifen kann.

Zum Problem:
Mit show vpn rules ist ersichtlich, ob auch die Netzmasken korrekt passen. Im LANmonitor würde ich in die Firewall schauen, ob nicht was geblockt wird.

vg Bernie