OVPN Server auf Windows mit Redirect Gateway

[Bob.Dig]

Naja, ich hab ja kein LAN, das passt also schon mal nicht.

PfSense sagt, es sei verbunden, der Server sagt das gleiche. Ping geht aber von beiden Seiten nicht. Geschweige denn Traffic durch.

Trübsal bricht aus.

 

[snaxilian]

Ja dann halt WAN statt LAN, bisschen Transferleistung sollte schon sein

im Eingangspost schreibst du was von Client-Traffic, jetzt auf einmal doch von einer pfSense? Also willst du kein Roadwarrior Setup sondern ein site-to-site VPN? Ach ne, ich soll ja nicht spekulieren hast du gesagt.
Tja dann musst du wohl Infos liefern und zwar nicht nur so Häppchen mit denen man nix anfangen kann und ich hab keine Lust dir die Infos aus der Nase zu ziehen. Du möchtest Hilfe/Unterstützung/Denkanstöße also solltest DU liefern...

Also:

• Was genau willst du erreichen? Beschreibe dies und nicht was du meinst was die richtige Lösung wäre.
• Beschreibe dein Ist-Aufbau und die Topologie aller! beteiligten Systeme
• Gibt es explizite Gründe für openVPN oder Hauptsache VPN? Warum dann nicht das windows-eigene VPN oder Wireguard?

 

[Bob.Dig]

Moin, eine Nacht drüber geschlafen (mehr oder minder) und das Problem identifiziert. Es ist wohl so, dass OVPN Fehler als "Warnungen" betitelt. Ich bin diese nun angegangen und es funktioniert. Etwas, was ich mir für die Zukunft merken muss.

Sat Jul 11 09:41:06 2020 82.119.22.105:27710 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1558'
Sat Jul 11 09:41:06 2020 82.119.22.105:27710 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'

Beispielsweise MTU habe ich nirgends (wissendlich) definiert, OVPN kann sich aber auch nicht adaptiv drauf einstellen, wie es scheint.
Habe mich diesbezüglich dann einfach bei den OVPN-Client-Configs von meinem VPN-Provider bedient und das eingestreut:
tun-mtu 1500;tun-mtu-extra 32;mssfix 1450
Dazu dann noch cipher und auth angehoben.

Spoiler: server-config

port 1194
proto udp4
dev tun
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\server.crt"
key "C:\\Program Files\\OpenVPN\\config\\server.key"
dh "C:\\Program Files\\OpenVPN\\config\\dh2048.pem"
topology subnet
server 10.66.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
keepalive 10 120
cipher AES-256-GCM
auth SHA512
comp-lzo no
persist-key
persist-tun
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
status openvpn-status.log
verb 3
explicit-exit-notify 1

Im Speedtest gibt es zumindest keine Auffälligkeiten.

Was mich jetzt noch stört, sind die offenen Ports, vermutlich durch die Installation der Remote Access-Rolle, auch wenn ich mir nicht sicher bin. Wie hier am Besten oder Praktikabelsten vorgehen, einfach manuell in der Windows-Firewall schließen? Könnte jetzt nicht behaupten, dass ich mich viel mit Windows Server beschäftigt hätte, eher das Gegenteil (seit einer Woche). 😀

 

[snaxilian]

Wenn der Server mit dem nackten Arsch im Internet hängt: Ja, dann hast du keine andere Wahl bzw. Option.
1) Prüfen auf welchem "Modus" der WAN-Port läuft, also ob private, public oder domain network > sollte public sein
2) Windows-Firewall öffnen und die entsprechenden vorhandenen Freigaben anpassen/ändern und nicht nur auf Anwendung/Port/Protokoll achten sondern auch auf welches Profil die Regel greift.

 

[Bob.Dig]

Habe 80,135,445,3389 händisch "geschlossen". Damit sind die ersten 1000 Ports alle zu. Profil ist eh klar. Ich vermute, dass ist ausreichend.

Allerdings habe ich schon wieder eine neue Herausforderung, die immer noch ONTOPIC ist:
Ich möchte gewissen IPv6-Traffic @home mittels einer OVPN-Client-Verbindung zu dem hier im Thread besprochenen OVPN-Server (auf Windows, welcher sich auf einem VPS befindet) ins Internet "ausleiten".
Für IPv4 funktioniert das bei mir schon wunderbar.
Aber für IPv6 habe ich es nicht hinbekommen, trotz aller Rumpfuscherei.

@home und @VPS haben beide IPv6. Probleme können sowohl in der Client-Config vorliegen, die ich hier nicht gezeigt habe, als auch beim Server, ggf. auch auf dem VPS selbst (wie schon bei IPv4, Stichwort NAT). Dem VPS ist ein öffentlicher /64-Prefix zugeordnet.
Ich meine irgendwo gelesen zu haben, dass man im Tunnel selbst gar kein IPv6 bräuchte? Irgendwie scheinen aber alle Anleitungen schon für den Tunnel den öffentlichen 64-Prefix des (VPS-)Servers zu nehmen?

 

[Bob.Dig]

Ok, habe es jetzt lauffähig bekommen, aber das mit der Umleitung funktioniert so wahrscheinlich nicht für IPv6.

 

[snaxilian]

Ja... nein so funktioniert das nicht sauber. Du kannst nicht 1:1 dein Wissen von IPv4 nehmen und auf IPv6 werfen.

• Afaik musst bei proto noch udp6 ergänzen.
• fe80::/64 sind für link-local unicasts vorgesehen. Das ist nicht das Gleiche wie die privaten Adressen im IPv4 Adressraum. Dafür besser/korrekt geeignet wären Unique local unicast Adressen

Wenn ich es einrichten müsste würde ich mich an dieser Anleitung orientieren: https://www.sugar-camp.com/openvpn-und-ipv6-ein-harter-kampf/
Den Teil mit dem IPv6 forwarding musst dann eben für Windows zurecht frickeln aber das ist dann eine Windows-Baustelle und hat ja weniger mit ovpn zu tun. Da kann ich leider nicht weiterhelfen, da ich das weder bisher gemacht habe noch jemals auf die Idee käme ein Windows als Router zu verwenden^^

 

[Bob.Dig]

@snaxilian Das Problem bei den Guides ist, viele sind verdammt alt. 😉
udp6 muss man nicht mehr ergänzen. Und ich habe inzwischen für den Tunnel öffentlichen IPv6 "Space" genutzt.
Mein "Client" hat auch eine öffentliche IPv6-Adresse. Nur ist mein Client ja nicht ein Rechner, sondern die pfSense und für das, was ich will, bräuchte ich jetzt quasi wieder irgendwie NAT? Mir fällt überhaupt nicht ein, wie sich das theoretisch realisieren lässt. Deswegen sage ich, vielleicht geht es so gar nicht mit OVPN.

 

[snaxilian]

Gut zu wissen mit dem udp/udp6.

Soll nur deine pfsense den v6 Tunnel nutzen oder Clients hinter der v6? Falls letzteres ist deine pfsense alles aber kein Client, da du dann ein site-to-site VPN nutzt und die pfsense Traffic von Clients durch den Tunnel schickt.
Wenn dein Provider für den Windows-Server dir ein festes v6 Subnetz anbietet, das eine Prefix Länge kleiner /64 bieten würde dann könntest du auf dem Win-Server per Prefix Delegation statische öffentliche IPv6 Adressen im Tunnel als auch dahinter verwenden so zumindest mein Verständnis. Macht dein Provider aber nicht.

Du wirfst hier auch wieder NAT und ULA durcheinander obwohl die nicht zwingend zusammen gehen. ULAs kann man wunderbar nutzen für die Separierung interner Netze. Du hast ein Subnet A für die Clients hinter der pfSense und du hast ein Subnet B für den Traffic zwischen pfSense und ovpn. Traffic dazwischen wird per Routingtabellen erledigt. In deinem Fall kommt anschließend ein NAT am Win-Server dazu wenn Traffic aus dem ovpn Tunnel ins Internet will. Es gibt aber auch zig Anwendungsbeispiele wo man ULAs verwendet inklusive VPNs bei denen aber nicht ein einziges Mal ein NAT zum tragen kommt.

Deswegen sage ich, vielleicht geht es gar nicht so mit OVPN

Tja um das beurteilen und dir sinnvoll weiter helfen zu können müsste man schon deinen kompletten Use-Case und deinen Aufbau etc kennen aber das verheimlichst du weiterhin, daher kann man dir hier nur schwer bis gar nicht weiter helfen. Vielleicht ist ovpn auch gar nicht das richtige und wir haben hier mal wieder ein Paradebeispiel für ein XY-Problem aber bisher kam von dir ja nur: Lösung X will nicht, was muss ich anpassen? Wir kennen jedoch nicht das Ziel, dass du verfolgst 🤷‍♂️

 

[Bob.Dig]

@snaxilian Eigentlich werfe ich gar nichts durcheinander, insbesondere kein ULA und NAT.

Mein Usecase:
Konkret mache ich schon folgendes mit IPv4. Ein Server an einem Interface der pfSense @home schickt eine E-Mail ins Internet. Dieser Traffic wird aber schon auf dem Interface "policy geroutet" auf/in/zu einer VPN-Client Verbindung in der pfSense. Darüber geht die E-Mail dann über (m)einen VPS raus ins Internet. Auf dem VPS läuft nur OVPN, kein E-Mail Server! Ich mache also quasi das, was auch die "VPN-Provider" machen. Der Vorteil für mich ist, dass die E-Mail nicht mit meinem dynamischen IP @home beim Empfangsserver ankommt, sondern mit der vom VPS, einer statischen Server IPv4.
Dasselbe mit IPv6 realisieren geht vermutlich nicht, weil niemand IPv6 und NAT macht?
Ich könnte aber ggf. stattdessen den /64-Prefix des VPS nutzen und quasi auch bei mir @home deployen? Das wäre zwar etwas anderes, aber ich könnte halt ebenfalls die IPv6-Adressen des VPS zum E-Mail-Versenden nutzen? 😉

 

[snaxilian]

Bin aus dem Alter raus wo ich mir relevante Informationen aus Textaufgaben extrahiere, zumindest wenn es um freiwillige Hilfe geht und vielleicht verstehst du meine mehrfachen Bitten nach einer simplen Skizze auch nicht daher verlinke ich ein Beispiel: https://www.lucidchart.com/pages/templates/network-diagram/internet-network-diagram-template

Jetzt kommen wir also langsam wie ne Schildkröte endlich dem Y näher worum es eigentlich geht. Das hätten wir auch ohne Verschwendung von Lebenszeit auf Seite 1 des Threads haben können. Du eierst für nichts und wieder nichts herum! Komm auf den Punkt was du erreichen willst und nicht was du meinst erreichen zu wollen. Das hilft niemandem. Du bekommst nicht die bestmöglichste Lösung und andere verlieren massivst die Lust, dir weiter helfen zu wollen.

Du willst also an einem Anschluss mit dynamischer IP einen Mailserver betreiben und hast dir dieses ganze Gefrickel ausgedacht um auch Mails an Dritte versenden zu können. Da fallen mir direkt zwei drei Möglichkeiten ein wie man das um ein Vielfaches einfacher haben könnte:
1. Nutzung eines beliebigen für die eigenen Bedürfnisse passenden Smarthost. Bei überschaubarem Mailaufkommen (unter 3000 Stk. im Monat) kannst z.B. gmail nutzen. Mailserver steht bei dir zuhause, mx zeigt auf die entsprechende dyndns Adresse. Ausgehende Mails schickt dein Mailserver an den smtp von Google, authentifiziert sich dabei und der Google smtp schickt die Mail dann weiter an den Empfänger.
2. Betreiben eines eigenen Smarthosts. Da wird gefühlt die kleinste VM ausreichen die man findet (1 vCPU, 1-2 GB Ram, <10GB Speicher) mit nem beliebigen Linux und Postfix. Theoretisch könntest nicht nur darüber Mails versenden sondern auch empfangen und an den Server zuhause weiter leiten. Wenn du das nicht selbst komplett von 0 auf hochziehen willst könntest dir z.B. das Proxmox Mail Gateway ansehen.
3. Du verschiebst den Mailserver aus dem LAN ins Internet und Mails sendende Systeme im LAN bekommen User auf dem Mailserver oder du packst ins LAN nen weiteren MTA der den Mailserver im Internet als Smarthost verwendet.

 

[Bob.Dig]

@snaxilian Nope. Ich wollte nichts von deinen Lösungen. Warum? Weil das kein Business ist sondern Hobby. Ich wollte einen OVPN-Server auf Windows auf meinem VPS und den habe ich nun. Bis auf die neuerliche IPv6 Geschichte, dazu habe ich aus anderer Quelle gehört, ich bräuchte dafür ein zweites öffentliches IPv6 Subnet, für welches netcup leider einen zusätzlichen Euro pro Monat veranschlagt, was für mich nicht in Frage kommt, läuft es jetzt ausgezeichnet.
Bedenke, dass ich bereits schrieb, ich will soviel viel möglich zu hause haben und so wenig wie möglich bei dritten, wozu ich selbst schon den VPS gezählt habe.

Die IPv6 Geschichte ist eh kein echtes Problem, weil ich das schon erfolgreich über Hurricane Electric mache. Für E-Mail ist IPv6 außerdem eh noch optional. Mich hätte als Alternative nur eine Lösung über den VPS interessiert, scheint aber wie gesagt schwierig.

 

[snaxilian]

Meine drei Lösungen sind alles Hobby-Lösungen, beruflich setze ich öffentliche statische IPs voraus oder würde den Kunden an o365 verweisen.
Ich kann den Wunsch verstehen möglichst viel selbst zu betreiben was ich selbst mache. Aber ich stelle zuerst die Anforderungen auf und entscheide mich dann für die bestmöglichste Lösung anstatt mir einen Zielzustand auszudenken und dann mit viel Aufwand und Umwegen meine Anforderungen da dran zu pappen.
Wenn es jetzt für dich so funktioniert ist doch gut für dich.

Mir wäre das zu komplex. Es erzeugt unnötige Abhängigkeiten und erschwert das troubleshooting wenn etwas nicht mehr so funktioniert wie es eigentlich sollte. Zum lernen ja, da hab ich auch abstruse Setups oder bau mir in der Firma eine Testumgebung auf aber privat und beruflich-produktiv heißt es: So sicher wie möglich und nur so komplex wie nötig.

 

[Bob.Dig]

@Masamune2 @snaxilian @VDC
Momentan habe ich ja einen VPS mit Windows Server und darin einen OVPN-Server. Meine pfSense @Home ist mittels OVPN-Client mit besagtem Server verbunden.
Ich leite nun Traffic aus meinem Heimnetz über den VPS ins Internet.

Kann ich dies auch andersherum bewerkstelligen, also externe Ports an meinem VPS auf einen Rechner in meinem Heimnetz routen?

 

[snaxilian]

Klar geht das, so funktionieren ja die ganzen Portmapper Dienste. Du lässt eine (Sub-)Domain auf deinen VPS zeigen. Dort richtest du ein Portforwarding ein was dann "in" deinen VPN-Tunnel zeigt und an der Gegenstelle, also der pfSense machst das nächste Portforwarding auf das Zielsystem.
Dein VPS muss dafür grundlegende Routingfunktionen beherrschen.

 

[Bob.Dig]

Dein VPS muss dafür grundlegende Routingfunktionen beherrschen.

Cool. Jetzt ist das OS ja gegeben, Windows Server.

Wie würde ich also da vorgehen müssen.

 

[snaxilian]

Wieder zu faul zum selber googlen, ja?^^
https://serverfault.com/questions/655356/windows-server-2012-port-forward-for-specifc-host
Eventuell musst auf dem Windows VPS noch routing bzw. forwarding aktivieren und eventuell die Routingtabelle anpassen damit der VPS weiß welche (privaten) Subnetze über das VPN erreichbar sind. Zu guter Letzt hilft auch ein Blick in die Firewall, da diese die ein- und ggf. ausgehenden Verbindungen erlauben muss.

 

[Bob.Dig]

@snaxilian Also dein Treffer liest sich für mich nicht wie eine Hilfestellung bei meinem Problem.
Als absoluter Laie brauch ich da was handfesteres.


Ich vermute hier spielt sich ein Großteil der Lösung ab? Auf die Kommandozeile möchte ich nach Möglichkeit verzichten, deswegen ja Windows. 😉

Ergänzung (4. Oktober 2020)

Kann es sein, dass ich auch OVPN anders konfigurieren muss, als site2site VPN? Bis jetzt ist es ja nur ein Client-Server Geschichte...

 

[snaxilian]

Auf die Kommandozeile möchte ich nach Möglichkeit verzichten, deswegen ja Windows.

insert random Simpsons Nelson haha meme
Selbst Microsoft hat mit ihrem neuen CEO verstanden, dass im administrativen Umfeld APIs und CLIs die Zukunft sind. Es gibt heute schon einige Funktionen von Microsoft Produkten, die ausschließlich per CLI konfigurierbar sind.
Bei Klickibunti kann ich dir nicht weiter helfen. "netsh portproxy" ist am Ende, das was du vor hast und das ist sowohl in meinem Link mit Beispiel gezeigt als auch dort verlinkt auch wenn der technet Artikel auf Server 2008 zeigt aber die aktuelle Version lässt sich dann ja leicht finden.
Der von dir gezeigte Menüpunkt behandelt NAT. NAT und Portforwardings hängen zwar irgendwie zusammen, sind aber nicht das Gleiche. Ich kann dir das Konzept erklären und Hinweise zur Umsetzung geben aber nicht spezifische Klickibunti-Fotostrecken.
Da du zwei Netze (zuhause + Internet) verbinden willst und Traffic in beide Richtungen fließen soll wäre site2site natürlich die bessere bzw. korrektere Einstellung.

 

[Bob.Dig]

@snaxilian Werde ich eine statische Route setzen müssen auf dem Server (noch nie gemacht)?
Werde ich den OVPN-Tunnel anpassen müssen?
Kommandozeile hin oder her.

Deine Antworten sind halt so gut wie nie Laien gerecht. Und da ich kaum Ahnung habe, führt alles rumprobieren nicht zum gewünschten Erfolg.