OpenVPN - Kein Ping von DS auf VPN Clients möglich

[light1]

Hallo zusammen,

ich kann von der DS (VPN-Server) aus keinen meiner VPN Clients anpingen.
Die DS steht im LAN (192.168.178.x) und desweiteren noch andere Rechner.
Das VPN-Subnetz ist 192.168.177.x.
Zum Test habe ich einen lokalen Rechner per OpenVPN mit der DS verbunden, der dann die IP 192.168.177.10 erhielt.
Wenn ich mich per SSH an der DS anmelde kann ich aber den Rechner mit IP 192.168.177.10 nicht anpingen.
Umgekehrt geht es allerdings schon, d.h. vom Rechner aus kann ich die IP 192.168.177.1 anpingen.

Ich habe gelesen, dass ich da nicht der einzige mit diesem Problem bin.


Hintergrund ist, dass ich von meinem lokalen Rechner durch den VPN Tunnel einen externen VPN Client (10.31.16.0) erreichen möchte. Ich hatte diese Anleitung befolgt, aber leider blieb das erfolglos.
Deshalb wollte ich erstmal versuchen meine VPN Clients vom Server anzupingen. Da das schonmal nicht funktioniert bin ich jetzt am Ende.
Ich dachte, wenn der externe VPN-Client eine IP 192.168.177.6 und der lokale Rechner eine VPN IP 192.168.177.10 erhält, müssten da doch Pings problemlos möglich sein?

Weiß jemand warum vom VPN Server aus keine Pings zu den Clients durchdringen?

PS: hier die Ausgabe von route -n der DS:

 

[fpo4711]

Ich dachte, wenn der externe VPN-Client eine IP 192.168.177.6 und der lokale Rechner eine VPN IP 192.168.177.10 erhält, müssten da doch Pings problemlos möglich sein?

Das kann niemals funktionieren. Generell gilt für VPN auf der DS

Clientsubnetz ungleich Tunnelsubnetz ungleich Serversubnetz.

Folge der verlinkten Anleitung dann funktioniert das auch. Und wenn Du von deinem Rechner zum Clienten pingen willst mußt Du auch wie in der Anleitung angegeben eine statische Route auf deinem Router einrichten.

Gruß Frank

 

[light1]

Hallo Frank,

danke für die Antwort.
Da habe ich wohl etwas zu einfach gedacht. Aber ich verstehe immer noch nicht warum man von der DS (VPN-Server) verbundene Clients mit der VPN-IP nicht anpingen kann? Noch nicht mal die, die im LAN sind?

Ich bin der Anleitung gefolgt, aber es funktioniert leider noch nicht.
In der CCD-Datei habe ich

iroute 10.31.16.0 255.255.240.0

(das Subnetz des externen VPN-Clients) eingetragen und in der server-conf:

route 10.31.16.0 255.255.240.0
client-config-dir ccd
client-to-client

.

Das Problem ist, dass der externe VPN-Client (Subnetz 10.31.16.0) im WLAN Netz einer Hochschule ist. Wenn ich das richtig verstanden habe, sollen statische Routen zwischen den Routern der beiden LANs eingerichtet werden.
Soll die statische Route auf die externe IP des Routers des externen Clients zeigen und andersrum der Router des externen Clients auf den Router des VPN-Servers?
Da könnte hier das Rechenzentrum leider etwas dagegen haben.

Im Grunde wäre es am besten, wenn Broadcasts durch das VPN an alle Clients gesendet werden. Da wäre dann TAP statt TUN wohl die bessere Wahl. Aber ich habe hier auch gelesen, dass das auf der DS nicht so einfach ist.
Es würde aber auch funktionieren, wenn ich einen LAN-Rechner mit seiner IP 192.168.178.31 erreichen könnte (funktioniert von Haus aus), und auch andersrum den externen VPN-Client (10.31.1x.x) von dem LAN aus erreichen könnte.
Dann müsste ich halt immer die IPs angeben, wenn der Broadcast-discovery nicht funktioniert.

Gruß Martin

 

[fpo4711]

Broadcasts werden per VPN auf der DS nicht übertragen (Nur ab OSI-Schicht 3). Und glaub mir, eine echte Bridge per TAP mit einem Uni-Netz das willst Du bestimmt nicht.

Ich hoffe mal Du hast auch das Radiusplugin deaktiviert. Ansonsten wird dir der Inhalt in der Datei im ccd-Verzeichnis überschrieben. Und auch den VPN-Server neu gestartet.

Die statischen Routen sind nur auf den Gateways nötig wenn auch von anderen Clienten in den jeweiligen Netzen über den Tunnel auf das beteiligte Subnetz zugegriffen werden soll. Wenn Du deinen Clienten nicht pingen kannst muß das nicht zwangsläufig bedeuten das Du ihn nicht erreichen kannst. Ist beispielsweise auf einer DS die Firewall aktiviert muß auch das Protokoll ICMP freigegeben werden.

Nach der Änderung der Configfiles wie in der Anleitung beschrieben solltest Du auf jeden Fall von der DS einen verbundenen Client erreichen können (sofern die Angaben den Netzen entsprechen). Auch kannst Du den Clienten mit der Tunnel-IP erreichen die Dir der VPN-Server in der GUI anzeigt. Die kann sich aber bei jeder Verbindung ändern und ist somit keine gute Lösung aber darüber kannst Du den Ping prüfen.

Wenn alles richtig konfiguriert ist solltest Du in der Routingtabelle auf der DS (Server) folgende Änderungen feststellen können. Vor dem Start des VPN-Server keine Route zum Subnetz des Clienten. Nach dem Start Route zum Clientsubnetz. Ist das nicht der Fall stimmt schon einmal etwas nicht mit der openvpn.conf.

Falls Route vorhanden (oder auch wenn nicht) kannst Du ja den Paketweg über "traceroute ...." verfolgen.Läuft der über das TUN-Device aber nichts kommt zurück stimmt wahrscheinlich etwas mit der Angabe in der ccd nicht "iroute ....."

Gruß Frank

 

[light1]

Hallo Frank,

Ich hoffe mal Du hast auch das Radiusplugin deaktiviert. Ansonsten wird dir der Inhalt in der Datei im ccd-Verzeichnis überschrieben. Und auch den VPN-Server neu gestartet.

ich habe in der radiusplugin.cnf overwriteccfiles auf false gesetzt. So sieht es aus:
Anhang anzeigen 23713

Die statischen Routen sind nur auf den Gateways nötig wenn auch von anderen Clienten in den jeweiligen Netzen über den Tunnel auf das beteiligte Subnetz zugegriffen werden soll.

Ich möchte ja nur von einem LAN Rechner durch seinen Tunnel zur DS und von dort aus durch den jeweiligen anderen Tunnel zum externen Client. Also brauche ich da dann keine statische Route?

Vor dem VPN-Server Start sieht die Routing-Tabelle ziemlich leer aus:
Anhang anzeigen 23714

Nach dem VPN-Server Start sind einige Einträge dazugekommen (unter anderem das 10.31.16.0 Subnetz des externen VPN-Clients):
Anhang anzeigen 23715
Was mich hier jedoch wundert ist der 192.168.177.2 Gateway. Ich kann ihn weder anpingen, noch weiß ich wo der herkommt.
Alle Packete Richtung 192.168.177.x (VPN-Subnetz) müssten ja durch diesen Eintrag abgedeckt sein:

 192.168.177.0   192.168.177.2   255.255.255.0   UG    0      0        0 tun0

Das heißt alle werden zum Gateway 192.168.177.2 geschickt, aber wo kommt der raus?

Ich habe mal mit Wireshark die Pakete analysiert die mit traceroute Richtung des externen VPN-Clients geschickt werden. Der LAN-Rechner schickt den Ping durch den VPN-Tunnel zur DS und dort bleiben sie dann stecken. Als erster hop wird 192.168.177.1 angegeben und das wars dann.

Der Ping von der DS Richtung LAN-Rechner außerhalb des Tunnels, also 192.168.178.31 (LAN-Subnetz) funktioniert problemlos.
Die Firewall der DS habe ich auch testweise ausgeschalten und auch ICMP zugelassen.
Es wollen trotzdem keine Pings durch irgendwelche VPN-Tunnel gehen von der DS aus gehen. Wie oben gesagt bleiben ja auch die traces bei der DS stecken, wenn sie durch andere Tunnel weitergeleitet werden sollen.
Es scheint also ob nur Pakete durch Tunnel geroutet werden können, wenn die Verbindung auch von dem Tunnel-Besitzer initiiert wurde.
Von extern können VPN-Clients ja auf LAN-Rechner zugreifen. Nur andersrum kann keiner durch den Tunnel, außer der ihn geöffnet hat.

Falls Route vorhanden (oder auch wenn nicht) kannst Du ja den Paketweg über "traceroute ...." verfolgen.Läuft der über das TUN-Device aber nichts kommt zurück stimmt wahrscheinlich etwas mit der Angabe in der ccd nicht "iroute ....."

Das ist mein Eintrag für die ccd datei "martin", mit Subnetz des externen VPN-Clients:


Danke für die Hilfe, um Routing Sachen habe ich schon immer einen Bogen gemacht.

Gruß Martin

 

[fpo4711]

 192.168.177.0   192.168.177.2   255.255.255.0   UG    0      0        0 tun0

Das ist ein ganz normaler Eintrag sofern dein VPN-Tunnel-Subnetz die 192.168.177.0/24 ist. Das ist der VPN-Server da selbst, das ist nicht dein Client. Wenn sich dein Client verbunden hat sollte er auf der Server-Seite die 192.168.177.5 haben.

Wenn Du mit Wireshark klar kommst, da baue doch von der Clientseite eine Verbindung auf mache auf der DS eine Shell auf und schicke Dir an deine lokale IP (Die des Clienten) also irgendwas mit 10.31.16.X einen Ping. Dann solltest Du sehen können wie ein Paket über das TUN-Device ankommt.

Deine Anlagen kann ich leider nicht aufrufen. Aber hilfreich wäre mal die komplette Routingtabelle von der Server als auch von der Clientseite wenn eine Verbindung aufgebaut ist.

Und ich hoffe Du testest das auch von extern, sonst geht das Routing eh in die Hose. Aber generell braucht es sowohl eine Hin- als auch eine Rückroute.

Gruß Frank

 

[light1]

Deine Anlagen kann ich leider nicht aufrufen. Aber hilfreich wäre mal die komplette Routingtabelle von der Server als auch von der Clientseite wenn eine Verbindung aufgebaut ist.

Oh da ist beim Hochladen wohl was schief gelaufen.

Die Routingtabelle des Servers sieht nach der Herstellung einer Verbindung zu einem Client exakt gleich aus. Der einzige Unterschied ist vor dem VPN-Server Start und nach dem Start.
Hier vor dem Start:


Und hier nach dem Start:



Ich habe versucht den externen VPN-Client mit seiner IP (10.31.28.33) vom internen VPN-Client des LAN-Rechners (VPN-IP 192.168.177.10) anzupingen. Hier ein Snapshot aus dem Wireshark logging auf dem TAP Windows Adapter des LAN-Rechners:

Die Pings gehen raus, gehen aber ins Leere bzw. es kommt keine Antwort zurück.

Hier ist ein Ping von der DS(VPN-IP 192.168.177.1) Richtung externer VPN-Client-IP (192.168.177.10) zu sehen (tcpdump auf der DS):

Die TCP Pakete kommen wahrscheinlich von der SSH-Session. Interessant ist, dass die ICMP und auch TCP Pakete beide die gleiche Zieladresse haben, jedoch unterschiedlichen Ursprungs sind. Die SSH kommt von der LAN-IP der DS (192.168.178.3) und die Pings von der VPN-IP der DS (192.168.177.1). Die SSH-Pakete bekommen jedoch eine Antwort von dem externen Client, nur die Pings nicht.

Hier noch ein Snapshot von Traffic gecaptchert per tcpdump auf der DS:

192.168.178.31 ist die LAN-IP des Rechners und die TCP Verbindung entsprechend die TeamViewer Sitzung zwischen externem VPN-Client (192.168.177.6) und LAN-Rechner.
Die Pakete von der LAN-IP des Rechners werden durchgereicht, aber der Ping von der DS mit IP 192.168.177.1 bekommt wieder keine Antwort.

Langsam bin ich echt ratlos.

baue doch von der Clientseite eine Verbindung auf mache auf der DS eine Shell auf und schicke Dir an deine lokale IP (Die des Clienten) also irgendwas mit 10.31.16.X einen Ping. Dann solltest Du sehen können wie ein Paket über das TUN-Device ankommt.

Das habe ich auch gemacht. Nur kommt bei dem externen Client nichts an. Kein ICMP Paket und entsprechend ist der Ping von der Shell aus erfolglos.
Comodo Firewall habe ich auch schon deaktiviert. Ich habe mal gelesen, dass es vielleicht auch mit den Windows-Adapter "Public, Work, Private" Netzwerkeinstellungen zusammenhängen kann. Bei mir ist der der TAP-Adapter aber schon private.

 

[fpo4711]

Tut mir leid ich steige bei deinen Angaben nicht durch. Solche Sätze wie

Ich habe versucht den externen VPN-Client mit seiner IP (10.31.28.33) vom internen VPN-Client des LAN-Rechners (VPN-IP 192.168.177.10) anzupingen

erzeugen bei mir nur Verwirrung. Was ist denn ein internen VPN-Client des LAN-Rechners?

Solltest Du damit den Tunnel-Endpunkt auf der Clientseite meinen kannst Du den mit der 192.168.177.1 mit einem Ping von der Serverseite erreichen sofern Du mit nur einem Clienten verbunden bist und dein Tunnel-Subnetz die 192.168.177.0/24 (Nennt sich im VPN-Server bei Synology dynamische IP und sollte dann 192.168.177.1 in der GUI ausweisen.

Hier mal der umgekehrte Weg - So müssen die Routingtabellen aussehen wenn das Server-Subnetz 192.168.0.0/24, das Tunnel-Subnetz die 10.8.0.0/24 und das Clientsubnetz die 192.168.1.0 ist und alles korrekt konfiguriert ist. Kannst das ja auf deine Subnetze übersetzen. Diese Einträge müssen vorhanden sein.

Server

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         fritz.box       0.0.0.0         UG    0      0        0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
192.168.1.0     10.8.0.2        255.255.255.0   UG    0      0        0 tun0


Client

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         fritz.box       0.0.0.0         UG    0      0        0 eth0
10.8.0.0        10.8.0.5        255.255.255.0   UG    0      0        0 tun0
10.8.0.5        *               255.255.255.255 UH    0      0        0 tun0
192.168.0.0     10.8.0.5        255.255.255.0   UG    0      0        0 tun0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

Auch im VPN-Server "Clients den Server-Lan Zugriff erlauben angehakt"

Gruß Frank

 

[light1]

Was ist denn ein internen VPN-Client des LAN-Rechners?

Als intern meine ich innerhalb des LAN-Subnetzes, wo auch die DS steht. Extern meine ich außerhalb des LANs. D.h. ein interner VPN-Client des LAN-Rechners ist der Tunnel zwischen LAN-Rechner und DS, so meine ich das
Ich bin mir nicht sicher ob ich nun zwischen LAN-Rechner und DS auch eine VPN-Tunnel brauche um den externen VPN-Client zu erreichen. Eigentlich bräuchte ich ja dann nur einen Routen-Eintrag Richtung Subnetz des externen Clients (10.31.16.0) mit Gateway 192.168.178.3 der DS. Die Pings müssten ja dann zur DS geschickt werden, und die hat ja einen Routing-Eintrag Richtung externem Client-Subnetz durch den Tunnel. Habe ich probiert, geht aber auch nicht.

Die Routing-Tabelle auf dem Server ist - übersetzt - exakt gleich bei mir wie bei Dir. Nur auf den Clients (Windows) sind es wesentlich mehr Einträge.
Der externe VPN-Client (192.168.177.6) hat eine Route zum LAN mit Gateway 192.168.177.5. Pings zum LAN-Rechner gehen ohne Probleme durch:


Vor der VPN-Verbindung sieht die Routing Tabelle auf dem LAN-Rechner so aus:


Mit der VPN-Verbidnung sieht die Routing Tabelle auf dem LAN-Rechner dann so aus:


Ich habe redirect-gateway aktiviert, also sollten ja ohnehin alle Pakete zur DS kommen. Da diese ja eine Route zum externen Subnetz hat und durch tun0 tunnelt, müsste die das ja dann weiterleiten.
Der LAN-Rechner erhält keine Route zum externen Client Subnetz, aber trotzdem sollte das durch redirect-gateway abgedeckt sein. Trotzdem geht kein Ping durch, und tracert macht noch nicht einmal einen einzigen Hop.
Ich habe dann auf dem LAN-Rechner manuell die Route zum externen Client Subnetz (10.31.16.0/20) hinzugefügt:


Tracert in diese Richtung macht aber immer noch keinen Hop bei der DS:


Den Haken bei "Clients-den Server-LAN Zugriff erlauben" habe ich aktiviert.
Ich frage mich ob das hier an dem Uni-Netz liegt. Client-zu-Client Verbindungen werden hier ja auch weitestgehend unterbunden, d.h. Pings zu anderen PCs im gleichen WLAN-Netz gehen meistens verloren.
Aber da VPN ja ein Tunnel ist, dürfte das ja eigentlich nicht der Fall sein.
Ich habe die DS auch neu gestartet, aber keine Änderung.

Nachtrag:
Ich habe gerade versucht per TCP eine Verbindung vom LAN-Rechner zum externen VPN-Client 10.31.28.33 aufzubauen, aber es gibt ein Connection timeout.

 

[light1]

Ich habe das ganze noch einmal in einem privaten externen Netzwerk getestet, also der externe VPN-Client war sozusagen nicht im Uni sondern im privaten Subnetz.
Pings vom LAN-Rechner gingen trotzdem nicht durch den Tunnel zum externen VPN-Client und auch die DS konnte den externen Client mit seiner lokalen IP nicht anpingen.

Da die DS den LAN-Rechner mit seiner lokalen IP anpingen kann, aber nicht den externen VPN-Client mit seiner lokalen IP, vermute ich mal dass es hier schon hakt.
So lange die DS selber nichtmal durch den Tunnel pingen kann, wie soll es dann der LAN-Rechner schaffen?

Setup war übrigens ähnlich wie obiger Beitrag (Routen von der DS alle vorhanden)

Als nächstes werde ich mal versuchen einen anderen Laptop zu verwenden. Vielleicht sogar mal via VM-Linux um Betriebssystem bzw. Rechnerkonfigurationen auszuschließen.