Generelle Frage zur Firewall Regel "Forward" im Zusammenhang mit Wireguard

[Avenger84]

Hallo,
ich verwende seit Ewigkeiten Wireguard, damals mit postup = iptables ... heute mit nftables.

PostUp = nft add table ip filter
PostUp = nft add table ip6 filter
PostUp = nft add chain ip filter FORWARD '{ type filter hook forward priority 0; policy accept; }' 
PostUp = nft add chain ip6 filter FORWARD '{ type filter hook forward priority 0; policy accept; }' 
PostUp = nft add rule ip filter FORWARD iifname "%i" counter accept 
PostUp = nft add rule ip filter FORWARD oifname "%i" counter accept
PostUp = nft add rule ip6 filter FORWARD iifname "%i" counter accept 
PostUp = nft add rule ip6 filter FORWARD oifname "%i" counter accept  
PostDown = nft flush ruleset

chatgpt sagt dazu:

Die beiden Regeln sorgen dafür, dass sowohl eingehender als auch ausgehender Verkehr für das WireGuard-Interface durch die Firewall zugelassen wird. Das ist notwendig, damit WireGuard ordnungsgemäß funktioniert, da es sowohl Pakete empfangen als auch senden muss. Wenn diese Regeln nicht vorhanden sind, könnte der Verkehr blockiert werden, was die VPN-Verbindung unterbrechen würde.

Ich habe es auch schon ohne diese Regeln probiert und es kam nichts durch = blockiert.

Standardmäßig ist bei Raspian Bookworm oder Linux Server minimal keine Firewall aktiviert bzw. die nftables leer.

Ein Kollege im anderen Forum schreibt immer die Postup Regeln wären totaler Mumpitz und unnötig und wir wären zu doof.

ich zitiere mal:

Das ist Unsinn, denn wie oben schon mehrfach gesagt haben Firewall Regelwerke in der VPN Konfig bekanntlich nichts zu suchen.
Es zeigt vielmehr das dein Server schon grundsätzlich eine aktive Firewall hat und die auf Whitelisting geschaltet ist. Sprich also ALLES auf jedem Interface verbietet. Das o.a. Ruleset egalisiert diese Einstellung dann in dem es mit einer recht fahrlässigen "Scheunentorregel" alles erlaubt.
Du hast es schlicht versäumt einmal mit einem nft list ruleset dir deine aktiven nftables Regeln unter /etc/nfttables.conf anzusehen diese DORT wo sie auch hingehören zentral anzupassen und diesen Firewall Unsinn im VPN Client zu löschen.
...
Mal ganz abgesehen davon das in der RaspberryOS Lite Version (die für deinen Server völlig reicht und die Performance schont) die nftables Firewall per Default gar nicht aktiv ist, was dir ein systemctl status nftables auch anzeigen sollte.
Bei einem internen Server im lokalen LAN benötigst du in der Regel auch gar keine Firewall und kannst diese mit systemctl disable nftables abschalten. So benötigst du die unsinnige Regelfrickelei im VPN Client auch nicht. Wie gesagt: Eine deaktivierte Firewall ist in der OS-Lite Version so oder so per Default der Fall!
Aus all dem folgt das du irgendwie an deinen nftables Firewall Einstellungen rumgefrickelt hast wenn du diese Konfig Zeilen wirklich benötigst!
Testweise hättest du die FW auch mit einem systemctl stop nftables einmal außer Betrieb nehmen können, auch dann hättest du gesehen das die obigen Regeln im VPN Client überflüssig sind.

Einer von beiden hat Unrecht, vielleicht könnte mir das hier jemand erklären ob, wann und warum die

PostUp = nft add rule ip filter FORWARD iifname "%i" counter accept
PostUp = nft add rule ip filter FORWARD oifname "%i" counter accept

Regeln nötig sind.

In jedem Tutorial zu Wiregard sind diese Forward Regeln ebenfalls beschrieben - alle Autoren dumm?

Achtung es geht nicht um POSTROUTING masquerade, nur um FORWARD wg0 accept in/out.
Nötig oder nicht. Und wenn nötig warum?
net.ipv4.ip_forward=1 ist natürlich auch aktiviert

 

[Simanova]

Die Aussage von ChatGPT ist leider Quatsch, ich muss mich der Meinung deines Kollegen anschließen.

Entweder, du schaltest deine Linux Firewall an, nutzt Sie im Whitelist Modus und gibst jeden einzelnen Port oder Anwendung frei, was ein immenser Aufwand ist und du praktisch 24/7 nur deinen Problemen hinterhet rennst.

Oder du schaltest die Linux Firewall ab, weil sie im lokalen Netzwerk sinnfrei ist. Wenn du Angst um deinen Server hast, dann halte die Pakete aktuell, verwende einen SSH Zugang über einen 2. Faktor und biege den Port um. Und nutze generell nur Software denen du auf seinem Server vertraust - dazu gehören nur offzielle Paketquellen (apt/sources prüfen). Dazu Fail2ban und ein Angreifer kann eigentlich nicht viel machen.

Was das VPN betrifft, so kannst du es auch selber nutzen, um deinen Serverzugriff abzusichern. Hierfür einfach alle Systemdienste so umbiegen, dass sie nur noch auf den VPN Adapter hören.

Weitere Ressourcen dazu
https://adminforge.de/linux-allgemein/vpn/wireguard-vpn-server-mit-web-interface-einrichten/

 

[andy_m4]

chatgpt sagt dazu

Bitte hört auf ChatGPT für Fakten heranzuziehen.
Das ist völlig sinnfrei. Sprachmodelle sind nicht geeignet dafür, Fakten wiederzugeben, auch wenn sie hin und wieder den Eindruck vermitteln.
Im Grunde hat das aber nicht mehr Glaubwürdigkeit als irgendwelches Stammtischgerede.

 

[Uridium]

Und solange Du nicht genauer erklärst, was Du erreichen willst, kann dir auch keiner ernsthaft helfen.
Soll das ein Router oder Desktoprechner sein? Was willst Du für die andere Seite freigeben?

Bevor Du irgendwelche Regeln setzen willst, schau dir doch erst mal den aktuellen Satz an.

$ sudo nft list ruleset

Ist das Ding leer, sollte alles offen sein und bei einem Desktoprechner musst Du dann auch keine postup Regeln setzen.

Edit: Wobei... das hat weiter oben schon einer geschrieben. Der weiß wahrscheinlich mehr über deine Infrastruktur und Intention als wir.

 

[foofoobar]

Stimmt das routing?

Poste mal die Ausgaben von beiden Kisten:

ip a
ip r
wg show

Und die Ausgabe von dem was du machen willst und was nicht funktioniert inkl. Fehlermeldungen.
Und ein Bild sagt mehr als tausend Worte.