22.08.2023

2314

OpenVPN oder Wireguard mit IPv4 und IPv6

Hallo Admins,

stehe gerade vor der Option meine RaspberryPis mit Site2Site auf Wireguard von OpenVPN zu wechseln, da es von außen nur für IPv4 eingerichtet ist. Die OpenVPN Anleitung und Support von @aqui haben mir damals sehr geholfen und im Prinzip bin ich mit OpenVPN recht zufrieden.

Ich informiere mich gerade, welcher Aufwand größer ist: OpenVPN IPv4 mit IPv6 zu ergänzen oder Wireguard aufzusetzen. Da ich mich noch gut an die Leiden erinnern kann, die das OpenVPN Setup mit sich gebracht hat (Wahl der richtigen Verschlüsselung und Herausfinden der Kombinationsmöglichkeiten bis hin zu route, iroute und schließlich der iptables Konfiguration), denke ich nun zweimal drüber nach. Habt ihr hier einen allgemeinen Rat?

Habe mir dazu auch schon mal diese Anleitung durchgelesen: Merkzettel: VPN Installation mit Wireguard

Speziell zu Wireguard: Vor ein paar Monaten bin ich auf nftables umgestiegen. Ich könnte also die iptables Befehle postup/postdown nicht 1:1 nutzen. Den Nat-Teil sollte man nach der Anleitung sogar weglassen. Würde es dann reichen, wenn ich so vorgehe:
postup = add rule ip my_filter_table my_forward_chain iifname "wg0" accept
postdown = delete rule ip my_filter_table my_forward_chain iifname "wg0" accept

- Alternativ könnte man den postup Befehl auch direkt in nftables dauerhaft platzieren, korrekt? Dann wäre der Tunnel halt immer offen.
- Wieso wird der Port für Wireguard nicht ebenfalls bei postup geöffnet, sondern müsste über die Firewall gemacht werden? Beispiel: add rule ip my_filter_table my_input_chain iifname "eth0" ct state new udp dport 999999 counter accept

Wireguard / OpenVPN mit IPv6:
- Müsste ich in nftables in <family> jeweils "ip6" ergänzen bzw. durch "inet" pauschal ersetzen oder sollte man hier vorsichtig sein?
- Gäbe es daneben noch weitere Anpassungen, die man in nftables durchführen müsste, damit Wireguard oder OpenVPN mit IPv6 laufen oder könnte ich meine Firewall im Prinzip so belassen?
- IPv6 Seiten gehen ja aktuell an meiner VPN vorbei. Liegt das daran, dass ich über IPv4 mit dem Server verbunden bin oder würde der Traffic darüber laufen, wenn ich es in nftables "ip" durch "inet" ersetze? Ich vermute ersteres.
- Wie verhält es sich aber in meinem IPv6-Setup in Zukunft bei Seiten, die noch und nur IPv4 nutzen?

Ich hoffe, das waren jetzt nicht zu viele Basic-Fragen.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 11789002786

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

Ausgedruckt am: 19.11.2024 um 07:11 Uhr

16 Kommentare

Neuester Kommentar

Moin,

Zitat von @meltinsands:
Da ich mich noch gut an die Leiden erinnern kann, die das OpenVPN Setup mit sich gebracht hat (Wahl der richtigen Verschlüsselung und Herausfinden der Kombinationsmöglichkeiten bis hin zu route, iroute und schließlich der iptables Konfiguration), denke ich nun zweimal drüber nach. Habt ihr hier einen allgemeinen Rat?

dieses Leiden kann man sich ersparen, sowohl für OpenVPN, als auch für Wireguard -> https://pivpn.io
ufw am besten vorher schon aktivieren, dann erkennt pivpn das ufw aktiv ist und ergänzt gleich die Regeln für die Ports.

Lernen tut man bei den Anleitungen von @aqui aber natürlich deutlich mehr.

Gruß Thomas

Danke für die 💐 ! 😊

Alternativ könnte man den postup Befehl auch direkt in nftables dauerhaft platzieren, korrekt?

Wäre die deutlich bessere Lösung.
So sähe das beispielhaft mit einer /etc/nftables.conf aus:

#!/usr/sbin/nft -f

flush ruleset

define pub_iface = "eth0"  
define wg_port = 56821
define wg_iface = wg0

table inet filter {
	chain input {
		type filter hook input priority 0; policy drop;
		# accept any localhost traffic
		iif lo accept

		# accept any wireguard traffic
		# iifname $wg_iface tcp dport http accept
		iifname $wg_iface accept

		# accept traffic originated from us
		ct state established,related accept

		# accepted ICMP types
		# ip protocol icmp icmp type {echo-request, echo-reply, time-exceeded, parameter-problem, destination-unreachable } accept
		ip protocol icmp icmp type {time-exceeded, parameter-problem, destination-unreachable } accept

		# accept common local TCP services on public interface
		# tcp dport { ssh, http, https } ct state new accept
		iif $pub_iface tcp dport { ssh } ct state new accept

		# accepted UDP ports on public interface 
		iif $pub_iface udp dport { isakmp, ipsec-nat-t, $wg_port } accept 
		iif $pub_iface ip protocol esp accept 

		# allow IPsec VPN networks
		meta ipsec exists accept

		# accept neighbour discovery otherwise IPv6 connectivity breaks.
		ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept

		# log and count dropped traffic
		# log prefix "[nftables]Denied: " counter drop 
		# only count dropped traffic
		counter drop
	}
	chain forward {
		type filter hook forward priority 0;
	}
	chain output {
		type filter hook output priority 0;
	}
} 

(Das Beispiel lässt IPsec passieren weil der Server parallel zu Wireguard noch als IPsec VPN Server arbeitet ohne den Zwang mit externer VPN Client Software rumfrickeln zu müssen. Bei reinem Wireguard kannst du das weglassen.)
Du kannst sehen das z.B. "iifname $wg_iface tcp dport http accept" rein nur HTTP Traffic im Tunnel zulassen würde. Du kannst hier also sehr fein und vor allem zentral definieren was in den Tunnel soll und was nicht.

Müsste ich in nftables in <family> jeweils "ip6" ergänzen

Nein, das Ruleset arbeitet parallel für v4 und v6 wenn du inet als Family angibst. Siehe HIER. (Doku lesen hilft wirklich! 😉)

Gäbe es daneben noch weitere Anpassungen, die man in nftables durchführen müsste

Nein, sofern du die relevanten Ports passieren lässt.

IPv6 Seiten gehen ja aktuell an meiner VPN vorbei

Das liegt dann an deiner fehlerhaften Konfig?!

Wie verhält es sich aber in meinem IPv6-Setup in Zukunft bei Seiten...

Wenn du rein nur v6 machst werden die schlicht nicht angezeigt. Üblicherweise macht man deshalb ja Dual Stack Betrieb.

Irgendwie wollte ich mich da selbst durchquälen und hätte am Ende ohnehin viel manuell anpassen müssen. Dachte aber auch, es ist weniger aufwendig. Vorteil wäre also mit PiVPN nur, der Server ist innerhalb von Sekunden aufgesetzt und funktioniert. Man hat also schonmal eine Basis zum weiter arbeiten.

Das liegt dann an deiner fehlerhaften Konfig?!

Interessant. Mir wurde mal gesagt, es liegt daran, dass ich die Verbindung zum Server über meine IPv4 aufbaue statt auch über IPv6.

Wie ich zu dieser Einschätzung komme, dass IPv6 Seiten vorbei geroutet werden:
https://www.dnsleaktest.com/ sagt mir einen Leak bei IPv6
https://www.dein-ip-check.de sagt mir bei IPv6 meinen wahren Standort

Wenn es nun nicht daran liegt, dass ich über IPv4 zum Server komme, kannst du mir hier 2-3 Anhaltspunkte geben wie ich es beheben kann?

Wie sieht denn deine Wireguard Konfig aus? Hast du denn IPv6 only oder als Dual Stack konfiguriert?
https://www.hardill.me.uk/wordpress/2021/04/20/setting-up-wireguard-ipv6 ...

Zitat von @aqui:

Wie sieht denn deine Wireguard Konfig aus? Hast du denn IPv6 only oder als Dual Stack konfiguriert?
https://www.hardill.me.uk/wordpress/2021/04/20/setting-up-wireguard-ipv6 ...

Im Moment läuft noch OpenVPN 2.4

Lesenswert zu der Thematik:
https://www.heise.de/select/ct/2018/13/1529374309620058

Zitat von @aqui:

Lesenswert zu der Thematik:
https://www.heise.de/select/ct/2018/13/1529374309620058

Danke! Werde ich mir nochmal in Ruhe ansehen und versuchen entsprechend einzurichten.

War noch nie ein großer c't Fan. Wird wohl auch so bleiben. Es wird einfach zu viel vorausgesetzt und bleibt dann umkonkret für mich. Nur ein Beispiel: IPv6-Tunnel sind bei DS-Lite-Anschlüssen jedoch nicht sinnvoll. --> Wo liegt das Problem? Ich würde auf die IPv6 des Raspi über einen DynDNS Service zugreifen. DS-Lite macht doch gerade bei IPv4 Problemen.

Zurück zum Thema. Es ist wohl weniger ein Problem OpenVPN mit IPv6 auszustatten, als dass man IPv6 erstmal versteht. Je mehr ich mich damit auseinandersetze, desto komplexer wird es...und ich verwirrter. Darf ich hier nochmal fragen:

Meine Fritz!Box spannt im Heimnetz ein fd00 Netz auf, was ähnlich sind zu den 192er IPv4 Adressen ist. Jedes Gerät erhält jedoch eine individuelle fe80 Adresse, mit dem ich es im Heimnetz erreiche. Zudem gibt es noch die globale Adressen wie 2a02.

Ohne das hier zu sehr zu vertiefen...

Sollte man in der Fritz!Box (Client und/oder Server?) einen eigenen ULA Präfix festlegen und wie sollte dieser aussehen? (Ich nutze OpenVPN 2.4 aber wird demnächst durch 2.5 ersetzt)
Ich habe von Problemen gelesen, wenn der Raspberry seine IPv6 nicht aus der Mac Adresse ermittelt. Hilft es daher: nano /etc/dhcpcd.conf

slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
#slaac private 
net.ipv6.conf.all.forwarding=1 

siehe Wireguard IPv6 im Tunnel verwenden - Verbindung klappt aber keine Daten

Trägt man im DynDNS Service die "scope global dynamic mngtmpaddr noprefixroute" aus "ip -6 addr" des Raspberry ein?

Nun braucht der OpenVPN noch seine Informationen:

Der OpenVPN Server spannt neben dem 10.8.0.0er Netz ein eigenes IPv6 Netz auf. Wie "bestimme" ich es und müsste bei server-ipv6 stehen?
Eng damit verbunden ist ja die CCD Datei, in der ich jedem Client eine feste IPv4 mit dem 10er Präfix gebe. Wie macht man das unter IPv6?

...und die Konfiguration in der Fritz!Box:

Die Portfreigabe erfolgt auf Basis der IPv6 des Raspberry.
Daneben folgen noch die statischen Routen. Analog der statischen Route von IPv4 für IPv6:

Fritz!Box auf Serverseite (Clientseite) für lokales Netz:
IPv6 Netzwerk = Präfix des Client (Server) Netzwerks (lokales fd00 oder globales 2a02?)
Präfixlänge = 64
Gateway = IPv6 des Servers

Fritz!Box für OpenVPN-Server Netz:
IPv6 Netzwerk = Präfix des OpenVPN-Server Netzwerks (wie oben definiert)
Präfixlänge = 64
Gateway = IPv6 des Servers

In der c't heißt es zudem: Setzen Sie anstatt 2001:db8:aa00:abba::/64 den Subnetzbereich ein, den Sie für Ihr VPN vorgesehen haben.

Wieso ist der Subnetzbereich ein globaler Bereich, der auch ins Internet routet und kein lokaler wie fd00?

Und weiter: Tragen Sie anstatt 2001:db8:aa00:abba::1 und ::2 die Tunnel-Adressen Ihres Servers ein.

Was sind denn die Tunnel-Adressen meines Servers und wieso gibt es ihn mit ::1 und ::2?

Und weiter: Entfernen Sie die beiden Zeilen, die mit "push redirect…" und "push DHCP…" beginnen.

Leider auch keine Erklärung und damit würde doch nur noch lokaler Traffic über den Server gehen.

Mir den Infos werde ich mich dann weiter durch den Dschungel kämpfen.

PS: Willst du nicht deine OpenVPN Anleitung um IPv6 ergänzen?

War noch nie ein großer c't Fan.

Das ist traurig und man fragt sich Warum? Liest du lieber Computer Blöd?
Aber mal ehrlich: Wenn du an dem Niveau schon scheiterst and wird das obige eine echte Herausforderung für dich. Der ct' Artikel beschreibt zumindestens für OpenVPN eine saubere und gute Lösung. Aber egal...

Es ist wohl weniger ein Problem OpenVPN mit IPv6 auszustatten, als dass man IPv6 erstmal versteht.

Das ist natürlich richtig aber kann man ja sehr leicht und auch noch kostenfrei schnell ändern:
https://danrl.com/ipv6/
Durchlesen und dann hast du IPv6 durchschaut!! 😉

Meine Fritz!Box spannt im Heimnetz ein fd00 Netz auf, was ähnlich sind zu den 192er IPv4 Adressen ist.

Das ist aber falsch und ziemlich kontraproduktiv Unique Local Unicasts zu verwenden wenn du einen Provider Anschluss mit IPv6 im Dual Stack oder als DS-Lite hast!!! Das solltest du dann dringenst wieder entfernen!

Zudem gibt es noch die globale Adressen wie 2a02.

Richtig, denn IPv6 hat immer mehrere Adressen auf dem Interface wenn man Global Unicasts im Netz hat, also ein öffentliches IPv6 Netz zugewiesen bekommen hat vom Provider. Bei einem reinen IPv4 Netz hast du lediglich Link Local Unicasts mit fe80::/10
Siehe https://de.wikipedia.org/wiki/IPv6

Wie "bestimme" ich es und müsste bei server-ipv6 stehen?

Da du kein öffentliches v6 Netz hast muss es ein ULA sein aus dem Bereich fc00::/7 wo derzeit meist nur der Präfix fd verwendet wird.
Zudem erlaubt die IANA auch 2001:DB8::/32 für Dokumentationen zu verwenden. Das erklärt dann auch gleich deine "Subnetz" Frage von oben!

Siehe RFC3849

die mit "push redirect…" und "push DHCP…" beginnen.

Das ist das Entfernen des Gateway Redirects und Umschalten auf Split Tunneling. Siehe hier.

Danke für die Anregungen und vermutlich sehr guten Literaturlinks. Bitte keinesfalls falsch verstehen, aber hätte mir allerdings etwas mehr konkrete Antworten auf die Fragen erhofft. Auch wenn Hilfe zur Selbsthilfe sicherlich gut ist.

Wie gesagt, beim c't Artikel ging es mehr um die IPv6 Problematik, weniger, wie man es dann in OpenVPN einbaut. Ich weiß, dass die c't von den meisten doch sehr geschätzt wird.

Deine Fragen sind doch alle beantwortet?! 🤔

Wie "bestimme" ich es und müsste bei server-ipv6 stehen?

server-ipv6 fd00:dead:beef:affe::/64 tun-ipv6
push tun-ipv6
ifconfig-ipv6 fd00:dead:beef:affe::1 fd00:dead:beef:affe::2
push "route-ipv6 fd00:dead:beef:cafe:: ::2/64"   

IPv6 Netzwerk = Präfix des Client (Server) Netzwerks (lokales fd00 oder globales 2a02?)

Hier bist du gezwungen ein fd00 zu nehmen wie z.B. fd00:dead:beef:cafe::, denn dein öffentliches v6 Netz im internen LAN wechselt ja alle naslang da du zyklisch per PD immer andere Netze vom Provider bekommst. Die kann man also nicht nehmen, denn bei jedem PD Wechel wäre dein VPN tot. Es sei denn du hast bei deinem Provider ein festes v6 Präfix gebucht?! Insofern brauchts du doch ein 3tes Netz.
Fehlte noch was?

Da war das fehlende Puzzleteil. IPv6 liegt mir nun etwas näher als noch am Anfang. Es löst einiges anders und bringt neue Herausforderungen mit sich

Da ist auch der c't Artikel besser zu verstehen. Vielleicht werde ich dann doch noch zum Fan... Hier sind meine Anpassungen mit der Bitte um ein Feedback. Die Qualität hat hoffentlich auch etwas angezogen

manuelle ULA auf Fritzbox Heim-Netz: fd00:rout:bsp:fra::
manuelle ULA auf Fritzbox Client-Netz: fd00:rout:bsp:hkf::

Ergänzungen in der Server.ovpn:
proto udp6
server-ipv6 fd00:ovpn:bsp:net::/64
#tun-ipv6 #ab v2.4 nicht mehr notwendig
push tun-ipv6
ifconfig-ipv6 fd00:ovpn:bsp:net::1 fd00:ovpn:bsp:net::2
push "route-ipv6 fd00:rout:bsp:fra:: ::2/64"
route-ipv6 fd00:rout:bsp:hkf:: ::2/64

Ergänzungen in der Client.conf:
Proto udp6
route-ipv6 fd00:rout:bsp:fra:: ::2/64

Ergänzungen in der CCD für normalen Client:
ifconfig-push 10.8.0.30 255.255.255.0
ifconfig-push fd00:ovpn:bsp:net::30/64

Ergänzungen in der CCD für Site2Site-Client:
ifconfig-push 10.8.0.20 255.255.255.0
iroute 192.168.188.0 255.255.255.0
ifconfig-push fd00:ovpn:bsp:net::20/64
iroute fd00:rout:bsp:hkf::20/64

Zusätzliche statische Routen im Heim-Netz-Router:
IPv6 Netzwerk = fd00:rout:bsp:hkf
Präfixlänge = 64
Gateway = fd00:ovpn:bsp:net::1

Zusätzliche statische Routen im Client-Netz-Router für Site2Site:
IPv6 Netzwerk = fd00:rout:bsp:fra
Präfixlänge = 64
Gateway = fd00:ovpn:bsp:net::1

Zusätzliche statische Route auf beiden Routern für OpenVPN-Netz:
IPv6 Netzwerk = fd00:ovpn:bsp:net
Präfixlänge = 64
Gateway = fd00:ovpn:bsp:net::1

Fehlte noch was?

natürlich

Ich habe von Problemen gelesen, wenn der Raspberry seine IPv6 nicht aus der Mac Adresse ermittelt. Hilft es daher die IPv6 aus der Mac Adresse abzuleiten und die dhcpcd.conf anzupassen:
nano /etc/dhcpcd.conf

slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
#slaac private 
net.ipv6.conf.all.forwarding=1 

Trägt man im DynDNS Service die "scope global dynamic mngtmpaddr noprefixroute" aus "ip -6 addr" des Raspberry ein? Beispiel: 2a02:1234:1234:1234::1001/64

Wieso schreibt man das so:
ifconfig-ipv6 fd00:ovpn:bsp:net::1 fd00:ovpn:bsp:net::2 --> Warum spricht man neben dem Server eine weitere Netzwerkschnittstelle an bzw. was liegt auf der :2? Hab an anderer Stelle nichts rausfinden können.
push "route-ipv6 fd00:rout:bsp:fra:: ::2/64" --> bei https://community.openvpn.net/openvpn/wiki/IPv6 heißt es im Beispiel push "route-ipv6 2001:db8:0:abc::/64" - also ohne ::2. Gleiche Frage wie oben.

Meine Fritz!Box spannt im Heimnetz ein fd00 Netz auf, was ähnlich sind zu den 192er IPv4 Adressen ist.

Steht das nicht im Widerspruch zu deiner nächsten Antwort?

Wie "bestimme" ich es und müsste bei server-ipv6 stehen?

Siehe RFC3849

Mein Fehler war, dass ich dabei von einem globalen IPv6 ausging...Danke, für die Erwähnung!

die mit "push redirect…" und "push DHCP…" beginnen.

Das ist das Entfernen des Gateway Redirects und Umschalten auf Split Tunneling. Siehe hier.

...was ich oben geschrieben habe. Fragen sind:
wieso # push "redirect-gateway def1 bypass-dhcp" --> IPv6 bekommt die Info vom Router. Ich habe jedoch auch gefunden, dass man es stehen lassen kann und in https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4 ... gibt es das sogar explizit für IPv6. Also würde ich den Befehl bei IPv4 belassen und IPv6 ergänzen mit push "redirect-gateway ipv6 def1 bypass-dhcp". Darf alternativ in der Client.conf "redirect gateway" stehen bleiben, damit auch der IPv4 Verkehr über den Server läuft? Wie stellt man es bei IPv6 vollständig sicher?

wieso #push "dhcp-option DNS 10.8.0.1" --> Das Paket bekommt bei IPv6 vom Router bereits mitgeteilt, wer der DNS ist, aber doch nicht bei IPv4. Warum muss die Zeile also verschwinden? Für IPv4 würde ich sie drin lassen.

Ein paar Anmerkungen:
Client spezifische Push Kommandos in der CCD sind NICHT erforderlich! Es sei denn du willst den Clients unbedingt feste IPs vergeben was i.d.R. nicht erforderlich ist. Die reinen Clients lernen das über die normalen Push Kommandos der Server Konfig. Die CCD spezifischen sind nur relevant bei einer Site-to-Site Vernetzung. Siehe auch hier und bei Site-to-Site hier.
Der rest ist soweit OK.

wenn der Raspberry seine IPv6 nicht aus der Mac Adresse ermittelt. Hilft es daher die IPv6 aus der Mac Adresse abzuleiten und die dhcpcd.conf anzupassen:

Das ist gehupft wie gesprungen ob EUI-64 oder nicht, relevant ist das der RasPi einen feste IP hat, da er ein Router ist. Die Mac Adresse wird ja so oder so immer per NDP ermittelt. Ob die dynamisch ist (Privacy Extension) oder SLAAC sollte egal sein. Da der RasPi aber auch ein Router ist macht es ggf. Sinn die Adresse auf EUI-64 zu belassen, da sie dann immer fest ist.

Trägt man im DynDNS Service

An einem DynDNS Service trägt man nie eine Adresse ein sondern immer einen Hostnamen. Die Adresse lernt, wie der Name es schon sagt, der Service immer automatisch. nslookup oder dig (dnsutils) sind hier, wie immer deine besten Freunde!

Wieso schreibt man das so:

Hier hilft immer die OpenVPN Kommando Reference!! Dort ist das unter "--ifconfig-ipv6 args" explizit erklärt.
Du musst bei IPv6 immer das Source Interface mitgeben. die ::1 ist das Server Interface.

und IPv6 ergänzen mit push "redirect-gateway ipv6 def1 bypass-dhcp".

Steht dann aber im Widerspruch zu deiner Split Tunneling Konfiguration mit dem dedizierten Routing! So ein Mixmax ist kontraproduktiv, da nicht supportet. Wie das Tutorial schon sagt: ...entweder, oder!

wieso #push "dhcp-option DNS 10.8.0.1"

Das erzwingt bei IPv4 einen neuen primären DNS Server. Kannst du mit ipconfig -all (Winblows) dann auch sehen bei aktivem Tunnel. Das erzwingt dann das alle DNS Requests immer über den Tunnel gehen. Meist keine gute Idee und sollte man besser weglassen dann wird immer der lokale DNS gefragt. Einzige Ausnahme: Man betreibt einen internen DNS Server und muss auch lokale IP Adressen auflösen, was in Heimnetzen meist nie der Fall ist es sei denn man betreibt einen Adguard oder PiHole DNS Filter um frei von Werbe- und Malware zu sein.

Sehr gut

Das freut mich!

Client spezifische Push Kommandos in der CCD sind NICHT erforderlich! Es sei denn du willst den Clients unbedingt feste IPs vergeben was i.d.R. nicht erforderlich ist. Die reinen Clients lernen das über die normalen Push Kommandos der Server Konfig. Die CCD spezifischen sind nur relevant bei einer Site-to-Site Vernetzung. Siehe auch hier und bei Site-to-Site hier.

Das möchte ich gerne so haben. Da die Client-Liste überschaubar ist, manage ich das gerne über die CCD und bei Site2Site hilft es mir ebenfalls.

Trägt man im DynDNS Service

Da verstehen wir uns falsch: Der DynDNS Service will die Aktuelle öffentliche IPv6 Adresse wissen.

und IPv6 ergänzen mit push "redirect-gateway ipv6 def1 bypass-dhcp".

Wo findest du die Info mit Split Tunneling? Eigentlich will ich das nicht und bisher funktioniert es mit IPv4 auch gut. Wenn ich mit dem Client Split Tunneling möchte, nutze ich eine client.conf, die den redirect-gateway Befehl der server.ovpn außer Kraft setzt.

wieso #push "dhcp-option DNS 10.8.0.1"

Die Ausnahme trifft bei mir zu und ist ein Grund, warum ich gerne den lokalen DNS nutzen will. Pihole soll schließlich auch was zu tun haben. Werde also so drin lassen und für IPv6 sollte es ohne gehen?!

Besten Dank und ein schönes Wochenende!