Hilfe beim IPSec Einstieg benötigt

[Alternativende]

Hallo zusammen,
ich betreibe seit ein paar Jahren einige Standorte mit OpenVPN (alle in Verbindung mit IPCops), zwecks Fernwartung. Ich kann mich sowohl von meinen Windowsclients als auch den Linuxmaschinen problemlos mit allen Standorten verbinden und Remoteunterstützung anbieten. Soweit so gut.

Nun kommen aber neue Standorte hinzu bei denen keine IPCops sondern Router verschiedener Hersteller eingesetzt werden und bei denen es auch aus Platzgründen schwierig wäre einen zusätzlichen Rechner aufzustellen.

Diese neuen Standorte verbinden sich mit einer Zentrale per VPN (IPSec mit Zertifikaten nehme ich an) um Daten abzurufen etc.. Da ich leider noch keinen Zugriff auf die Geräte habe konnte ich mich um die VPN Einzelheiten noch nicht kümmern. Ich kenne also nur den grundsätzlichen Aufbau und schlimme Erfahrungen mit VPN Konfigurationen vor einigen Jahren mit Netgear Geräten. Nun zur Frage :

Mit welchen Programmen erreiche ich denselben oder ähnlichen Komfort wie mit OpenVPN?
Gibt es überhaupt ausreichende Möglichkeiten sich mit Linux und Windows zu jenen VPN´s zu verbinden?
Außerhalb von OpenVPN habe ich leider keinerlei Erfahrungswerte was das angeht, aber brauche unbedingt jene PointToNet Verbindungen wie bei OpenVPN.

Danke

[DynaBlaster]

Igitt, IPSEC

Bei den von meinem Arbeitgeber (also eben auch von mir) betreuten Kunden wird IPSEC seit einiger Zeit von OpenVPN der Rang abgelaufen. OpenVPN ist schlicht einfacher zu konfigurieren und wir haben wesentlich weniger Probleme mit den Endgeräten (SOHO-DSL-Router oder UMTS-Tarife ohne ESP-Unterstützung bzw. mangelhaftem VPN-Passthrough) der Roadwarrrior, die sich per VPN ins Firmennetz einwählen wollen - und die Client-Software ist obendrein auch noch umsonst.

Für IPSEC spricht, dass es quasi Industriestandard ist und viele Router oberhalb des SOHO-Bereichs von Haus aus IPSEC sprechen können, dagegen spricht defintiv die wiederspenstige Konfiguration und die oben bereits angeführten Probleme mit Endanwender-Hardware.

Wir setzen linuxseitig Openswan ein - die Windows-Clients nutzen in der Regel die IPSEC-Clientsoftware von Funkwerk (ehemals Bintec) - letztere kostet um die 80 €.

[Alternativende]

Hallo,
ja so habe ich IPSEC auch in Erinnerung. Leider kann ich aber nicht so ohne weiteres auf OpenVPN umstellen. Ich habe im Serverraum zu wenig Platz für einen weiteren IpCOP und die meisten Router unterstützen kein OpenVPN. Mit welchen Endgeräten betreibt ihr denn eure VPN´ s?

Blöd ist zudem das ich auch Windows Clientsoftware brauche da die Remotesteuerung mit der ich den Usern helfen kann nur auf Windows läuft.

Was soll ich also am besten tun? Denke nicht das ich soviele Möglichkeiten habe, etnweder ich tausche radikal die erforderlichen Endgeräte gegen Cop´s aus, vermittle das den Usern und habe wochenlang damit zu tun, oder kann keine Fernwartung insgesamt anbieten.

[DynaBlaster]

Hardwareseitig stehen bei unseren Kunden alle möglichen Endgeräte diverser Hersteller. Hauptsächlich LANCOM-Geräten, bei denen es in Bezug auf IPSEC eigentlich nichts zu meckern gibt. Geräten von Watchguard mangelt es nach meiner Erfahrung an der Einbindung von Zertifikaten für die Authentifizierung (soll wohl mit der aktuellen Firmware gehen, aber bei meinen Tests konnte ich die Watchguard zwar dazu bringen, ein gültiges SSL-Zertifikat für IPSEC samt passender Root-CA zu importieren, die Watchguard weigerte sich aber anschließend, mir dieses Zertifikat in der IPSEC-Konfiguration zu Auswahl zu geben - habe das ganze dann aus Zeitdruck dran gegeben und es wird jetzt mit einem Preshared-Key verschlüsselt und anhand der festen öffentlichen IP's authentifiziert)

Wenn bei unseren Kunden irgendwelche Linux-Server stehen, verzichten wir für Fernwartungszwecke i.d.R. auf VPN-Zugänge und nutzen stattdessen SSH inkl. SSH-Tunnel. Ansonsten halt OpenSWAN (Linux) oder die Bintec/FEC IPSEC Clientsoftware (Windows).

Wenn bei deinen Kunden Windows-Server arbeiten, könntest du auch in Erwägung ziehen, einen OpenVPN-Server auf Windows-Basis zu konfigurieren oder gleich das MS-eigene "Routing und RAS" (PPTP) zu verwenden.

[Alternativende]

Hmh OpenVPN Server auf Windowsbasis wäre zumindest für den Einstieg eine gute Sache schätze ich.
Da habe ich mein gewohntes Arbeitsumfeld und kann dann immer noch der Reihe nach auf OpenVPN umstellen.
Dafür müsste ich wahrscheinlich nur die entsprechende DynDNS Adresse auf Port 443 (wird ja von den meisten Firewalls durchgelassen,) oder einem anderen, zum Windowsserver leiten oder?

[DynaBlaster]

Jop. Einfach Port 443 oder 1194 (je nachdem, wie du den OpenVPN-Server konfigurierst) auf den Windows-Server "forwarden". Bei dieser Gelegenheit nicht vergessen, auf dem Router auch gleich (eine) statische(e) Route(n) für das VPN-Netz und ggf. das Netz hinter dem VPN-Netz auf die interne IP des Windows-OpenVPN-Servers zu setzen. Sonst hast du womöglöich das Problem, dass du die Clients im LAN "hinter" dem Windows-VPN-Server mangels (Rück-)Route nicht erreichen kannst.

[Alternativende]

Hi,
du meinst eine Route vom virtuellen Netz zur internen Adresse des Routers des Standortes, damit dieser dann verteilen kann?
Oder hab ich das falsch verstanden?

[DynaBlaster]

Naja, das wird vermutlich nicht reichen. Das Setup sähe dann ja in Etwa wie folgt aus:

OpenVPN-Client (LAN-IP:192.168.1.2, Tun-Device: 10.8.0.3) -- dein Router (192.168.1.1)-- Internet -- Kunden-Router (192.168.2.1) -- Windows-OpenVPN-Server (LAN-IP: 192.168.2.2, Tun-Device: 10.8.0.1)

Ich gehe davon aus, dass sich dein OpenVPN-Client erfolgreich über die öffentliche IP-Adrsse des Kunden (ob nun feste IP oder dyndns-Adresse spielt keine Rolle) mit dem OpenVPN-Server im Kunden-LAN verbunden hat (Port-Forwarding auf dem Kunden-Router von Port 443 bzw. 1194 an 192.168.2.2 ist also eingerichtet und funktioniert). Soweit so gut - du bist nun in der Lage, den Windows-Server, auf dem auch OpenVPN läuft, fernzusteueren, indem du eine RDP-, VNC- oder wasauchimmer-Verbindung zu 10.8.0.1 aufbaust. Problemtisch ist im jetzigen Zustand halt der Zugriff von deinem OpenVPN-Client auf die anderen Rechner im Kunden-LAN. Wenn du beispielsweise versuchen solltest, den Kunden-Rechner 192.168.2.3 zu erreichen, wird dieser ein Paket von 10.8.0.3 erhalten und seine Antwort an sein Standard-Gateway schicken - also vermutlich an 192.168.2.1. Der Kunden-Router weiss aber (noch) nicht, dass er 10.8.0.3 erreichen kann, indem er das Paket an 192.168.2.2 weiterschickt, damit dieser es an den VPN-Tunne übergeben kann - die Kommunikation scheitert.

Du hast also 2 Möglichkeiten. Enweder du nutzt den Windows-Server des Kunden quasi als Sprungbrett und baust nun von hier aus die weiteren Verbindung zu den anderen Kundenrechnern im Netz 192.168.2.0/24 auf oder du hinterlegst auf dem Kunden-Router eine statische Route für 10.0.8.0/24 über 192.168.2.2. Dann klappt auch der Zugriff von deinem OpenVPN-Client.

Ich hoffe, dass ist jetzt verständlicher

[Alternativende]

Ah ok. Danke für deine ausführliche Erklärung. Ich hoffe das es nun etwas klarer für mich ist. Bisher habe ich wie gesagt immer einen IPCop gehabt und dort musste ich keine Routen einstellen. Ich bin morgen bei dem besagten Kunden, werde mir dann die Umgebung anschauen und vielleicht komme ich auch dazu OpenVPN einzurichten.

Danke soweit!

[DynaBlaster]

Gern geschehen

Bei deinen IPCOP's war das vermutlich nie nötig, weil die eben auch als Gateway/Firewall ins Internet gedient haben und deshalb alle Clients hinter dem IPCOP die LAN-IP des IPCOP als Standard-Gateway eingetragen hatten bzw. per DHCP mitgeteilt bekommen haben. Folglich haben die Clients ihre Antwort-Pakete für alle IP-Adressenbereiche (inkl. des OpenVPN-Netzes) eben auch den IPCOP geschickt. Und der hat die Pakete dann entsprechend seiner Routingtabelle eben ins Internet weitergeleitet bzw. über sein tun-Device rausgejagt.

Wenn du dich nicht mit dem Routing rumschlagen willst, besteht auch die Möglichkeit, anstatt des tun-Devices das tap-Device zu verwenden und dieses in einer Bridge mit dem Lan-Adapter zusammenzufassen. Dann bekommt dein OpenVPN-Client eben eine IP aus dem Kunden-LAN und du hast keine weiteren Probleme.

Aber Windows und eine Bridge (da heisst das glaube ich Netzwerkbrücke). Habe ich nie gemacht und würde auch eher davon abraten

[Muddern]

Nimm dir lieber n IPFire, denn der wird noch supportet und die Leute die das entwickeln sind noch sehr aktiv. So wie ich das mitbekommen habe, wird IPCop nicht mehr supportet.

http://www.ipfire.org

MfG Muddi

[Alternativende]

Wie kommst du darauf das der IpCop nicht mehr supported wird? Die bereiten soweit ich das mitbekommen habe die nächste Major Version vor. Nur weil ein Projekt nicht jeden Monat ein Update raus bringt ist es doch nicht gleich tot.

[Muddern]

Sagen wir es mal so ich hatte gehört das es nicht mehr supportet wird. Aber sicher war ich nicht. Darum hatte ich auch geschrieben "soweit wie ich mitbekommen habe".

Wenn sie es noch supporten dann ist ja ok.

MfG Muddi

[Alternativende]

Hallo,
also ich bin heute da gewesen und auch nach einigen Stunden nicht viel schlauer.

Kommando zurück. Ich habe Ipsec Einstellungen auf dem Server gefunden und auch Preshared Keys. Allerdings sind das alles Lancom Geräte und die Konfiguration ist unheimlich kompliziert. Auf dem zentralen Gerät gibt es eine Dyndns Adresse die, so nehme ich an, von den Außenstellen des Kunden angesprochen wird.

Ich werde also zunächst eine weitere Dyndns Adresse anlegen, Portweiterleitung auf den Windowsserver 443 schalten, Statische Route auf dem Router von 10.X.X.X nach Windowsserver und dann müsste ich auf alle Clients im Kundenlan zugreifen können?

[DynaBlaster]

Hallo,
Ich werde also zunächst eine weitere Dyndns Adresse anlegen, Portweiterleitung auf den Windowsserver 443 schalten, Statische Route auf dem Router von 10.X.X.X nach Windowsserver und dann müsste ich auf alle Clients im Kundenlan zugreifen können?

Jop!

[Alternativende]

Hi,
ich probiere hier leider erfolglos rum und hoffe du kannst helfen .
Ich kann mich mit dem Netzwerk erfolgreich verbinden und auch den Server anpingen, aber wie du sagtest der Knackpunkt der Weiterleitung geht noch nicht.

Hier mal meine Config:

Code: Alles auswählen

port 1194
proto tcp
dev tun
tun-mtu 1500
#
# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see "pkcs12" directive in man page).
ca c:\\Programme\\OpenVPN\\easy-rsa\\keys\\ca.crt
cert c:\\Programme\\OpenVPN\\easy-rsa\\keys\\gg.dyndns.org.crt
key c:\\Programme\\OpenVPN\\easy-rsa\\keys\\gg.dyndns.org.key
dh c:\\Programme\\OpenVPN\\easy-rsa\\keys\\dh1024.pem

# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
server 10.200.0.0 255.255.255.0


ifconfig-pool-persist ipp.txt

# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
push "route 192.168.1.0 255.255.255.0"


# server's TUN/TAP interface.
;client-to-client
tls-server
keepalive 10 60
comp-lzo
max-clients 100
persist-key
persist-tun
status c:\\Programme\\OpenVPN\\log\\openvpn-status.log
log c:\\Programme\\OpenVPN\\log\\openvpn.log
log-append c:\\Programme\\OpenVPN\\log\\openvpn.log
verb 3

Ach ja meine Routing Verbindung im LANCOm Geräte sagt nun eine Route von 10.200.0.0 255.255.255.0 nach 192.168.1.253 (Server) aus. So ist das doch richtig oder muss ich 10.200.0..1 oder so angeben??

Ich habe nicht aufdfälliges in den Logs gesehen. Verstehe nicht warum ich nicht andere erreichen kann..

[DynaBlaster]

Ich kann mich mit dem Netzwerk erfolgreich verbinden und auch den Server anpingen, aber wie du sagtest der Knackpunkt der Weiterleitung geht noch nicht.

Ach ja meine Routing Verbindung im LANCOm Geräte sagt nun eine Route von 10.200.0.0 255.255.255.0 nach 192.168.1.253 (Server) aus. So ist das doch richtig oder muss ich 10.200.0..1 oder so angeben??

Moin,

das ist in Ordnung so,

2, 3 Ideen hätte ich trotzdem noch.

Firewall auf dem Windows-Server (192.168.1.253) ist aus?

Wie siehts mit "Routing und RAS" auf dem Windows-Server? Unter Linux musst du ja auch grundsätzlich erstmal Routing erlauben

Code: Alles auswählen

echo "1" > /proc/sys/net/ipv4/ip_forward

Durchaus möglich, dass das bei Windows auch notwendig ist - habe allerdings im Moment keine Ahnung wie. Da ich genau dieses Setup aber bei einem Kunden laufen habe, könnte ich da morgen mal stibitzen . Ich weiss, dass ich dort einen "geplanten Task" mit einem Batch-Script gebastelt habe, weil Windows Server 2003 immer wieder das "Routing und RAS" zerbröselt hat und ich dann trotz erfolgreichem Tunnelaufbau trotzdem keine Verbindung per Ping oder RDP zum Server bekommen habe (egal, ob VPN-IP oder LAN-IP des Serevrs) .

Was ist mit der Firewall auf dem LANCOM? Da läuft ja auch ne Art Linux drauf und es ist durchaus möglich, das dort die FORWARD-Kette für Pakete aus dem LAN, die für das LAN bestimmt sind, geblockt werden. Deine Antwortpakete der Kunden-Clients aus dem LAN 192.168.1.0/24 werdenn ja erst zum LAN-Interface des LANCOM geschickt, der diese dann wieder über sein LAN-Interface nach 192.168.1.253 schicken soll. Könnte sein, das seine Firewall das standardmässig blockt. Mein neulich mit OpenWRT geflashter Router hat nämlich genau dies getan. Ich habe hier zum Rumspielen und zum Testen einen KVM-Server, dessen VM's in einem anderen Subnetz liegen wie mein eigentliches LAN. Trotz Eintragen der statischen Route für dieses Netz über die LAN-IP des KVM-Servers konnte ich die VM's nicht erreichen. Schuld war wie gesagt, die FORWARD-Kette für das LAN-Interfcae auf dem OpenWRT-Router, die auf DROP stand - immerhin hat das Ding aber entsprechende Syslog-Einträge produziert und es hat nicht allzulange gedauert bis ich dahintergestiegen bin.

[Alternativende]

Hi,
ja die Firewall auf dem Server ist ausgeschaltet. Das mit dem Routing und RAS werde ich mir mal ansehen, aber habe da noch nie reingeschaut. Hast du schon bei dem Kunden schauen können was du da eingestellt hast?

Ich habe derzeit aber leider ein größeres Problem mit dem Lancom Gerät, weil er seit gestern keine Dyndns Updates mehr komme ich überhaupt nicht mehr drauf.

Edit:
So drauf komme ich nun wieder, aber sobald ich Routing und RAS am Windows Server unter Dienste starte kann ich mich zwar noch mit dem VPN verbinden, aber kann überhaupt nichts mehr erreichen. Keinen Windowsserver nichts. Sobald der Dienst wieder gestoppt ist erreiche ich zumindestens den Windowsserver wieder.

[DynaBlaster]

So drauf komme ich nun wieder, aber sobald ich Routing und RAS am Windows Server unter Dienste starte kann ich mich zwar noch mit dem VPN verbinden, aber kann überhaupt nichts mehr erreichen. Keinen Windowsserver nichts. Sobald der Dienst wieder gestoppt ist erreiche ich zumindestens den Windowsserver wieder.

Ich meine, genau dieses Phänomen habe ich bei unserem Kunden auch gehabt und über das besagte Batch-Script gelöst

Google minet das hier: http://forum.openvpn.eu/viewtopic.php?f ... 28&start=0

Wenn nötig, poste ich morgen das Batch-Script ...

[Alternativende]

Hallo,
meinst du die route-delay Angabe oder die Anpassung an der Registry? Die registry Anpassung habe ich gemacht, aber konnte den Server logischerweise nicht im vollen Betrieb neustarten (falls das überhaupt notwendig ist??).
Die route-delay Angabe werde ich morgen mal bei der Client Config und in der Server.ovpn eingeben und mal sehen was dann passiert.

Edit:
Aber es wäre trotzdem nett wenn du das Skript posten würdest .

[Alternativende]

Hallo,
also auch nach Anpassung der Registry konnte ich leider keine Verbesserung feststellen. Ich erreiche immer noch nur den Windows Server. Morgen werde ich den Server mal neu starten und schauen ob sich die Situation dadurch verbessert. Für das Script wäre ich aber dennoch sehr dankbar da mir sonst langsam die Ideen ausgehen.

[DynaBlaster]

Moin, hatte viel um die Ohren und melde mich deshalb erst heute - Sorry dafür

Was das Script angeht; das ist eine Bezeichnung, die das Ding wahrlich nicht verdient hat - jedenfalls steht folgender Kram in einer *,bat-Datei, die über den WIndows-eigenen "geplante Tasks"-Dienst irgendwann jede Nacht ausgeführt wird. Die 10 Pings auf localhost dienen nur als Ersatz/Workaround für sleep unter Linux. Soll eimfach dazu dienen, dass der Neustart des OpenVPN-Services auch genug Zeit hat, um komplett gestartet zu sein, bevor RAS aktiviert wird. Habe damals auf die Schnelel nix vergleichbares zu slepp gefunden

Code: Alles auswählen

net stop RemoteAccess
net stop OpenVPNService
net start OpenVPNService 
ping -n 10 127.0.0.1
net start RemoteAccess

[Alternativende]

Hallo,
wobei ich ja das Problem hatte das ich nach der Aktivierung von RoutingUndRAS nicht mal mehr den Windowsserver erreichen konnte. Die Anpassung an der Registry habe ich gemacht und werde die Kiste vermutlich morgen Abend aus der ferne neustarten und dann mal schauen ob es schon klappt. Falls nicht probiere ich das mit deinem Script.

Edit:
Also ich bin vorhin dagewesen und habe folgendes getan:
Registry angepasst, neu gestartet, Danach klappt die VPN Verbindung zwar immer noch aber ich erreiche nicht mal den Windowsserver per ping. Danach habe ich Routing und RAS stumpf aktiviert, aber konnte keine Verbesserung feststellen. Also die VPN Verbindung baut sich auf und es gibt auch keine Fehlermeldung, aber ich erreiche überhaupt nichts mehr im Netzwerk.

[Alternativende]

Dein Script ist Goldwert. Es scheint tatsächlich zu funktionieren. Der OpenVPN Server braucht scheinbar ein bisschen zum starten aber nach der Registry Anpassung und dem aktivieren von RAS, nach Neustart scheint es endlich zu funktionieren.
Ich überprüfe heute Abend noch mal um das ganze endgültig zu bestätigen und in meine Doku einzupflegen.

Zu aller erst aber: VIELEN VIELEN DANK!!!!