01.07.2023

2763

Firewall blockiert VPN

Hallo an alle,

ich habe ein kleines Problem mit meiner Firewall (firewalld mit nftables) unter Linux. Ich möchte allen Traffic von einem VPN durch das interface tun0 kommt, nach virbr2 (eine Bridge) weiterleiten, die sich im Subnet 10.8.0.0/24 befinden. Aktuell habe ich die Vermutung, dass virbr2 die Verbindung blockiert. Hinter virb2 geht es weiter mit 192.168.192.0/24. Das ganze sieht ungefähr so aus:

|tun0|-------[Firewall]-------|virbr2|

Ich glaube es liegt an der zeile

rule priority="32767" reject

aber ich bin mir nicht ganz sicher, denn ich bin relativ neu im Bereich Netzwerktechnik. Ich habe bereits versucht tun0 der zone libvirt hinzu zufügen, das hat jedoch zu keinem Erfolg geführt. Ebenfalls hat

icmp-block-inversion: yes

auch keine Ergebnisse gezeigt. Wenn ich die Firewall komplett deaktiviere geht alles einwandfrei. Jetzt stellt sich mir nur noch die frage, was ich entsprechend ändern muss?

Mein aktuelles Verständnis der Firewall ist im Prinzip einfach zu erklären: "Wenn ich in einer Zone ACCEPT bin, werden die Pakete durchgelassen. Ansonsten nicht. Icmp wird geblockt, außer wenn das blocken es invertiert wird."
Ist dieses Verständnis richtig oder muss ein Paket "durch alle Zonen durch"?

Die Konfiguration der Firewall habe ich unten beigefügt. Sollten noch weitere Informationen benötigt werden, teilt es mir, gerne auch mit Begründung, mit.

Ich bin sehr dankbar für jeden konstruktiven Beitrag.

trusted (active)
  target: ACCEPT
  icmp-block-inversion: no
  interfaces:
  sources: 10.8.0.0/24 fddd:1194:1194:1194::/64
  services:
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

libvirt (active)
  target: ACCEPT
  icmp-block-inversion: no
  interfaces: virbr0 virbr1 virbr2
  sources:
  services: cord dhcp dhcpv6 dns http-https http-proxy ssh tftp
  ports: 9090/tcp 443/tcp
  protocols: icmp ipv6-icmp
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
        rule priority="32767" reject  

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eno1
  sources:
  services: XXX YYY ZZZ
  ports: xx/tcp yy/tcp zzz/tcp 80/tpc 443/tcp
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

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

Content-ID: 7706743852

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

Ausgedruckt am: 24.11.2024 um 04:11 Uhr

13 Kommentare

Neuester Kommentar

Moin.
Am besten du erstellst dir gleich eine Policy für das Inter-Zone-Forwarding zwischen den beiden Zonen, anstatt an den Zonen rum zu basteln

firewall-cmd --permanent --new-policy=trusted2libvirt
firewall-cmd --permanent --policy=trusted2libvirt --set-target=ACCEPT
firewall-cmd --reload
firewall-cmd --policy=trusted2libvirt --add-ingress-zone=trusted --permanent
firewall-cmd --policy=trusted2libvirt --add-egress-zone=libvirt --permanent
firewall-cmd --reload

Zeppel

Beispiele für so ein Setup findest du auch im Linux VPN Server Tutorial:
Bzw. HIER für das genaue Firewall Setup mit nftables.

Es geht auch noch etwas striker vom Regelwerk. Beispiel Multiprotokoll VPN Server mit IKEv2 für onboard Clients und Wireguard Support.

#!/usr/sbin/nft -f

flush ruleset

define pub_iface = "eth0"  
define wg_port = 57820

table inet drop-bad-ct-states {
	chain prerouting {
		type filter hook prerouting priority -150; policy accept;
		# drop packets in "invalid" connection-tracking state 
		ct state invalid drop
		# drop tcp packets for new connections that aren't syn packets 
		tcp flags & (fin|syn|rst|ack) != syn ct state new counter drop
		# drop XMAS packets.
		tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg counter drop
		# drop NULL packets.
		tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 counter drop
		# drop new connections over rate limit
		ct state new limit rate over 1/second burst 10 packets drop
		}
}

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 "wg0" 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;
	}
}

table ip nat {

        define VPN_NETS = {
        192.168.188.0/24, 192.168.11.0/24
        }
        chain postrouting {
                type nat hook postrouting priority 100; policy accept;
		oifname $pub_iface ip daddr $VPN_NETS accept
                ip saddr 172.25.25.0/28 oifname $pub_iface masquerade
        }
} 

Zitat von @7426148943:

Moin.
Am besten du erstellst dir gleich eine Policy für das Inter-Zone-Forwarding zwischen den beiden Zonen, anstatt an den Zonen rum zu basteln

firewall-cmd --permanent --new-policy=trusted2libvirt
firewall-cmd --permanent --policy=trusted2libvirt --set-target=ACCEPT
firewall-cmd --reload
firewall-cmd --policy=trusted2libvirt --add-ingress-zone=trusted --permanent
firewall-cmd --policy=trusted2libvirt --add-egress-zone=libvirt --permanent
firewall-cmd --reload

Zeppel

Vielen dank für deine Hilfe. Ich habe auf jeden fall neues Über die Firewall gelernt.

Allerdings wenn ich von einem PC im VPN mit der IP 10.8.0.2. Den Befehl

ping 192.168.192.215

eingebe erhalte ich als Antwort:

Antwort von 10.8.0.1: Zielport nicht erreichbar.

Auf der Host Maschine scheint es mit dem Selben Befehl korrekt zu funktionieren:

64 bytes from 192.168.192.215: icmp_seq=1 ttl=64 time=0.890 ms

Auch das irritiert mich etwas, da icmp doch normalerweise ohne Ports funktioniert?

Ich habe die beiden Policies gesetzt aber das Problem wurde dadurch nicht gelöst.

libvirt2trusted (active)
  priority: -1
  target: ACCEPT
  ingress-zones: libvirt
  egress-zones: trusted
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

trusted2libvirt (active)
  priority: -1
  target: ACCEPT
  ingress-zones: trusted
  egress-zones: libvirt
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Auch das irritiert mich etwas, da icmp doch normalerweise ohne Ports funktioniert?

Klar aber das Forwarding muss schon aktiv sein damit der Host Anfragen weiterreicht.
Wenn die IP am Host selbst terminiert ist dann noch

firewall-cmd --zone=trusted --add-forward

Und natürlich muss am VPN Client eine Route zu diesem Netz existieren.

Auch das irritiert mich etwas, da icmp doch normalerweise ohne Ports funktioniert?

Klar aber das Forwarding muss schon aktiv sein damit der Host Anfragen weiterreicht.
Wenn die IP am Host selbst terminiert ist dann noch die Ports der Policy hinzufügen.

Und natürlich muss am VPN Client eine Route zu diesem Netz existieren.

Und zur Info, die Regeln.der Firewall gelten immer INGRESS am Interface bzw. SRC

Schau dir einfach das Ergebnis auf der Shell an mit

nft list ruleset

firewalld ist ja auch nur ein weiteres Frontend für plain nftables. Ich bevorzuge die direkte Nutzung dieser dann hat man es selbst in der Hand und versteht auch was Sache ist.

Klar aber das Forwarding muss schon aktiv sein damit der Host Anfragen weiterreicht.

Das Forwarding ist bei trusted wie bei libvirt aktiviert.

Und natürlich muss am VPN Client eine Route zu diesem Netz existieren.

Das möchte ich eigentlich vermeiden. Dann müsste man bei jedem neuen Client das Routing neu einstellen. Wobei ich hier wieder auf die Firewall verweisen möchte, da beim deaktivieren ja alles zu funktionieren scheint.

Schau dir einfach das Ergebnis auf der Shell an mit

Okay. Habe ich getan. Dabei ist eine Ausgabe mit ca. 1200 Zeilen entstanden, die mich jetzt doch etwas überrumpelt hat.

Ich habe mal versucht die wichtigsten stellen heraus zu suchen. Allerdings bin ich noch recht neu auf diesem Gebiet. Ich habe zwar ein Grundlegendes Verständnis von IP-Adressen, Subnetzmasken und Netztwerkkommunikation. Wird es aber etwas komplizierter z.B. durch NAT oder MASQUERADE bin ich eher unerfahren aber bereit schnell zu lernen. Deshalb arbeite ich auch lieber mit dem Frontend.

	chain nat_POSTROUTING_POLICIES_pre {
		ip saddr 10.8.0.0/24 oifname { "virbr0", "virbr2" } jump nat_POST_policy_trusted2libvirt  
	}

	chain nat_POSTROUTING_ZONES {
		ip daddr 10.8.0.0/24 goto nat_POST_trusted
		oifname "virbr1" goto nat_POST_public  
		oifname "eno1" goto nat_POST_public  
		oifname "virbr0" goto nat_POST_libvirt  
		oifname "virbr2" goto nat_POST_libvirt  
		goto nat_POST_public
	}

table ip nat {
	chain POSTROUTING {
		type nat hook postrouting priority srcnat; policy accept;
		counter packets 98 bytes 30628 jump LIBVIRT_PRT
		ip saddr 10.8.0.0/24 ip daddr != 10.8.0.0/24 counter packets 92 bytes 30180 snat to MY.HOST.IP.ADDR
	}

	chain LIBVIRT_PRT {
		ip saddr 192.168.192.0/24 ip daddr 224.0.0.0/24 counter packets 0 bytes 0 return
		ip saddr 192.168.192.0/24 ip daddr 255.255.255.255 counter packets 0 bytes 0 return
		meta l4proto tcp ip saddr 192.168.192.0/24 ip daddr != 192.168.192.0/24 counter packets 0 bytes 0 masquerade to :1024-65535 
		meta l4proto udp ip saddr 192.168.192.0/24 ip daddr != 192.168.192.0/24 counter packets 0 bytes 0 masquerade to :1024-65535 
		ip saddr 192.168.192.0/24 ip daddr != 192.168.192.0/24 counter packets 0 bytes 0 masquerade 
		ip saddr 192.168.128.0/24 ip daddr 224.0.0.0/24 counter packets 0 bytes 0 return
		ip saddr 192.168.128.0/24 ip daddr 255.255.255.255 counter packets 0 bytes 0 return
		meta l4proto tcp ip saddr 192.168.128.0/24 ip daddr != 192.168.128.0/24 counter packets 0 bytes 0 masquerade to :1024-65535 
		meta l4proto udp ip saddr 192.168.128.0/24 ip daddr != 192.168.128.0/24 counter packets 0 bytes 0 masquerade to :1024-65535 
		ip saddr 192.168.128.0/24 ip daddr != 192.168.128.0/24 counter packets 0 bytes 0 masquerade 
	}
}

meta l4proto tcp ip saddr 192.168.192.0/24 ip daddr != 192.168.192.0/24 counter packets 0 bytes 0 masquerade to :1024-65535

Diese Zeile sieht verdächtig aus. Sollte ich die Maskierung entfernen mit:

firewall-cmd --remove-masquerade --permanent

Oder hat das dann zur folge, dass die VMs aus 192.168.192.0/24 nicht mehr mit dem Internet kommunizieren können?

EDIT:
Der Befehel:

firewall-cmd --remove-masquerade

bzw.

firewall-cmd --zone=libvirt --remove-masquerade

bzw.

firewall-cmd --zone=trusted --remove-masquerade

liefert diese Meldungen. Daran kann es also nicht liegen.
Warning: NOT_ENABLED: masquerade not enabled in 'public'
bzw.
Warning: NOT_ENABLED: masquerade not enabled in 'libvirt'
bzw.
Warning: NOT_ENABLED: masquerade not enabled in 'trusted'

Wird es aber etwas komplizierter z.B. durch NAT oder MASQUERADE bin ich eher unerfahren aber bereit schnell zu lernen.

Eigentlich erklärt das hiesige VPN Tutorial diese Dinge ganz gut im Detail so das man mit dem Rüstzeug das schnell zum Fliegen bringen sollte. Routing ist nicht erforderlich wenn man mit einem secondary IP Netz auf dem Loopback lo arbeitet bei einem standalone VPN Server.
Linux IKEv2 VPN Server

Eigentlich erklärt das hiesige VPN Tutorial diese Dinge ganz gut im Detail so das man mit dem Rüstzeug das schnell zum Fliegen bringen sollte.

Vielen Dank für deinen Input. Ich habe mir das Tutorial durchgelesen.
Allerdings wird als Client hier windows mit IpSec eingerichtet. Ich nutze aufgrund der Einfachheit für meine Nutzer OpenVPN. Auch gestaltet sich die Nutzerverwaltung dadurch sehr einfach. Das verbleibende Problem dabei ist allerdings nur noch die Firewall.
Zudem kommt noch der Fakt, dass ich nicht bei allen Clients den Router konfigurieren kann. Eine Serverseitige lösung scheint mit deshalb angemessen.

Tatsächlich bin ich mir eigentlich ziemlich sicher, die richtigen Konfigurationen getroffen zu haben. Zumindest wenn meine Vorstellung von Netzwerktechnik korrekt ist. Ich habe das mal grob skizziert und beigefügt.

Allerdings aufgrund der Tatsache, dass die Aktuellen Konfigurationen nicht das gewünschte Ergebnis erzielen, bedeutet das, dass es Irgend etwas gibt, dass ich nicht korrekt verstehe bzw. Falsch mache. Deshalb frage ich hier gerade nach, was ich noch berücksichtigen bzw. ändern muss um die Funktion zu erfüllen.

OpenVPN? Wie gruselig.... Ein Bild sagt mehr als 1000 Worte:

Und "Einfachheit" kannst du nicht ernst meinen mit der Frickelei mit den Client Zertifikaten und dem überflüssigen Overhead mit der Installation von externer VPN Software auf den Clients. Kein VPN Client ist bekanntlich so gut in ein OS integriert wie der bordeigene und IKEv2 bringen ja nun mal durchgehend alle Betriebssysteme, Smartphones usw. von sich aus mit. Da ist die VPN Installation ein Kinderspiel und kann auch von Laien einfach nur durch Eintippen gemacht werden und gut iss.
Solltest du vielleicht mal drüber nachdenken...

Aber auch wenn es denn unbedingt ein überflüssiges, zusätzliches VPN Protokoll sein muss, warum dann nicht das deutlich einfacher zu handhabende und deutlich perfomantere Wireguard?
Alles vielleicht einmal eine Überlegung wert um eine neue Perspektive zu bekommen?! Aber egal...

ziemlich sicher, die richtigen Konfigurationen getroffen zu haben.

Das sieht auch soweit ganz gut aus. Um das allerdings sicher und zielführend beurteilen zu können müsste man deine OpenVPN Server Konfig genauer kennen um das nicht in ein sonntägliches Ratespiel ausufern zu lassen.
Vielleicht hilft dir das hiesige OpenVPN Tutorial das eine korrekte OpenVPN Serverkonfig beschreibt.
(Das Wireguard Pendant findest du übrigens hier)

Die nftables Einstellungen von oben gelten dann entsprechend ebenso wenn du die dortigen WG Ports gegen deine OpenVPN UDP Ports ersetzt. Ohne IKEv2 kann man natürlich die IPsec/IKEv2 spezifischen Zeilen auch auskommentieren.

Danke für das Tutorial. Ich werde es mir definitiv durchlesen.

Wireguard stand tatsächlich auf dem Plan. War sogar schon bereit zur Installation. Allerdings kam dann das große Aber. Bei Wireguard ist es nach meinem Verständnis so, dass nur UDP Verbindungen unterstützt werden. Unsere Anwendungen verwenden allerdings primär TCP. Warum das so ist, kann ich hier leider nicht erläutern. Allerdings ist dies der Hauptaspekt. Naturlich könnte man jetzt udp2raw verwenden. Aber auch das müsste man wieder bei jedem Client installieren, was zusätzlicher Administrativer aufwand wäre und zu Verwirrung bei Nutzern führen könnte.

Die Entscheidung für OpenVPN ist außerdem aus dem Grund gefallen, dass man die Verbindung über den OpenVPN Client ganz einfach ein und aus schalten kann. Zudem ist der OpenVPN Client unabhängig vom Betriebssystem. Hierfür haben wir eine Langsamere Verbindung in kauf genommen.

Ich bin mir über die Nachteile von OpenVPN durchaus bewusst.

Tatsächlich lief die Installation von OpenVPN größtenteils automatisiert ab, was den Prozess stark beschleunigt, mich aber ebenfalls dabei im Dunkeln gelassen, hat.

Ich denke ich habe die Lösung gefunden.

Zunächst möchte ich aber noch einmal fragen, ob man bei Wireguard, welches nur UDP verwendet trotzdem ohne großen Aufwand beim Client, TCP Verbindungen herstellen kann? Sprich ein Service der auf dem Server läuft kann eine TCP Verbindung aufbauen, dass von Wireguard "gekapselt" wird. Ich vermute nein, weil TCP ist TCP und UDP ist UDP. TCP ist für korrekte Übertragungen und UDP ist für schnelle aber ggf. unvollständige Übertragungen. Vielleicht kommt der Wireguard TCP Support noch in Zukunft.

Nun zur lösung:

Ich habe durch einen Beitrag herausgefunden, dass der Forward Mode der Schnittstelle virbr2 auf 'nat' gesetzt war. Nachdem Ich den wert zu 'routed' geändert habe, scheint jetzt alles korrekt zu funktionieren. Allerdings ist dabei ein neues Problem entstanden. Der Zugriff auf das Internet wurde Blockiert. Aus der Dokumentation geht hervor, dass libvirt zur firewalld Zone zusätzlich noch iptables manipuliert.

libvirt's own rules outlined above will *always* be iptables rules regardless of which backend is in use by firewalld

Das war denke ich auch der Hauptgrund für die fehlende Funktion. Was ich jedoch noch nicht ausprobiert habe ist das backend auf iptables anstatt nftables zu ändern. Allerdings möchte ich im Aktuellen Stadium keine Risiken eingehen.

Der folgende Befehl hat dann auch noch das Zweite Problem gelößt und das Internet sowie den Zugriff auf andere VMs frei gegeben.

sudo iptables -t nat -A POSTROUTING -s 192.168.192.0/24 -o eno1 -j MASQUERADE

eno1 ist dabei mein WAN Anschluss.

Vielen Dank für eure Unterstützung.

Zitat von @PlayerSchark:

//Zunächst möchte ich aber noch einmal fragen, ob man bei Wireguard, welches nur UDP verwendet trotzdem ohne großen Aufwand beim Client, TCP Verbindungen herstellen kann?

Natürlich, sämtliche Verbindungen werden transparent getunnelt! Du kannst sogar IPv4 und IPv6 gleichzeitig im Tunnel fahren, egal ob der Tunnel über IPv4 oder IPv6 aufgebaut wird.

Ich vermute nein, weil TCP ist TCP und UDP ist UDP. TCP ist für korrekte Übertragungen und UDP ist für schnelle aber ggf. unvollständige Übertragungen.

Du vermutest absolut falsch. Beließ dich mal zum Krypto-Routing Mechanismus.
Sämtlicher Traffic wird zur Gegenstelle in UDP Pakete verpackt und beim Peer wieder entpackt, eine TCP Verbindung bleibt also eine TCP Verbindung genauso wie UDP transparent durchgeleitet wird.
Ist ja bei OpenVPN nicht anders, dort werden auch TCP Verindungen in UDP Pakete gekapselt wenn OpenVPN über UDP läuft.

Zur Firewall
Klar wenn da deine FW NATed wo es nicht nötig ist, gibt's ne Einbahnstraße ...

Gruß zeppel