PIVPN Wireguard Configuration und weiterleiten des kompletten Internetverkehrs zum VPN

[prodo80]

Ich möchte meinen kompletten Internetverkehr vom Fire TV über meinen VPServer leiten. Hintergrund ist, dass ich über Telekom Glasfaser regelmäßig mit Prime Probleme habe bzgl. Fallback auf HD. Über Nord VPN funktioniert das ohne Probleme allerdings kostet das 40€ im Jahr extra und Geoblocking will ich auf dem Weg aktuell eh nicht umgehen. Für Testzwecke habe ich aktuell eine Ubuntu VM auf Clientseite aufgesetzt, weil das Fire TV im Standard wenig Eingriffe zulässt. Insofern habe ich nun auf beiden Seiten des Tunnels Linux.

Geplantes Setup
VM PC / Fire TV mit Wireguard im Folgenden Client genannt (gesamter Verkehr) > Fritz Box > Wireguard Tunnel > VPS mit Wireguard im Folgenden Server genannt > Internet - Die Fritz Box soll nicht den Tunnel aufbauen, sondern der Client auf dem Endgerät (das soll in der finalen Konfiguration das Fire TV Cube selbst machen, aktuell macht es aus Testgründen die VM).

Nach kurzem Googeln erschien mir PIVPN die am wenigsten aufwendige Lösung zu sein. Allerdings geht der Wizard von der UFW Firewall aus, ich habe auf dem VPS aber firewalld aktiv. Der Teil der Autokonfiguration funktioniert somit nicht komplett.

Zuerst habe ich den PIVPN Wizard auf dem VPS durchlaufen, anschließend die Konfigurationsdatei zum Client (also Fire TV / Ubuntu Test VM) geschoben und Wireguard auf dem Client aktiviert. Im Server habe ich Port 51820 geöffnet. Die Wireguard Verbindung funktioniert. Ich kann vom Client beide Enden des Tunnels und die öffentliche IP des Servers pingen.

Zwecks forwarding habe ich folgende Einstellungen auf dem Server angepasst, da der Datenverkehr vom Wireguard Tunnel ins Internet weitergeleitet werden soll:
net.ipv4.ip_forward = 0 zu net.ipv4.ip_forward = 1 und das gleiche für IPV6 mit net.ipv6.conf.all.forwarding=1.

cat /proc/sys/net/ipv4/ip_forward
1

wg show auf dem Client (Ubuntu VM)

Spoiler: wg show

wg show
wg0
  public key: <my key>
  private key: (hidden)
  listening port: 45706
  fwmark: 0xca6c

peer: <my key>
  preshared key: (hidden)
  endpoint: <public server ip>:51820
  allowed ips: 0.0.0.0/0, ::/0
  latest handshake: 4 minutes, 37 seconds ago
  transfer: 93.15 KiB received, 227.65 KiB sent

Ping auf Client zu Public server ip

ping <public server ip>
PING <public server ip> (<public server ip>) 56(84) bytes of data.
64 bytes from <public server ip>: icmp_seq=1 ttl=64 time=18.4 ms

Ping auf client für eigene wireguard ip (Aus client Sicht Anfang des Tunnels)

ping 10.143.176.2
PING 10.143.176.2 (10.143.176.2) 56(84) bytes of data.
64 bytes from 10.143.176.2: icmp_seq=1 ttl=64 time=0.031 ms

Ping auf client für server wireguard ip (aus Client Sicht Ende des Tunnels)

ping 10.143.176.1
PING 10.143.176.1 (10.143.176.1) 56(84) bytes of data.
64 bytes from 10.143.176.1: icmp_seq=1 ttl=64 time=21.9 ms

Wireguard Client config (Ubuntu VM)

Spoiler: Client Config

[Interface]
PrivateKey = <my private key>
Address = 10.143.176.2/24,fd11:5ee:bad:c0de::2/64
DNS = 9.9.9.9, 149.112.112.112

[Peer]
PublicKey = <my public key>
PresharedKey = <pre shared key>
Endpoint = <myserverip>:51820
AllowedIPs = 0.0.0.0/0, ::0/0

Wireguard Server config (VPS Server)

Spoiler: Server Config

[Interface]
PrivateKey = <myprivate key>
Address = 10.143.176.1/24,fd11:5ee:bad:c0de::1/64
MTU = 1420
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens18 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o ens18 -j MASQUERADE; iptables -A FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens18 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o ens18 -j MASQUERADE; iptables -D FORWARD -o %i -j ACCEPT
### begin firetv ###
[Peer]
PublicKey = <my public key>
PresharedKey = <my preshared key>
AllowedIPs = 10.143.176.2/32,fd11:5ee:bad:c0de::2/128
### end firetv ###

Ausgabe auf dem Server beim Stard von Wireguard:

Spoiler: Start von Wireguard auf dem Server

wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.143.176.1/24 dev wg0
[#] ip -6 address add fd11:5ee:bad:c0de::1/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens18 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o ens18 -j MASQUERADE; iptables -A FORWARD -o wg0 -j ACCEPT

Was nicht läuft ist das Umleiten des Internetverkehrs vom Client. Die meisten Guides erwähnen iptables oder UFW, letzteres ist bei mir inaktiv und in iptables sind Einträge enthalten die teilweise von firewalld kommen und teilweise Programme auch selber da rein schreiben - das war mir bisher noch nicht so bewusst und könnte ggf. Probleme verursachen. Ich habe testweise firewalld auch mal deaktiviert, das bringt bzgl. der Thematik keinen für mich sichtbaren Unterschied.

Iptables auf dem Server:

Spoiler: IPTABLES

sudo iptables -L -v -n
Chain INPUT (policy ACCEPT 161K packets, 205M bytes)
 pkts bytes target     prot opt in     out     source               destination
   20  1296 ACCEPT     all  --  *      *       10.143.176.0/24      0.0.0.0/0            /* wireguard subnet */
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            10.143.176.0/24      /* wireguard subnet */

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  677 45957 DOCKER-ISOLATION-STAGE-1  all  --  *      *       0.0.0.0/0            0.0.0.0/0
  677 45957 DOCKER-USER  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 DOCKER     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  docker0 docker0  0.0.0.0/0            0.0.0.0/0
  677 45957 ACCEPT     all  --  wg0    ens18   0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      wg0     0.0.0.0/0            0.0.0.0/0            /* wireguard subnet */
    0     0 ACCEPT     all  --  *      *       10.143.176.0/24      0.0.0.0/0            /* wireguard subnet */

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
 pkts bytes target     prot opt in     out     source               destination
  677 45957 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-2 (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain DOCKER-USER (1 references)
 pkts bytes target     prot opt in     out     source               destination
  677 45957 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Einige Regeln erscheinen mir auch nicht sinnvoll:

Spoiler: Ggf. nicht notwendige Regeln

pkts bytes target     prot opt in     out     source               destination
0     0 ACCEPT     all  --  *      *       0.0.0.0/0            10.143.176.0/24      /* wireguard subnet */
0     0 ACCEPT     all  --  *      wg0     0.0.0.0/0            0.0.0.0/0            /* wireguard subnet */

IP Tables NAT auf dem Server:

Spoiler: IP Tables NAT

sudo iptables -L -v -n -t nat
Chain PREROUTING (policy ACCEPT 5482 packets, 1423K bytes)
 pkts bytes target     prot opt in     out     source               destination
  809 43992 DOCKER     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 2410 packets, 170K bytes)
 pkts bytes target     prot opt in     out     source               destination
 1329 81808 DOCKER     all  --  *      *       0.0.0.0/0           !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT 2410 packets, 170K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  docker0 *       0.0.0.0/0            0.0.0.0/0

firewalld zones:

mysite:

Spoiler: Zone mysite Regeln in firewalld

sudo firewall-cmd --zone=mysite --add-rich-rule='rule family="ipv4" source address="10.143.176.0/24" masquerade'
sudo firewall-cmd --zone=mysite --add-source=<mypublic ip>/32 UDP Port 51820 open

mywg

Spoiler: Zone mywg

Interface WG0

Direct rules:

Spoiler: Firewalld direct rules

ipv4 filter foeward -o wg0 -j ACCEPT -m comment --comment 'wireguard subnet'
ipv4 filter forward -i wg0 -o ens18 -j ACCEPT
ipv4 filter forward -s 10.143.176.0/24 -j ACCEPT -m comment --comment 'wireguard subnet'
ipv4 filter input -s 10.143.176.0/24 -j ACCEPT -m comment --comment 'wireguard subnet'
ipv5 filter input -d 10.143.176.0/24 -j ACCEPT -m comment --comment 'wireguard subnet'

Pyvpn Konfigurationsdatei (die dürfte nach der initialen Konfiguration nicht mehr relevant sein:

Spoiler: PIVPN Konfigurationsdatei

PLAT=Ubuntu
OSCN=jammy
USING_UFW=0
IPv4dev=ens18
IPv6dev=ens18
install_user=admin
install_home=/home/admin
VPN=wireguard
pivpnPORT=51820
pivpnDNS1=9.9.9.9
pivpnDNS2=149.112.112.112
pivpnHOST=<my vpn public ip>
pivpnPROTO=udp
pivpnMTU=1420
pivpnDEV=wg0
pivpnNET=10.143.176.0
subnetClass=24
pivpnenableipv6=1
pivpnNETv6="fd11:5ee:bad:c0de::"
subnetClassv6=64
ALLOWED_IPS="0.0.0.0/0, ::0/0"
UNATTUPG=0
INSTALLED_PACKAGES=(grepcidr qrencode)
INPUT_CHAIN_EDITED=1
FORWARD_CHAIN_EDITED=1

Jemand eine Idee?

 

[Crumar]

Es wuerde ggf. helfen, wenn du ein Diagramm zeichnest.
Umso wichtiger waere aber, wenn du die Configs in Code Tags packst und in einen Spoiler pro File, dann wird das ganze deutlich verstaendlicher.

Edit:
Danke, das ist ein Anfang.
Ich habe mir die Konfigurationen noch gar nicht angesehen.
Hast du denn dem FireTV gesagt, dass der PI das Gateway ist (statt dem Router)?
Also in dem Fall deiner VM?
Was steht bei ip addr

 

[prodo80]

Ich habe die Darstellung jetzt etwas optimiert.

Beim Fire TV steht als Gateway 0.0.0.0 lt. meiner Suche scheint das aber ok zu sein, wenn Wireguard direkt auf dem FireTV läuft. Ich wüsste aktuell auch nicht wie ich dort was anderes eintragen soll, denn eintragen muss ich in der Fire TV Netzwerkkonfiguration das physische Netzinterface. Bei der Ubuntu VM habe ich folgendes ausgeführt.

ip route get 1.1.1.1
1.1.1.1 dev wg0 table 51820 src 10.143.176.2 uid 0
    cache

Das scheint also ok zu sein. Zumindest wird der Tunnel angesteuert.

 

[riversource]

Was nicht läuft ist das umleiten des Internetverkehrs vom Client.

Was genau ist für dich denn im Moment der "Client"? Die VM mit Wireguard? Und wie hast du das festgestellt?

Was fehlt, ist ein "ip r" und ein "ip -6 r" auf der VM. Im Moment kann man nicht sehen, welche Routen bevorzugt werden.

Nach kurzem Googeln erschien mir PIVPN die am wenigsten aufwendige Lösung zu sein.

Nein, das ist ein Irrtum. Diese Lösungen funktionieren überhaupt nur, solange man exakt in den beabsichtigten Anwendungsfällen bleibt. Sobald man nur eine Winzigkeit selber anpassen will, kommt man in die Hölle, siehe dein Beispiel mit ufw und firewalld. Damit hast du verloren. Mach es von Hand, geht VIEL schneller.

 

[Crumar]

Okay, dann bin ich nicht mitgekommen.

Ich wusste nicht, dass man Wireguard auf dem FireTV direkt nutzen kann. Wie dem auch sei.

Eigentlich brauchst du kein extra IP tables setup auf der dem WG Client.
AllowedIPs macht 2 Dinge:

1. Firewall, welche Pakete ueber wg0 eingehen duerfen
2. Route+Firewall, welche Pakete ueber wg0 rausgehen duerfen

 

[prodo80]

Was genau ist für dich denn im Moment der "Client"? Die VM mit Wireguard? Und wie hast du das festgestellt?

Was fehlt, ist ein "ip r" und ein "ip -6 r" auf der VM. Im Moment kann man nicht sehen, welche Routen bevorzugt werden.

Ja, die VM mit Wireguard meine ich mit Client, so wurde das zumindest auch in den Guides betitelt. Die IPV6 Adressen hatte ich zuletzt aus den Konfigurationen rausgeschmissen, um IPV6 Effekte im ersten Schritt auszuschließen.

ip r
default via 172.19.240.1 dev eth0 proto dhcp metric 100
10.143.176.0/24 dev wg0 proto kernel scope link src 10.143.176.2
169.254.0.0/16 dev eth0 scope link metric 1000
172.19.240.0/20 dev eth0 proto kernel scope link src 172.19.244.94 metric 100

ip -6 r
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 1024 pref medium

Ergänzung (3. August 2023)

Ich wusste nicht, dass man Wireguard auf dem FireTV direkt nutzen kann. Wie dem auch sei.

Eigentlich brauchst du kein extra IP tables setup auf der dem WG Client.
AllowedIPs macht 2 Dinge:

Ich habe einfach die offizielle Wireguard App auf dem Fire TV installiert und dann nur die fertige Konfiguration von PIVPS übertragen (auf der VM analog). Für die Wireguard Verbindung funktioniert das scheinbar auch.

Die Anpassungen an IPTABLES habe ich nur auf dem VPS vorgenommen bzw. die nehmen die Tools teilweise schon alleine vor, nachdem ich keine Internetverbindung auf dem Fire TV hatte.

 

[riversource]

default via 172.19.240.1 dev eth0 proto dhcp metric 100

Die Defaultroute zeigt auf eth0, nicht auf Wireguard. Damit ist klar, dass der Internetverkehr nicht über VPN umgeleitet wird. Ich vermute ein Problem mit den Allowed IPs.

172.19.240.0/20 dev eth0 proto kernel scope link src 172.19.244.94 metric 100

Warum denn ein so großes Subnetz auf eth0?

 

[prodo80]

Wenn ich über \etc\hosts auf dem Client die IP zur URL zuordne, kann ich von der VM auf dem VPS eine Webseite aufrufen. D.h. auf dem Client scheint alles gut zu sein, nur das Routing ins Netz funktioniert auf dem VPS nicht. Die Daten wandern auch über die Wireguard Verbindung, soweit man das an den Transfers sieht.

transfer: 18.87 MiB received, 7.74 MiB sent

Ergänzung (3. August 2023)

Die Defaultroute zeigt auf eth0, nicht auf Wireguard. Damit ist klar, dass der Internetverkehr nicht über VPN umgeleitet wird. Ich vermute ein Problem mit den Allowed IPs.

Warum denn ein so großes Subnetz auf eth0?

Das hatte ich vorhin testweise mal gemacht, dann geht überhaupt nichts mehr, nicht mal die Pings die aktuell auf die Gegenseite des Tunnels laufen. Wenn das default Gateway nicht mehr auf die IP des virtuellen Netzwerkadapters der VM zeigt und stattdessen auf den Tunnel, dann ist auch die Gegenseite des Tunnels nicht mehr pingbar.

Ich habe diesbezüglich auf dem Client in keinem Guide Anpassungen gefunden und so 20-30 verschiedene habe ich unterdessen durch.

Allowed sind alle IPs, also der komplette Netzverkehr der VM (0.0.0.0/0), wenn du das meinst.

Die Netzeinträge auf der VM sind out of the Box Hyper V mit Ubuntu Desktop Standardinstallation. Da wird die Netzmaske etwas ungewöhnlich ausgelegt (255.255.240.0) aber das ist denke ich irrelevant.

 

[riversource]

Wenn ich über \etc\hosts auf dem Client die IP zur URL zuordne, kann ich von der VM auf dem VPS eine Webseite aufrufen.

Jetzt wirds chaotisch. Aber der Reihe nach.

"Wenn du ... auf dem Client eine IP einer URL zuordnest": Das geht nicht. Du kannst einen Hostnamen einer IP zuweisen, aber keine URL. Und auf Linux geht es in /etc/hosts, nicht in \etc\hosts. Aber die wichtigste Frage: Warum das alles? DNS ist doch kein Problem, oder? Welchen Host hast du denn da welcher IP zugewiesen?

"... kannst du von der VM auf dem VPS eine Webseite aufrufen": Was um Himmels Willen hat eine VM auf dem VPS mit deinem Client zu tun? Der Client läuft doch hoffentlich bei dir zu Hause, und nicht auf dem VPS, der gleichzeitig VPN Server ist, oder? Sag jetzt bitte "nein" ... denn sonst fangen wir bei Null an.

Was hast du oben im "ip r" gezeigt? Den Server oder den Client? Wenn es der Client ist: Da zeigt die Defaultroute nicht auf das VPN Device. Da wird nur der Datenverkehr fürs VPN Netz ins VPN geschickt, sonst nichts.

Ergänzung (3. August 2023)

Das hatte ich vorhin testweise mal gemacht, dann geht überhaupt nichts mehr, nicht mal die Pings die aktuell auf die Gegenseite des Tunnels laufen. Wenn das default Gateway nicht mehr auf die IP des virtuellen Netzwerkadapters der VM zeigt und stattdessen auf den Tunnel, dann ist auch die Gegenseite des Tunnels nicht mehr pingbar.

Darum brauchst du dich überhaupt nicht zu kümmern. Wenn du Wireguard über die allowed IPs sagst, dass die Defaultroute aufs VPN gelegt wird, richtet es selber eine Hostroute mit kleiner Metrik für den VPN Server an und leitet den Rest übers VPN. Das ist überhaupt kein Problem. Wenn das bei dir nicht klappt, hast du ein generelles Problem mit Wireguard (PiVPN lässt grüßen, siehe oben ...).

 

[prodo80]

Jetzt wirds chaotisch. Aber der Reihe nach.

"Wenn du ... auf dem Client eine IP einer URL zuordnest": Das geht nicht. Du kannst einen Hostnamen einer IP zuweisen, aber keine URL. Und auf Linux geht es in /etc/hosts, nicht in \etc\hosts. Aber die wichtigste Frage: Warum das alles? DNS ist doch kein Problem, oder? Welchen Host hast du denn da welcher IP zugewiesen?

Ja, du hast recht, ein Hostname. keine URL und auch bei Slash und Backlash.

Warum das alles? Weil die Frage war, ob der Tunnel benutzt wird oder nicht. Deine Argumentation ging ja dahin. Mit den Zuordnungen Hostname IP konnte ich die Webseiten auf dem VPS aufrufen.

DNS ist insofern ein Problem vom Client aus, als dass von dort hinter dem Tunnel die Verbindung ins Internet nicht geht und somit ging auch keine DNS Auflösung vom Cleint, sobald Wireguard aktiv ist. Das liegt aber offenbar nur daran, dass nichts ins Internet geht und somit kann auch kein DNS funktionieren.

Ich habe jetzt mal testweise den DNS Server auf dem VPS in der Wireguard Config angegeben und schon klappt die DNS Auflösung im Client. Erkenntnis: DNS ist auf dem Client nur insofern ein Problem, dass nach wie vor die Weiterleitung auf den VPS funktioniert, von da aber nicht ins Internet (also das was ich ursprünglich schon angenommen hatte aber jetzt halt genau weiß),

"... kannst du von der VM auf dem VPS eine Webseite aufrufen": Was um Himmels Willen hat eine VM auf dem VPS mit deinem Client zu tun? Der Client läuft doch hoffentlich bei dir zu Hause, und nicht auf dem VPS, der gleichzeitig VPN Server ist, oder? Sag jetzt bitte "nein" ... denn sonst fangen wir bei Null an.

Die VM hat eine Verbindung zum VPS und ich kann von der VM die Webseite auf dem VPS aufrufen über den Tunnel und die hostnamen / URLs. Wenn die VM Webseiten auf dem VPS aufrufen kann und gleichzeitig sichtbar ist, dass im Wireguard Tunnel größere Datenmengen transferiert werden, wenn man z.B. ein Video öffnet (z.B. 50MB für ein Video), es besteht also kein Problem auf dem Client, sonst wäre das nicht möglich,

Was hast du oben im "ip r" gezeigt? Den Server oder den Client? Wenn es der Client ist: Da zeigt die Defaultroute nicht auf das VPN Device. Da wird nur der Datenverkehr fürs VPN Netz ins VPN geschickt, sonst nichts.

Ergänzung (3. August 2023)

Den Client und wie ich schrieb. Mit dem Setting aus dem Screenshot geht der Verkehr durch den Tunnel, mit dem Default Gateway auf den Tunnel geht überhaupt nichts mehr.

Darum brauchst du dich überhaupt nicht zu kümmern. Wenn du Wireguard über die allowed IPs sagst, dann die Defaultroute aufs VPN gelegt wird, richtet es selber eine Hostroute mit kleiner Metrik für den VPN Server an und leitet den Rest übrs VPN. Das ist überhaupt kein Problem. Wenn das bei dir nicht klappt, hast du ein generelles Problem mit Wireguard (PiVPN lässt grüßen, siehe oben ...).

Der Teil klappt zumindest auf dem Client offenbar. Das hattest du oben in Frage gestellt. Über die obigen Tests ist das aber erledigt.

Ansonsten legt PIVPN bzgl. Wireguard auch nur die Wireguard Configs an, siehe oben. Die sehen auch nicht anders aus, wenn man Wireguard selber aufsetzt. Zumindest habe ich den Wireguard Guides keine Unterschiede entdeckt.

Problematisch ist aktuell eher, dass das Tunnelende nicht zum Internet verbunden wird.

 

[prodo80]

Ich habe einen TCP Dump auf das Tunnelende am Server gehängt, das hat mich dann zu den Firewall Logs geführt.

Im Client habe ich zum Testen einen refresh im Browser ausgeführt ganz Simpel auf: https://www.heise.de/

Danach habe ich die Firewalld Konfiguration zurück gebaut. Sobald ich das Interface WG0 in eine eigendefinierte Zone hänge, blockt firewalld lt. Log den ausgehenden Verkehr von WG0 nach ENS18 (also vom internen Wireguard Adapter ins Internet, obwohl es dafür eine Regel gab). D.h. ich habe mich von der Firewall austricksen lassen oder selbst damit ausgetrickst. Ansonsten funktioniert es, wenn das WG0 in der Zone thrusted ist oder es funktioniert eingeschränkt, wenn die Zone für WG0 internal ist.

Das einzige was ich auf dem Server benötigt habe ist die Masquerade:
iptables -t nat -I POSTROUTING 1 -s 10.143.176.0/24 -o ens18 -j MASQUERADE

Alles andere war zu viel des Guten. War das eine Geburt.

Jetzt klappt auch Prime UHD.

 

[prodo80]

Notiz an mich selbst RTFM. Für alle, die ggf. auch in der Kombination mit Firewalld und forwarding mit Wiregard auf Probleme stoßen ist folgendes ggf. hilfreich.

Die Zonennanmen in Firewalld sind nicht nur Namen, sondern bringen im Auslieferungszustand Flags mit sich, die sich elementar auf das Verhalten der Zonen bzgl. des Datenverkehrs auswirken können. Das ist in der grafischen Pflege (firewall-config) nicht vollständig ersichtlich bzw. man sieht in der Regel die Zuordnungen von Posts, Interfaces, Diensten usw. aber nicht die Zonenflags. Bisher bin ich mit der grafische Pflege gut zurecht gekommen aber in diesem Fall reicht sie eben nicht.

Beispiele für Flags an Zonen:

public (active)

target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services:
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

external

target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services:
  ports:
  protocols:
  forward: yes
  masquerade: yes
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

internal (active)

target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services:
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

trusted (active)

target: ACCEPT
  icmp-block-inversion: no
  interfaces:
  sources:
  services:
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Accept (Standard in Zone trusted) ist quasi ein opt out, also eher die Verkehrung der klassischen Firewalldenkweise und somit nicht die beste Idee.

"The ACCEPT target is used in trusted zone to accept every packet not matching any rule."

Ansonsten:
https://firewalld.org/documentation/man-pages/firewalld.zone.html

Forward
Is an optional empty-element tag and can be used only once in a zone configuration. This flag enables intra-zone forwarding. When enabled, packets will be forwarded between interfaces or sources within a zone, even if the zone's target is not set to ACCEPT.

Ergebnis: Wenn man z.B. zwei Interfaces in einer Zone zuordnet - in meinem Fall WG0 und ENS18 ist forwarding dazwischen möglich, wenn das o.g. Zonenflag für Forwarding gesetzt ist. Das hat aber den Nachteil, dass die gleichen Einstellungen für beide Objekte (die der Zone) gelten. In meinem Fall kann ich WG0 also der Default Zone zuordnen, die allerdings auch sämtliche Portfreigaben für den Server beinhaltet. Die werden für den Fire TV nicht benötigt und sind daher nicht sinnvoll.

In der Public Zone (External wäre auch möglich bzw. für Routing vorgesehen) ist der Endpunkt des VPN aber schon deutlich besser aufgehoben als in der trusted Zone.

Die Einzige Variante für zonenübergreifendes Forwarding mit Firewalld ist - nach dem was ich in der Doku gefunden habe - neben ACCEPT als Zonenflag (opt out) die Nutzung von Policies:
https://firewalld.org/2020/09/policy-objects-introduction

Policies habe ich in der GUI überhaupt nicht gefunden und so ganz alt ist die Funktion auch noch nicht.

firewall-cmd --permanent --new-policy=wg0public
firewall-cmd --permanent --policy=wg0public --set-target=ACCEPT
firewall-cmd --reload
firewall-cmd --permanent --policy=wg0public --add-ingress-zone=wg0
firewall-cmd --permanent --policy=wg0public --add-egress-zone=public

D.h. ausgehend akzeptiert Public alles von FireTV bzw. vom VPN, eingehend nichts was von außen kommt und nicht vom FireTV angefordert wurde. Das scheint mir die optimale Variante zu sein. In meinem Fall hat das noch den Vorteil, dass direkte Zugriffe auf den Server nicht erlaubt sind, da das Target in dem Fall nicht ENS18, sondern leer ist, die obige Regel Policy greift somit nicht. D.h. vom Tunnelende ist kein Zugriff auf den VPS Server möglich, sofern man nicht jeden einzelnen Dienst explizit freigibt (man hat somit separate Regeln für den Tunneleingang bzw. in meinem Fall das Fire TV). somit wäre, sofern jemand das Fire TV von außen hacken würde, der Server noch immer sicher.

wg0public (active)

priority: -1
  target: ACCEPT
  ingress-zones: wg0
  egress-zones: public
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Eigentlich erstaunlich simpel. Wichtig zu wissen ist, dass mit den Standardeinstellungen von Firewalld out of the box weder in einer Zone (External ausgenommen), noch zonenübergreifende Kommunikation zugelassen wird. Das findet man in den meisten Guides nicht oder es wird in Guides versucht das über direkte iptables Einträge auszuhebeln.

Was man auch wissen muss: Immer, wenn man das Logging in Firewalld aktiviert, dann wird die Firewall neu geladen und die Permanent Einstellungen werden zu Runtime Einstellungen. Es bringt also überhaupt nichts mal etwas auf Runtime zum Testen einzustellen, dann das Logging zu aktivieren und zu testen, weil man damit die Runtime Einstellung überschrieben hat.