Merkzettel: VPN Installation mit OpenVPN

Mitglied: aqui

back-to-topEinleitung


Durch die steigenden Anforderungen an VPNs, ist auch im hiesigen Forum die Zahl der technischen Fragen zum Thema VPN und insbesondere auch OpenVPN gestiegen. Mit dem Klassiker OpenVPN kann man schnell und unkompliziert einen VPN Zugang in einem existierenden, einfachen Netzwerk realisieren ohne das bestehende Netz umkonfigurieren zu müssen. So ist mit wenig Aufwand schnell und kostenschonend ein VPN Zugang für remote Mitarbeiter realisiert oder auch eine Standort VPN Kopplung möglich.
OpenVPN ist dabei nicht wählerisch was die Hardware und Betriebssystem angeht. Mit einem alten ausrangierten PC, einem preiswerten Raspberry Pi 4, einem NAS mit OpenVPN App oder was auch immer ist das schnell umgesetzt.
Ebenso haben eine Vielzahl von Routern und Firewalls sowie das alternative Router Betriebssystem OpenWRT und DD-WRT von sich aus OpenVPN schon an Bord und ersetzen hier den VPN Server.
Ob es Linux wie beim Raspberry Pi, Ubuntu, Windows, Mac OS oder der Router selber ist, spielt dabei keine Rolle. Ein weiterer Vorteil bei OpenVPN ist, das die Server und Client Konfiguration über alle Plattformen hinweg identisch ist. Ein Grund für die große Verbreitung von OpenVPN.
Zweifelsohne gibt es auch noch andere VPN Protokolle, wie das auch von der FritzBox benutzte, standartisierte und weit verbreitete IPsec. Desweiteren L2TP und das brandneue WireGuard. Alles zu behandeln würde aber den Rahmen dieses kurzen, rein auf OpenVPN bezogenen, "Merkzettels" sprengen und ist Thema weiterer VPN Tutorials hier im Forum. Die weiterführenden Links am Ende verweisen darauf.

Dieses VPN Design ist wie alle Designs, bei denen der VPN Server im internen LAN betrieben wird, nicht ideal. Technisch ist es immer besser das VPN direkt auf der Netzwerk Peripherie wie Router oder Firewall zu betreiben. VPN Traffic muss so nicht durch Löcher in der Firewall ins interne, geschützte LAN und es erhöht die Sicherheit wenn das VPN in der Peripherie terminiert ist. VPN Traffic muss hier zudem über ein gemeinsames Interface zum und vom VPN Server, was Performance und Skalierbarkeit einschränkt. Kurzum... VPNs gehören auf Imnternet Router oder Firewall !
In kleineren Netzen sind diese VPN fähigen Router oder Hardware Firewalls aber oft nicht vorhanden oder es fehlt entsprechendes KnowHow um so etwas umzusetzen oder es ist Zeitdruck bei der Realisierung.
Das Tutorial versucht mit den folgenden Installations Tips diesen Spagat zwischen Realisierung und Installation um so ggf. auftauchende Probleme schon im Vorwege zu klären.
Basis dieses "Merkzettels" ist ein einfaches lokales Netzwerk mit den klassischen Komponenten:

ovpn-grundlagen

Oder als klassische Site to Site Installation zur Kopplung mehrere IP Netze:

s2sovpn
(Wobei hier auch einer oder beide Router solche mit OpenVPN an Bord sein können. Dann entfallen natürlich OVPN Server und Client im lokalen LAN !)

Internet Router Einstellungen werden hier stellvertretend für andere Router Hardware, anhand einer FritzBox beschrieben. Billige Consumer Router haben in Firmennetzen generell nichts zu suchen aber die recht anschaulichen Setups der AVM Router gelten damit stellvertretend für ALLE verwendeten Router Modelle !
Das lokale LAN im Beispiel arbeitet mit der IP Netzwerk Adresse 192.168.188.0 /24 und das interne OpenVPN Netzwerk mit 172.17.77.0 /24.
Noch etwas zum NAT/Masquerading am Server:
Im eigenen, internen LAN ist sowas kontraproduktiv und führt dazu das kein transparentes Routing möglich ist. Einige Anleitungen im Internet gehen häufig von öffentlichen VPNs aus um Geo Location Grenzen (Streaming usw.) zu überwinden. So ein Design führt in einem Standort oder Client VPN wie hier zur Fehlfunktion. Es gilt also: KEIN NAT/Masquerading aktivieren (iptables) !!
Wichtige Tips zur VPN Adressierung findet man HIER !
Los gehts...!

back-to-topEinstellungen Router bzw. Firewall


Das Tutorial geht von einer klassischen OpenVPN Installation aus mit dem Default Port UDP 1194. Hat man das geändert, muss dies in den Konfig Dateien entsprechend angepasst werden.
Wer aus Sicherheitsgründen nicht den Standard Port verwenden will, sollte aufgrund der weltweit fest genormten Port Zuweisungen durch die IANA immer auf die sog. freien Ephemeral Ports im Bereich 49152 bis 65535 ausweichen. Diese Ports werden in der Regel von Angreifern wenig bis gar nicht gescannt. UDP 51194 oder UDP 61194 z.B. wären dann eine sinnvolle Wahl.
Oft limitieren auch vorgeschaltete Firewalls den Port. Hier kann man dann auf UDP oder auch TCP 443 (HTTPS) wechseln. TCP Enkapsulierung gilt es aber, wenn immer möglich, generell zu vermeiden, da dies meist mit erheblichen Performance Verlusten im VPN durch den größeren Paket Overhead und das aufwändigere Session Handling einher geht. UDP ist bei OpenVPN also immer primär das Protokoll der Wahl !

back-to-topIP Adressierung OpenVPN Server


Der OpenVPN Server kann generell dynamisch eine IP Adresse aus dem DHCP Bereich des Routers an seinem lokalen LAN Interface bekommen. Das hat aber einen Nachteil der sich gravierend auswirken kann.
Da eine feste, statische IP Route im Internet Router auf die lokale OpenVPN Server IP Adresse zeigt, ist es sinnvoller dem VPN Server immer eine feste und damit verlässliche IP Adresse zu vergeben. Sollte die dynamische DHCP IP Adresse sich einmal ändern läuft folglich die Route ins Leere und das VPN verliert die Verbindung. Etwas, das es zu vermeiden gilt.
Es ist also immer eine gute Idee dem VPN Server eine statische IP Adresse zu vergeben. Er ist gewissermaßen VPN Router und Router bekommen generell Prinzip bedingt immer statische IP Adressen an ihren Interfaces.
Das kann natürlich manuell am Server selbst in dessen Netzwerk Setup gemacht werden. Einfacher ist es aber über die Hardware MAC Adresse der verwendeten Server Hardware (Netzwerkkarte), dem DHCP Server im Router (Fritz Box) eine feste IP zuzuweisen.
So kann der Server flexibel auf DHCP Betrieb verbleiben (was meist Default in allen OS ist), bekommt aber so dennoch immer eine feste IP Adresse.
Das Screenshot Beispiel zeigt dies an einem FritzBox DHCP Server:
mac-neu
fritz3dhcp

Welche Hardware Adresse (Mac) der Server verwendet verrät auf dem Server das Kommando ipconfig -all (Windows) oder ifconfig (Linux, MacOS). Man kann es aber oft je nach Router Modell in dessen grafischem Übersichtsmenü sehen.

back-to-topInterne OpenVPN IP Adressierung


Der VPN Tunnel selber ist im OpenVPN ein eigenes IP Netzwerk und wird mit dem Konfig Kommando (Beispiel) server 100.64.64.0 255.255.255.0 in der Server Konfurations Datei bestimmt.
Diese interne Adressierung muss einzigartig sein im gesamten VPN Netz und ist deshalb nicht trivial, denn es gilt hier eine Überschneidung mit den zahllosen privaten_RFC1918_IP_Adressen zu vermeiden. Wie so eine Adressierung auszusehen hat wurde schon in anderen VPN Tutorials des Forums hinreichend beschrieben wie z.B. HIER.
Eine sehr elegante Alternative ist immer die Verwendung von IP-Adressen (100.64.0.0/10), die für Carrier-Grade-NAT (RFC 6598) reserviert sind. Damit ist zu jeder Zeit sichergestellt, dass die Tunnel-IPs nie mit den obigen privaten Adressbereichen der zahllosen privaten Consumer Router kollidieren können.

back-to-topPort Forwarding oder auch Port Weiterleitung bzw. Freigabe im Router


Damit VPN Clients von außen den internen OpenVPN Server überhaupt erreichen können, müssen diese die Firewall des Routers überwinden. Die Router Firewall schützt ja normalerweise ein dahinter liegendes lokales LAN wasserdicht vor solchen ungewollten Verbindungsversuchen von außen ! Ohne ein entsprechens Port Forwarding (Weiterleitung) würde die Router Firewall solche Verbindungen immer sicher verhindern mit dem Effekt das kein VPN Client den Server erreichen kann.
Man "sagt" also mit der Port Forwarding Freigabe der Router Firewall das sie doch bitte UDP 1194 auf die interne IP Adresse (192.168.188.50 = OpenVPN Server) passieren lassen soll:
fritzpfw
fritzpfw2
Diese Einstellung lässt dann am Router Internet Port dort eingehenden OpenVPN Verkehr mit UDP 1194 (und NUR diesen Verkehr !) auf die interne OpenVPN Server IP 192.168.188.50 passieren.
Daraus folgt das die VPN Ziel IP, die im Client zu konfigurieren ist immer die WAN Port/Internet IP des Routers sein muss und nicht die lokale LAN IP des VPN Servers !
fritz5uebers
Dazu auch später mehr im Client Setup.
An diesem Punkt erkennt man auch sofort den oben schon angespochenen Nachteil einer solchen internen VPN Lösung ! Wäre der VPN Server direkt auf dem Internet Router oder Firewall onboard, müsste man keine solchen "Löcher" in die Firewall bohren und das VPN Konzept wäre in sich sicherer.

back-to-topStatische Route auf internes VPN IP Netz


Der OpenVPN Server spannt intern ein eigenes IP Netz auf. Dieses muss einzigartig sein im gesamten Netz und darf nirgendwo sonst vorkommen. (Siehe Tips zum VPN IP Adressdesign oben).
Damit VPN Clients von extern alle Endgeräte, die im lokalen LAN den Internet Router als Default Router (Gateway) konfiguriert haben, per VPN erreichbar sind, muss der Router natürlich wissen wie er das interne OpenVPN IP Netz erreichen kann. Das übernimmt eine statische Route im Internet Router die allen Traffic für das OpenVPN IP Netz (hier 172.17.77.0 /24) dann an den VPN Server (192.168.188.50) sendet (siehe dazu Netzwerk Skizze oben):
fbrouneu1
fbrouneu2

Damit sind dann alle Einstellungen auf der Router und Netzwerkseite erledigt. Der Rest dreht sich nur noch um das Setup des OpenVPN Servers und der Clients.

back-to-topOpenVPN Server und Client Konfiguration


Das Tutorial setzt voraus das die entsprechende OpenVPN Software auf Clients und Server installiert ist.

back-to-topGenerieren der OpenVPN Zertifikate und Schlüssel


Das am meisten herausfordernde ToDo bei einer OpenVPN Installation ist sicher das Erzeugen der Zertifikate und Schlüssel. Laien fühlen sich damit oft überfordert, was aber mit den entsprechenden Tools nicht der Fall sein muss.
Natürlich kann man OpenVPN auch mit einem simplen, statischen Passwort verwenden (sog. Preshared Key). Davon ist in Firmennetzen aber dringenst abzuraten, denn diese statischen Schlüssel kann man durch einfache, ungeschützte Weitergabe sehr einfach kompromittieren, was dann zwingend eine Erneuerung dieses Passworts für alle User mit einem erheblichen Arbeitsaufwand zur Folge hat, will man die Sicherheit eines VPN Zugangs bewahren.
Mit individuellen User Keys werden nur diese individuell ungültig, nicht aber das gesamte VPN. Trotz der etwas größeren Mühe lohnen sich also sichere Schlüssel.
Es gibt mehrere mögliche Wege wobei drei die meist genutzten sind bei einer fehlenden PKI:
Letzteres ist zwar sehr bequem, birgt aber das Risiko der Unsicherheit, da man bei einem fremden Anbieter irgendwo im Web Daten hinterlässt und dieser theoretisch damit auch alle Schlüssel hat.
Die Handhabung des Easy-RSA Tools beschreibt ein anderes_OpenVPN_Tutorial hier im Forum. Es ist für alle Betriebssysteme vorhanden und in der Bedienung gleich.
Alle erzeugten Schlüssel sind, egal mit welchem Tool erstellt, immer über alle Betriebssystem Plattformen einsetzbar.
Letztlich geht dieses Tutorial nur auf die grafische XCA Variante ein um den Rahmen nicht zu sprengen:
XCA findet man zum Downloaden für alle Betriebssysteme hier: https://hohnstaedt.de/xca/
Unter Windows installiert man idealerweise die portable Version die man dann auch immer bequem und sicher auf einem USB Stick verwahren kann.

Nach dem Starten des XCA Tools erstellt man eine Datenbank und generiert eine Vorlage mit seinen Daten:
xcas2vorl

Im zweiten Step setzt man in der Vorlage die Gültigkeitsdauer der Zertifikate. (Es reichen hier sicher auch erstmal 5 Jahre wem die hier gesetzten 10 doch zu lang erscheinen.)
xcas3uhr

Danach speichert man die Vorlage und erzeugt der Reihe nach eine Root CA und auf Basis der Root CA Vorlage, dann die OpenVPN Server und Client Zertifikate und die Schlüssel.
Die Art der Verschlüsselung und das Hashing Verfahren wählt das XCA Tool wie auch Easy-RSA Tool automatisch.
xcas1

Zum Schluss werden die Zertifikate und Schlüssel exportiert:
xca1
xca2

Detaillierte Hilfe bietet die XCA Webseite per Video, YouTube und auch HIER

Diese exportierten Schlüssel und Zertifikate kopiert man dann in die entsprechenden OpenVPN Verzeichnisse auf Server und Client mittels USB Stick oder bei Linux, Raspberry z.B. außer USB Stick online mit WinSCP.

back-to-topIP Forwarding (Routing) im OpenVPN Server aktivieren


Der Server ist gewissermaßen auch ein Router, denn er routet ja immer zwischen dem lokalen LAN und dem internen OpenVPN Tunnel IP Netz (hier im Beispiel 172.17.77.0 /24).
Normalerweise ist aber das Routing (IP Forwarding) auf Servern, egal mit welchem Betriebssystem immer per Default deaktiviert !
Damit der Server nun IP Pakete vom lokalen LAN ins VPN IP Netz und umgekehrt senden kann muss dafür das Routing auf dem OpenVPN Server Rechner im Betriebssystem aktiviert werden.
Bei Windows geschieht das über einen Eingriff in die Registry oder die Dienste Verwaltung.
(IPEnableRouter Parameter auf 1) siehe auch: https://www.edv-lehrgang.de/ip-routing-aktivieren/

winrouteenable

Unter Linux/Raspberry editiert man mit dem nano Editor die Datei /etc/sysctl.conf und entkommentiert dort den Eintrag:
indem man das "#" vor der Zeile net.ipv4.ip_forward=1 entfernt und somit das IP Forwarding/Routing aktiviert.
Danach muss der Linux Rechner rebootet werden.

back-to-topKonfiguration OpenVPN Server


Vorab ein wichtiges Wort zur Tunnel Enkapsulierung:
Hier sollte in jedem Fall UDP als Enkapsulierungs Protokoll verwendet werden ! TCP erzeugt einen sehr großen Overhead was zu erheblichen Performance Verlusten und weiteren potentiellen Problemen wie Fragmentierung bei MTU/MSS Mismatch usw. führen kann ! Es gibt also sehr gute Gründe hier, wenn immer möglich, UDP zu verwenden ! Auch die offizielle OpenVPN Dokumentation weisst eindringlich auf das Preferieren von UDP hin !
Weitere Punkte die zu beachten sind:
  • Nicht mehr das veraltete net30 Verfahren in der Client Adressierung verwenden sondern das modernere und aktuelle subnet Verfahren.
  • Compression wegen des Security_Bugs deaktivieren. Der Effekt ist so oder so sehr gering.
  • Entsprechende VPN_IP_Adressierungstips beim Netzdesign beachten ! Wichtig: Das interne IP Netz des OpenVPN Servers ("server 172.17.77.0 255.255.255.0" Kommando i.d. Konfig) muss einzigartig sein und darf sich mit keinem anderen lokalen IP Netz doppeln ! Hier also intelligenterweise IP Adressen aus dem vorab genannten Tip wählen. Eine gute Wahl ist immer der 172.16.0.0 /12er oder 10.0.0.0 /8er Bereich statt dem häufig verwendeten 192.168er Bereich.

Weiterhin zu beachten ist das die übliche Standard Namenserweiterung (Suffix) der Konfigurationsdatei .conf bei Verwendung unter Windows in .ovpn umbenannt werden muss. Das Windows Programm Icon wechselt dann auch sofort auf das typische OpenVPN Logo.
Unter allen unixoiden Betriebssytemen (Linux, Raspberry usw.) bleibt der typische .conf Datei Suffix.
Ein abschliessendes Wort zu den Namenserweiterungen (Suffix) der Schlüsseldateien (hier .pem):
In vielen Tools enden diese auf .key. Das ist von Tool zu Tool unterschiedlich und nur ein Name und Kosmetik. Man muss lediglich in der Konfigurations Datei genau darauf achten das diese Endungen immer mit den dort angegebenen Dateinamen übereinstimmen damit sie gefunden und ausgeführt werden.

Die einfache Konfig Datei des Servers sieht so aus:
Diese Datei muss mit der Endung .ovpn (Windows) oder .conf (Linux) zusammen mit den Zertifikaten im Konfig Verzeichnis abgespeichtert werden. Also z.B. server.ovpn (Windows) oder server.conf (Linux).
Das o.a. Beispiel zeigt eine Konfig Datei mit Pfad Angaben unter Linux. Pfadangaben sind bei Windows zu ändern in die entsprechenden Windows Konfig Verzeichnisse bzw. unter Windows entfällt dies, denn bei Import der Konfig Datei über das OpenVPN Taskleisten Symbol werden die Pfade entfernt.
Alle mit "#" auskommentierten Server Kommandos sind nicht aktiv und haben die folgende Bedeutung:
  • client-to-client = Erlaubt eine Client zu Client Komunikation. Im Default ist diese nicht erlaubt sondern nur Client zu Server.
  • push "redirect-gateway def1 bypass-dhcp" = Schickt statt nur den Traffic des lokalen LANs den gesamten Client Traffic in den VPN Tunnel ! Wenn dies aktiviert wird muss man dann zwingend den Eintrag push "route 192.168.188.0 255.255.255.0" mit "#" einkommentieren oder löschen ! Niemals dürfen beide Push Optionen zusammen in der Konfig stehen !! Ein Fehler der oft gemacht wird. Es geht entweder nur Split Tunnel oder Gateway Redirect.
  • push "dhcp-option DNS 192.168.188.<dns_server>" = Schickt einen lokalen DNS Server zum Client wenn man z.B. lokale DNS Namen im lokalen LAN auflösen möchte.
Die Konfig Kommandos müssen bei Bedarf aus- oder einkommentiert werden indem man das "#" davor entfernt oder einfügt.

Nach Änderung dieser Parameter ist der OpenVPN Server neu zu starten.
Unter Linux geschieht das mit dem Kommando systemctl restart openvpn-server@135404 wobei das server hinter dem "@" den Namen der Konfig Datei ohne die ".conf" Extension (hier server.conf) im Verzeichnis etc/openvpn/server bezeichnet. So kann man bequem mehrere Konfig Dateien vorhalten.
Analog geschieht das auf der Linux Client Seite mit systemctl restart openvpn-client@client1 im Verzeichnis etc/openvpn/client
Unter Windows rechtsklickt man das OpenVPN Symbol in der Taskleiste und wählt: Konfiguration importieren.

Wer z.B. einen Linux basierten Server wie RaspberryPi u.ä. als OVPN Server betreibt sollte ebenso daran denken das dort das IPv4 Forwarding (Routing) aktiviert werden muss. Klar, denn der Server ist ja in diesem Falle auch Router zwischen lokalem LAN und internem OpenVPN IP Netz. Das erledigt man mit der Zeile net.ipv4.ip_forward=1 die in der Datei /etc/sysctl.conf entkommentiert ( "#" entfernen) werden muss.
Gleiches gilt für einen Windows Rechner wo dies über_die_Registry gemacht wird.
Danach müssen die Server rebootet werden um es zu aktivieren.

Natürlich kann man mit OpenVPN auch das gesamte Client Netz ins Server Netz routen. Das erfordert eine kleine Anpassung der Server Konfig Datei wurde hier aber bewusst aus Gründen der Übersichtlichkeit weggelassen !
In den weiterführenden Links am Schluß findet man ein solches Konfigurationsbeispiel.

back-to-topKonfiguration OpenVPN Client


Auch hier gilt unter Windows die Standard Namenserweiterung der Konfigurationsdatei .conf in .ovpn umbenennen !

Die zum Server korrespondierende Client Konfig Datei sieht dann so aus:
{code:2 }<router_wan_ip> ist hier ein Platzhalter für die WAN Port / Internet IP des Routers (siehe Übersichts Screenshot oben !) hinter dem der OpenVPN Server betrieben wird. Oder, falls der Server öffentlich ist, der direkten Server IP.
Das kann natürlich auch eine ggf. vorhandene DynDNS Hostadresse über einen der zahlreichen freien DynDNS Dienstleister sein wie z.B. myFritz! oder noip.com usw.
So bekommt man auch mit einer wechselnden IP Adresse am Router immer einen festen Zugriff auf den OpenVPN Server !

Das folgende Client Beispiel ist die Windows Konfigurations Datei. Man erkennt das hier die Pfad Angaben durch den Import über den Windows OpenVPN Client entfernt wurden:
win

Unter Linux sind diese aber zwingend erforderlich und sähe dann so aus:
ca /etc/openvpn/client/CA.crt
cert /etc/openvpn/client/Client1.crt
key /etc/openvpn/client/Client1.pem


Dann steht einem finalen Test nichts mehr im Wege...

back-to-topVPN Verbindung checken


Mit einem Doppelklick auf das VPN Symbol in der Windows Taskleiste startet man den VPN Tunnel und aktiviert auch die Log Anzeige:
wincl2
Die Meldung Initialization Sequence Completed am Schluß zeigt das alles glatt gegangen ist und der Tunnel aktiv ist. Klappt alles kann man später immer mit einem Rechtsklick auf das Symbol und "Verbinden" den VPN Tunnel aufbauen.
Entsprechend wird dann auch das Taskleisten Symbol der VPN Verbindung grün:
wincl1

Unter Linux startet systemctl restart openvpn-client@client1 die Client Verbindung. (Konfig Datei heisst client1.conf im Client Verzeichnis)

Stimmen statische Route und ist das IP Forwarding im OVPN Server aktiv verläuft ein Ping Check vom aktiven VPN Client
  • auf den OVPN Server intern: 172.17.77.1
  • auf den OVPN Server extern: 192.168.188.50
  • auf die lokale LAN IP des Routers 192.168.188.1,
  • und hier z.B. auf die Management IP Adresse des LAN Switches .22
dann ebenso erfolgreich wie auch der Aufruf z.B. des Web GUIs von Router und Switch über die remote VPN Verbindung.


back-to-topWeiterführende Links


OpenVPN Grundlagen Tutorial:
https://administrator.de/wissen/openvpn-server-installieren-pfsense-fire ...

Gesamtes Client Netzwerk routen (LAN zu LAN Kopplung):
"One armed" Lösung:
https://administrator.de/content/detail.php?id=530283&token=984#comm ...
Kaskaden Lösung:
https://administrator.de/forum/zugriff-auf-geraet-an-lte-router-via-vpn- ...

Mikrotik Router als OpenVPN Server:
https://administrator.de/content/detail.php?id=359367&token=695#comm ...

Handhabung der OpenVPN Konfig Dateien auf Debian basierten Linux Systemen (Ubuntu etc.):
https://administrator.de/content/detail.php?id=569471&token=546#comm ...

DS-Lite Anschluss und VPN: Lösung mit OpenVPN als VPN Vermittlungsserver:
https://administrator.de/forum/zwei-mobilfunkrouter-tp-link-mr200-vpn-ve ...

Grundlagen IP Routing:
https://administrator.de/wissen/routing-2-ip-netzen-windows-linux-router ...

RoutingFehler vermeiden !:
https://administrator.de/content/detail.php?id=1027836193&token=462

OpenVPN Server App auf Synology NAS:
https://idomix.de/synology-diskstation-openvpn-server-einrichten-windows ...

OpenVPN Zugang mit Radius Server absichern:
https://administrator.de/forum/pfsense-openvpn-freeradius-anfängerf ...

OpenWRT / DD-WRT OpenVPN: NAT Probleme mit der LAN zu LAN VPN Anbindung sicher umschiffen:
https://administrator.de/content/detail.php?id=481363&token=144
https://administrator.de/content/detail.php?id=494146#comment-1391482

Alternative OpenVPN Linux Anleitung (Ubuntu):
https://ctaas.de/OpenVPN_Server_Ubuntu_howto.htm

Alternative Routing Protokolle:

VPN "Merkzettel" Wireguard:
Merkzettel: VPN Installation mit Wireguard

Mobile- und Home Office User mit den bordeigenen VPN Clients (IPsec) und einer Firewall ins Netz bringen:
https://administrator.de/wissen/ipsec-vpn-mobile-benutzer-pfsense-opnsen ...

L2TP VPN für alle onboard VPN Clients auf pfSense/OPNsense Firewall:
https://administrator.de/wissen/pfsense-opnsense-client-vpn-l2tp-protoko ...

L2TP VPN für alle onboard VPN Clients auf Mikrotik Router:
https://administrator.de/content/detail.php?id=562927&token=111#comm ...

Preiswerte OpenVPN und Wireguard Router Hardware:
https://www.amazon.de/GL-iNet-GL-MT300N-V2-Repeater-Performance-Compatib ...

Raspberry Pi 4 Hardware:
https://www.reichelt.de/raspberry-pi-4-b-4x-1-5-ghz-2-gb-ram-wlan-bt-ras ...
https://www.reichelt.de/raspberry-pi-4-b-4x-1-5-ghz-4-gb-ram-wlan-bt-ras ...
Netzteil:
https://www.reichelt.de/raspberry-pi-netzteil-5-1-v-3-0-a-usb-type-c-eu- ...
Passendes Gehäuse mit passiver Kühlung:
https://www.amazon.de/iuniker-Raspberry-Gehäuse-Kühlkörpe ...

Content-Key: 561052

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

Ausgedruckt am: 24.07.2021 um 17:07 Uhr

Mitglied: Stefan007
Stefan007 26.03.2020 um 15:09:37 Uhr
Goto Top
Danke für deine Arbeit!
Mitglied: MuchoMan
MuchoMan 26.03.2020 um 15:46:10 Uhr
Goto Top
Du bist so krass :O
Mitglied: brammer
brammer 26.03.2020, aktualisiert am 27.03.2020 um 13:17:53 Uhr
Goto Top
Hallo,

Typisch @aqui! Super Arbeit!

Brammer
Mitglied: TomTomBon
TomTomBon 27.03.2020 um 08:46:36 Uhr
Goto Top
Danke für eine weitere deiner vielen konkreten und spezifischen Anleitungen.

So schreibt man Anleitungen die eineindeutig sind!
Versuche Ich auch unseren Azubis beizubringen ;-) face-wink

Mein Senf
Thomas
Mitglied: broecker
broecker 27.03.2020 um 13:41:50 Uhr
Goto Top
danke auch von mir, für die nächste Revision:
>indem man das "#" vor der Zeile net.ipv4.ip_forward=1 entfernt.
>Danach muss der Server rebootet werden.
nein, wenn Du da 'eh auf moderne Distries verweist, kann man doch ebensogut nur noch dazu schreiben:
echo "1">/proc/sys/net/ipv4/ip_forward
und auf den reboot verzichten.
Mitglied: aqui
aqui 27.03.2020 aktualisiert um 15:05:25 Uhr
Goto Top
Ich wollte die wasserdichte Anfänger Methode vorziehen. ;-) face-wink Bzw. Winblows muss man de facto rebooten.
Du hast aber natürlich Recht. Danke für den Hinweis !
Mitglied: wellknown
wellknown 30.03.2020 um 09:35:36 Uhr
Goto Top
Hut ab, sehr schöne Anleitung. Habe ich gestern mal testweise danach für einen Laptop gemacht (nutze sonst IPSEC für VPN). Bis auf Timeout-Probleme, resultierend aus Anbindung über Funk, ging das prima.
Mitglied: aqui
aqui 30.03.2020 aktualisiert um 15:32:24 Uhr
Goto Top
So sollte es auch sein mit der Umsetzung ! Danke für die Blumen... ;-) face-wink
Mitglied: it-fraggle
it-fraggle 04.04.2020 um 00:25:06 Uhr
Goto Top
Ich ziehe den Hut vor der Arbeit, die du geleistet hast. Anleitungen zu schreiben ist meist anstrengend, zeitaufwändig und oft undankbar.

Falls es nicht zu frech ist, füge ich noch hinzu, dass die pfSense (wer sie ohnehin im Einsatz hat) einen Wizard für OpenVPN hat und man das Paket "OpenVPN Client Export" zum exportieren von fertigen Client-Paketen (Cert, OpenVPN-Installer und Konfiguration) hinzuladen kann. Gerade als Laie ist das nützlich, da man recht leicht eine zertifikatbasierte VPN Verbindung bekommen kann und nicht aus Bequemlichkeit oder Frust beim "preshared Key" landet, weil es das Einzige ist, was man hinbekommen hat.
Mitglied: aqui
aqui 04.04.2020, aktualisiert am 08.09.2020 um 09:13:50 Uhr
Goto Top
Nein, ist natürlich nicht frech. ;-) face-wink Danke für den Hinweis !
Diese Option steht auch im oben zitierten generellen OpenVPN_Tutorial.
Sie ist allerdings nur für die Nutzer hilfreich die es mit einer pfSense Firewall umsetzen. Wer es mit Windows (Server), Linux, Raspberry Pi, OpenWRT oder irgend einer anderen Plattform nimmt dann meist die anderen erwähnten Tools.
Mit der pfSense hat man alternativ noch die etwas elegantere Option ganz ohne extra VPN Client auszukommen und alles mit den jeweils bordeigenen VPN Clients zu erledigen wie es in diesem_Tutorial erklärt ist.
Mitglied: fundave3
fundave3 05.04.2020 aktualisiert um 11:50:13 Uhr
Goto Top
Besten Dank für die Tolle Anleitung,

Klar macht es Sinn, das ganze auf einem Gerät zu installieren.
Ich finde es schade, dass es AVM bisher immer noch nicht auf die Kette bekommen hat, Openvpn zu implementieren.
Mitglied: aqui
aqui 05.04.2020 aktualisiert um 12:08:32 Uhr
Goto Top
Die haben Angst vor den dann massiv aufkommenden Support Fragen. Stell dir mal völlige IT DAUs vor die Zertifikate erstellen. Das kostet massiv Geld und bei einer billigen Plastik Consumer Box liegt sowas wirtschaftlich niemals drin.
Was ggf. kommen könnte ist das sie das neue Wireguard implementieren wenn es dann nun fest im Linux Kernel verankert ist. Denn wie jedermann weiss werkelt in der FritzBox auch ein Linux.
Das wird aber sicher noch etwas dauern bis das soweit ist und vor allem DAU massentauglich ist.
Generell rennt ja auch IPsec Native sauber und fehlerfrei und ist zudem auch in fast allen Betriebssystemen und Smartphones enthalten so das man dann auch mit der jetzigen VPN Funktion auf der FritzBox gut klar kommt sofern man mit dem mickrigen Durchsatz leben kann.
Man darf eben auch nicht vergessen das das ein billiges Massenprodukt sein soll und kein Business Router. Unter dieser Prämisse macht sie den Job ja sehr gut. ;-) face-wink
Wir haben zudem Routerfreiheit in der ganzen EU. Steht ja jedem frei der mehr will sich dann einen "richtigen" Router oder Firewall zu beschaffen. ;-) face-wink
Mitglied: it-fraggle
it-fraggle 05.04.2020 um 13:02:39 Uhr
Goto Top
Die haben Angst vor den dann massiv aufkommenden Support Fragen.
Ich finde mit der pfSense wird es doch genial vorgemacht. Ein Wizzard, der nur ein paar Fragen stellt und am Ende hat man ein Installationspaket für den Mac, Windows 7/8/10 und ggf. für den "Profi" die Konf mit Cert so. Meiner einer würde das sehr begrüßen. Einfacher geht es doch nicht mehr. Wer damit dann nicht zurecht kommt, der weiß auch nicht, dass es VPNs gibt.
Mitglied: aqui
aqui 05.04.2020 um 14:49:52 Uhr
Goto Top
Ich finde mit der pfSense wird es doch genial vorgemacht.
Da hast du natürlich Recht ! Wäre so kinderleicht.
Aber wer weiss was AVM da Marketing technisch bewegt ?!
Mitglied: it-fraggle
it-fraggle 05.04.2020 um 17:41:23 Uhr
Goto Top
Aber wer weiss was AVM da Marketing technisch bewegt ?!
Auch wieder wahr.
Mitglied: AnkhMorpork
AnkhMorpork 06.04.2020 um 15:01:33 Uhr
Goto Top
Spät, aber dennoch: Auch von mir ein richtig fettes Danke für diese Arbeit!

Ist in dieser Zeit mit angrenzender Sicherheitswahrscheinlichkeit perfekt im Rennen ...

Munter bleiben!
Mitglied: aqui
aqui 06.04.2020 um 18:12:45 Uhr
Goto Top
War auch die Intention. Danke für die Blumen. :-) face-smile
Mitglied: MrFeed
MrFeed 11.07.2020 um 11:55:44 Uhr
Goto Top
Coole Anteilung !!
Das hätte ich damals auch gebraucht!
Mitglied: harrysam
harrysam 05.01.2021 um 18:31:50 Uhr
Goto Top
Auch ich danke dir für die tolle Anleitung. Ich habe schon nach vielen Anleitungen gearbeitet, aber eine Client - Server - Verbindung noch nie hinbekommen. Zuerst über Internet auf einen DD-WRT-Server, zuletzt auf einem Windows10-PC, wobei Client und Server auf der selben Maschine sind. Den Server kann ich problemlos starten.
Beim Verbinden des Clients kommt der Abbruch immer mit dem gleichen Fehler:

2021-01-05 17:22:17 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2021-01-05 17:22:17 TLS Error: TLS handshake failed
2021-01-05 17:22:17 SIGUSR1[soft,tls-error] received, process restarting

Leider passiert das auch nach deiner Anleitung.
Wo liegt da nur der Fehler?
Ich versuche das schon seit Monaten, bin am Verzweifeln.
Hast du vielleicht die entscheidenden Hinweise für mich?
Viele Grüße
Harald
Mitglied: aqui
aqui 05.01.2021 um 18:46:19 Uhr
Goto Top
wobei Client und Server auf der selben Maschine sind.
Wie macht man denn sowas ?? Das ist gar nicht supportet und kann niemals klappen. Du kannst ja niemals auf derselben Maschine gleichzeitig eine Client und Server Konfig betreiben, wie sollte das gehen ??
Ausnahme natürlich da rennt ein Virtualisierer ala VirtualBox oder sowas...
Oder meinst du das du mal den einen oder mal den anderen startest ? Das ginge dann natürlich.

Der Fehler ist mit an Sicherheit grenzender Wahrscheinlichkeit die Windows Firewall bzw. das Firewall Profil. Diese blockt UDP Port 1194 Pakete und das ergibt dann den Negotiation Timeout.
Du musst also dafür sorgen das die VPN Pakete auch die lokale Firewall passieren können sonst wird das natürlich nicht klappen.
https://administrator.de/forum/windows-firewall-einstellungen-openvpn-tu ...
Mitglied: harrysam
harrysam 05.01.2021 um 20:03:52 Uhr
Goto Top
Danke für deine Antwort. Ich werde das mal auf zwei verschiedenen PC's im selben Netzwerk versuchen und mich um die Windows-Firewall kümmern.
Mitglied: harrysam
harrysam 15.01.2021 aktualisiert um 19:13:06 Uhr
Goto Top
Danke für die Hinweise, es klappt jetzt - Client -> Server im gleichen Netz und auch Client aus dem Internet zum Server.
Jetzt habe ich noch ein Problem, welches du auch schon mal behandelt hast.
Ich betreibe einen Asus RT-AC68U mit neuester DD-WRT-Firmware als OpenVPN-Server hinter einem Speedport Hybrid (zu diesem gibt es leider keine Alternative). In dem Speedport Hybrid kann man keine statischen Routen eintragen. Du hast dazu u.a. folgenden Hinweis gegeben:

"Unter Linux/Raspberry editiert man mit dem nano Editor die Datei /etc/sysctl.conf und entkommentiert dort den Eintrag:
    1. Uncomment the next line to enable packet forwarding for IPv4
    net.ipv4.ip_forward=1
    indem man das "#" vor der Zeile net.ipv4.ip_forward=1 entfernt und somit das IP Forwarding/Routing aktiviert.
    Danach muss der Linux Rechner rebootet werden."

    Leider klappt das per Telnet nicht, weil ->
    Über Telnet kann ich mich mit dem User "root" einloggen. Leider reichen damit die Rechte für das Anlegen und editieren der Datei "/etc/sysctl.conf" nicht aus (in den meisten Verzeichnissen heißt es "read only"). "sudo" ist nicht installiert, "su" funktioniert auch nicht. Ich weiß auch nicht, was für eine Art Linux drauf ist.
    Weißt du, wie man auf diesem Router wirklich alles machen kann? Welcher User, welches Passwort?
    Das wäre toll.
Mitglied: aqui
aqui 15.01.2021 um 19:29:28 Uhr
Goto Top
(zu diesem gibt es leider keine Alternative)
Das ist, wie immer, technischer Quatsch, denn das was der kann kann jeder vernüftige Dual WAN Balancing Router auch. Aber andere Baustelle und anderes Thema !
In dem Speedport Hybrid kann man keine statischen Routen eintragen. Du hast dazu u.a. folgenden Hinweis gegeben:
Das ist sehr schlecht aber kein KO Kriterium. Das bedeutet dann nur das du auf jedem einzelnen Host im lokalen Netzwerk den du via VPN ereichen willst eine eigen statische Route eintragen musst. Logisch, denn die globale Netzwerk Route kann man ja dann nicht konfigurieren wenn das in billigen Schrottroutern nicht supportet ist.
Bei einem Windows Rechner geht das dann so:
route add <internes_OVPN_netz> mask <maske> <ip_adresse_OVPN_server> -p

Du hast dazu u.a. folgenden Hinweis gegeben:
Das ist hier aber technischer Unsinn und gar nicht relevant, denn damit wird auf einem unixoiden Server (z.B. Linux) selber das IP Forwarding (Routing) aktiviert also das der OVPN Server selber routen kann.
Da du aber schon per se einen Router betreibst ist das ja vollkommen überflüssig denn das dort IP Forwarding aktiviert ist ist evident.
Abgesehen davon hat IP Forwarding nix mit statischen Routen zu tun. Zeigt eher das du nicht so wirklich verstanden hast worum es geht, kann das sein ?!

So oder so ist der gesamt Einwand auch etwas wirr. Versteht man dich richtig dann betreibst du die Speedport Gurke mit dem Asus in einer Router_Kaskade. Sprich der Speedport forwardet per eingetragenem statischen Forwarding alle UDP 1194 Pakete an den Asus und der ist selber OVPN Server, sprich er HAT also schon die Route ins interne OpenVPN Netz. Alle Clients hinter dem Asus also an seinem lokalen LAN kommen also so zentral ins OpenVPN netz weil es ja direkt am Asus Router dran ist. Eine statische Route ist also völlig überflüssig.
Dein Kaskaden Design wird also so out of the Box fehlerlos funktionieren.
Heiß diskutierte Beiträge
question
RAM-Zugriff auf einem neuen High-Performance Server, teilweise um Welten langsamer als auf einer WorkstationMysticFoxDEVor 16 StundenFrageBenchmarks41 Kommentare

Moin Zusammen, mir ist gestern beim Optimieren eines neuen Servers eine Sonderheit aufgefallen, die ich mir so beim besten Willen, momentan absolut nicht erklären kann. ...

general
Kosten nicht gerechtfertigt? Dienstleister stellt Kosten für "Troubleshooting" bei Neuanschaffung von HCI + CoreSwitchDirty2186Vor 1 TagAllgemeinZusammenarbeit17 Kommentare

Hallo Zusammen, ich interessiere mich für Eure Meinung zu dem Thema Leistungsnachweise von Systemhäusern und Dienstleistern und deren Berechnung von Leistungen. Da sich hier ja ...

info
Phishing Mail mit schädlichen Images in freier Wildbahn (.IMG Datei)wolfbleVor 1 TagInformationViren und Trojaner12 Kommentare

Moin Moin an alle Gestern bekam ich eine EMail mit irgendwelchen komischen Sepa Einzugsankündigungen die man angeblich der angehängten Datei entnehmen kann. Ging so um ...

question
Listet Microsoft Default ACLs von Windows?DerWoWussteVor 1 TagFrageSicherheit18 Kommentare

Moin Kollegen. Nach dem Sicherheits-GAU "Hivenightmare" stellt sich mir die Frage, wie ich in Zukunft sicherstellen kann, dass die ACLs der Systemdateien in Windows korrekt ...

question
Erfahrungen mit CodeTwo Exchange Migration von 2016-2019dlohnierVor 1 TagFrageExchange Server18 Kommentare

Hallo, ich möchte unseren Exchange Server 2016 der noch auf WIndows 2016 läuft auf einen Server 2019 mit Exchange 2019 migrieren. Habe das Tool "CodeTwo ...

question
Doppelte A-Records in DNSBPeterVor 1 TagFrageWindows Server10 Kommentare

Hallo, unsere Windows Notebooks registrieren sich im DNS mit ihrer Lan- und Wlan Adresse. D.h. es gibt 2 gleiche Namen mit 2 unterschiedlichen IP-Adressen. Wie ...

question
AD-Domäne über VPN beitreten -Ist das möglich?EnrixkVor 1 TagFrageWindows Netzwerk9 Kommentare

Hallo, ich bräuchte mal einen Rat von einem Netzwerkprofi. Ich habe bei mir zuhause ein Heimnetzwerk mit AD-Domäne, entsprechenden Ordnerfreigaben, NAS und servergespeicherten Windows-Profilen. Wenn ...

question
Abschlussprojekt - FiSi gelöst VerbranntesHuhnVor 1 TagFrageWeiterbildung6 Kommentare

Hallo zusammen, ich bin derzeit auf der Suche nach einem Abschlussprojekt (max. 35 Stunden) - Abgabe des Antrags - Stichtag 02.08.2021. Ich weiß jedoch nicht ...