Über OpenVPN sind Clients ohne Standard Gateway nicht erreichbar
-
Von OpenVPN Clients aus kann man keine Clients im lokalen Netzwerk / Subnet pingen, erreichen, Remotedesktop herstellen,... wenn diese selber nicht den Standard Gateway (pfsense Firewall / OpenVPN Server) eingetragen haben.
Hintergrund
- es gibt in einem Rechenzentrum, angeschlossen via Glasfaser, Clients, die dort 2 Netzwerkkarten haben. Eine für den Internetzugriff über das / aus dem Rechenzentrum und eine an der Sie mit unserem Netzwerk verbunden sind. Da 2 Standardgateways dort zu anderen Problemen führt, wurde dieser einfach auf der 2. Netzwerkkarte weggelassen.
Zugriffe von Clients aus dem lokalen Netzwerk, also ohne VPN, auf die Clients im Rechenzentrum (mit einer IP aus dem lokalen Subnet) funktionieren o.P.!
Zugriffe von Clients aus dem VPN auf Clients im lokalen Subnet, bei denen der Standard Gateway gesetzt ist, funktionieren auch o.P.!
Der Ping von der Firewall auf die IP des Clients ohne Standard Gateway klappt auch.
Annahme
Die Firewall / OpenVPN Server kennt den Client nicht und leitet Anfragen aus dem VPN Subnet nicht an den Client ohne Standard Gateway weiter.Ideen????
-
@swk
Habt ihr nur ein einziges Subnetz? Zugriffe in ein anderes setzen ja auch ein Standardgateway voraus?Der VPN Server ist nicht das Standardgateway? Hätte aber deutliche Vorteile.
-
Hi und schon mal Danke für die Antwort. Ich habe das gestern nur "schnell" zwischen 2 Terminen hier eingegeben und füge gerne alles Weitere mit hinzu.
Zu deinen Fragen:
- Subnetze -> Jain
-
VPN @ Firewall == 10.0.9.0/24
-
Standard Gateway / Firewall für Company Clients == 192.168.0.1
-
Company Clients == 192.168.0.0/16
-
Clients Datacenter (extern über Glasfaser angebunden) == 1. Netzwerkkarte 172.20.0.0/24 (mit Standard Gateway des Datacenters) + 2. Netzwerkkarte 192.168.0.0/16 (ohne Standard Gateway)
-
Clients im Datacenter können aber von internen Clients über die 192er IP gepingt, Remotedesktop,... werden, gleiche Clients können aber nicht von Clients aus dem VPN Subnet erreicht werden. (Außer man trägt auf der 2. Netzwerkkarte einen "2." Standard Gateway ein, was aber zu anderen Problemen führt / nicht best practice ist.)
-
Clients im internen Netzwerk (mit Standard Gateway auf die Firewall -> 192.168.0.1) können von Clients aus dem VPN Subnet erreicht werden.
Hast du/Jemand noch Ideen?
Vielen Dank!
VG
-
@swk ich habe jetzt 3 mal deinen text gelesen:
- bitte mal einen GRAFISCHEN NETZWERKPLAN
- ich habe nicht verstanden warum eure rechner in 2 unterschiedlichen netzen hängen. kannst du mal genau erklären warum/was ihr damit bezweckt?
deshalb auch die frage nach dem grafischen netzwerkplan. vom gefühl her hätte ich es anders umgesetzt. was für dienste laufen auf den kisten, bitte so viel informationen wie möglich (bist du da der erfahrenste admin in deinem unternehmen?)
-
In unserem Plan müsste ich erst einiges unkenntlich machen.
Ich habe es auch absichtlich versucht es so einfach wie möglich zu beschreiben, damit das jede/r verstehen kann. Anscheinend hat das aber leider nicht geklappt.
Ich versuche es noch mal besser verständlich...
-
Die Clients im externen DC sind virtualisierte IIS Kundenmaschinen. Diese müssen eine Netzwerkkarte mit deren DNS (217.x.x.x./215.x.x.x.), Gateway (172.20.0.1) und einer zugewiesenen IP haben (zB 172.20.0.15), weil das ihr weg über eine prof. Firewall nach draußen ist, bzw. der weg rein zu Ihnen über Port 80/443.
-
In dem externen DC haben wir dann einen Switch stehen, der über Glasfaser mit dem Gegenpart bei Uns im Serverraum verbunden ist. Dieser ist dann wiederum an das interne Netz angeschlossen. Hinter/an diesem Switch im DC sind dann diese virtualisierte IIS Kundenmaschinen angebunden. Diese Anbindung geschah über je Kundenmaschine eine weitere virtuelle Netzwerkkarte. Welcher wir dann in unser Subnetz (192.168.0.0/16) gebracht haben und auch unsere internen DNS eingetragen haben. Nur halt nicht den internen Gateway.
-
Der springende Punkt ist jetzt nur, dass man solch eine Kundenmaschine (zB 192.168.0.251) im internen Netzwerk erreichen kann und über das VPN nicht. (unsere Firewall==VPN Server) Sobald die Kundenmaschine aber dann mal zum Test temp. einen 2. Gateway (zB 192.168.0.1) auf der 2. Karte eigentragen bekommen, dann kann ich diese Maschinen auch aus dem VPN erreichen.
Das war es schon.
Wir haben auch eine Lösung, diese ich aber nicht so ganz komfortable.
Wenn man, und das sind eher wenige, auf solch eine Kundenmaschine will, dann schaltet man sich halt erst auf eine vorhandene Proxy Maschine im internen Netz auf und dann auf die im DC. Das geht ja alles o.P., ist halt nur...Ich/wir wollen nur verstehen, ob wir da was machen können, woran wir nicht gedacht haben. (Bist du in deinem Unternehmen der Netzwerkspezialist und brauchst das hier technischer? Wenn dir was fehlt, du Vorschläge hast woran es liegen könnte u/o was man evtl. noch anpassen kann, dann immer gerne. Falls dir noch Informationen fehlen, dann liefere ich die natürlich auch gerne.)
-
-
@swk
VPN Clients bekommen vom Server eine virtuelle IP zugewiesen und verwenden diese für die Kommunikation über die VPN als Quell-IP.
Das VPN Netz ist immer ein anderes Subnetz (TAP mode ausgenommen). Die Zielgeräte, die der Client kontaktiert, schicken ihre Antwortpakete auf die Quell-IP des Request-Pakets, also auf eine IP aus dem VPN Tunnel Pool.
Nachdem das Ziel nicht innerhalb ihres eigenen Subnetzes liegt und sie keine Route für diese IP haben, schicken sie die Antwort auf ihr Standardgateway.Das Problem sind also Clients, die nicht den VPN Server als Standardgateway verwenden. Die 2. Netzwerkkarte im Netz der pfSense macht die Sache um nichts besser.
Mir fallen drei mögliche Lösungen ein (ohne den VPN Server aufs Standardgateway zu verlegen):
-
Masquerading: D.h., der VPN Server erstetzt die Quell-IP in Paketen von VPN Client durch seine eigene Interface IP.
Damit sehen die Zielgeräte eine IP aus ihrem eignen Subnetz (ggf. 2. Netzwerkkarte) und antworten auf diese, also zur pfSense.
Nachteil: der wahre Client bleibt dem Zielgerät verborgen, alle VPN Clients greifen mit der IP der pfSense zu. -
Transit Netzwerk einrichten. Das ist ein Netzwerk zwischen dem VPN Server und dem Standardgateway. Auf letzterem setzt du eine statische Route für den VPN-Tunnel, der auf die pfSense IP zeigt.
Ist dieses Standardgateway nicht auf der pfSense eingerichtet, braucht es auch da statische Routen für das 172.x.x.x er Netz.
Das ist die optimale Lösung. -
Eine statische Route für das VPN Tunnel Netz auf jedem Gerät, das über die VPN erreicht werden soll und den VPN Server nicht als Standardgateway nutzt.
Das bedeutet halt etwas Arbeit. Wenn die Geräte per DHCP konfiguriert sind, kannst du aber auch darüber die Route verteilen.
-
-
@swk ok, wenn ihr eine professionelle (komisch ich finde die sense sehr professionel) firewall habt, warum macht ihr dann nicht mit der vpn, würde doch alles einfacher machen für dich?
leider hast du nicht auf meine frage geantwortet ob du bei dir der netzwerkprofi bist (ich beschäftige mich schon ein paar jahre mit der sense)
also nochmal:
- warum wird auf der professionellen firewall keine vpn gemacht und so ein unprofessionelles produkt wie die sense für vpn genutzt?
- wie @viragomann geschrieben hat kannst du eine statische route setzen (das war heute morgen auch schon mein gedanke, wollte nur die begründung verstehen)
-
SRY, wir scheinen andere Sprachen zu Reden / ich mich falsch auszudrücken / ....
Wir nutzen die PFSENSE Software und später die Netgate Hardware seit ? ca. 10 Jahren? Das ist für mich meine prof. Firewall/VPN Server, weil ich bisher super zufrieden bin.
Und die Frage ob ich der Netzwerkprofi bin, fand ich nicht relevant. Alle Kollegen der Infrastruktur schauen hier drauf / das wird in unserem MO/DO Weekly Jourfixes angesprochen.
Ich finde die Idee mit der statischen Route auch super und werde Sie sobald ich kann ausprobieren und hier zurückmelden.
VIELEN DANK @viragomann
-
VIELEN LIEBEN DANK!
Du hast uns auf die richtige Spur gebracht. Wir haben es erstmal mit der statischen Route auf den Clients im DC getestet / gelöst und haben uns die Lösung mit dem Transit Netzwerk für später (Aufwand/Nutzen-Faktor) vorgemerkt.
@micneu Danke auch dir, dass du dir die Zeit genommen hast!
-
@swk said in Über OpenVPN sind Clients ohne Standard Gateway nicht erreichbar:
Der springende Punkt ist jetzt nur, dass man solch eine Kundenmaschine (zB 192.168.0.251) im internen Netzwerk erreichen kann und über das VPN nicht. (unsere Firewall==VPN Server) Sobald die Kundenmaschine aber dann mal zum Test temp. einen 2. Gateway (zB 192.168.0.1) auf der 2. Karte eigentragen bekommen, dann kann ich diese Maschinen auch aus dem VPN erreichen.
Soweit ich das gerade ohne groben Netzplan vom Flow verstanden habe und @viragomann auch schon schrieb ist das alles lediglich eine etwas verkorkste Design/Architekturfrage und ein Routingproblem Wie schon gesagt ist das VPN Subnetz von der Einwahl den Maschinen nicht bekannt, sie schickens über das Default GW raus und das wars dann.
Wenn ihr dann nochmal davor eine (andere) Firewall habt, könnt ihr das entweder ausgleichen, indem ihr dort direkt eine Route nach innen macht (wenn die externe FW mit euren internen Netzen irgendwie verbastelt ist), oder ihr müsstet - was unschön ist - die ganzen Kundenkisten mit ner zusätzlichen Route ausstatten.
Alternative: Ihr NATtet die OpenVPN ausgehend zu den Kundenmaschinen auf eine andere IP der pfSense, die von den Kundenkisten aus gesehen/erreicht werden kann (ohne extra Route). Dann seht ihr zwar auf den IIS Mühlen nicht mehr direkt welche VPN IP ankommt, sondern nur noch die NAT IP, aber dann sollte es auch ohne zusätzliche Route klappen.
Wie gesagt das ist nur "der Normalfall", wie das in eurem spezifischen Netzaufbau aussieht kann ich nicht 100% sagen, da ich die Architektur nicht ganz durchschaue.Es klingt aber auch so, als ob eure IIS Kisten dann via 2. Interface eure Firewall unterlaufen indem sie "hinten raus" zu euch direkte Verbindungen aufbauen. Das kann man machen, aber aus einem Security Sichtpunkt ist das nicht sehr schön, da ihr hier ein Breakout baut der nicht durch die Firewall davor geschützt ist und dem explizit vertraut wird. Zudem sehen sich je nach Setup die Kisten dann über dieses Interface auch oder können Verbindungen aufbauen die sie nicht sollten.
Da würde ich ggf. nochmal eine Runde mit einem Netzplan drehen und mit den Kollegen oder ggf. auch mit "Sicht von außen" das einfach mal durchgehen, ob man das nicht optimieren könnte oder ggf. sinnvoller aufbauen. :)
Machen wir/ich z.B. relativ häufig für Kunden.Cheers
\jens
