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:
Ich glaube es liegt an der zeile
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
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.
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
icmp-block-inversion: yes
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:
Please also mark the comments that contributed to the solution of the article
Content-ID: 7706743852
Url: https://administrator.de/contentid/7706743852
Printed on: October 4, 2024 at 01:10 o'clock
13 Comments
Latest comment
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
Zeppel
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.
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
}
}
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
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
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
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...
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.
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.
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