Router <> Wireguard <> Client

    Für das Routing zum WG-Interface wäre es egal. Du würdest aber den Peers die Erlaubnis geben, sich per IP-Adresse für einen anderen Peer auszugeben. Außerdem würde die Verbindung nur für einen Peer funktionieren, weil dieser Parameter auch für das WG-interne Routing verwendet wird. Die AllowedIPs der Peers eines WG-Interfaces dürfen nicht überlappend sein. Über mehrere WG-Interfaces ginge das. Du müsstest das Routing auf die Interfaces dann selbst machen, z.B. per Source Routing, Routing Marks, oder ähnlichem.

    Einmal editiert, zuletzt von NaN (18. September 2025 um 21:46)

    hat da keiner die man-page gelesen, da steht es ja eindeutig drinnen. ;)

    Zitat

    AllowedIPs — a comma-separated list of IP (v4 or v6) addresses with CIDR masks

    • from which incoming traffic for this peer is allowed and
    • to which outgoing traffic for this peer is directed.

    The catch-all 0.0.0.0/0 may be specified for matching all IPv4 addresses, and ::/0 may be specified for matching all IPv6 addresses. May be specified multiple times.

    bzw ist es in https://techoverflow.net/2021/07/09/wha…ps-actually-do/ auch schön erklärt.

    sprich, man gibt immer an, was an der gegenüberliegenden seite ist bzw was man von dort aus erreichen will (hier zb am iPhone die 192.168.1.0/24, die selbst nicht am wg-server anliegt, sondern an der wiederrum als client am wg-server verbundenen Fritz!-box).

    also outgoing ist es routing und incoming verifikation der source IP.

    und weil es eben incoming nur eine verifikation der source IP ist braucht es dann noch unbedingt ein paar firewall regeln für die destination IPs bzw ports. andererseits hat man vielleicht eh schon zero-trust und jeder host hat seine eigene lokale firewall.

    Naja, es ist da auch nur halbrichtig erklärt. Dass die Pakete zum Wireguard Interface geroutet werden, ist der unwichtige Teil, der wie ich jetzt schon mehrfach geschrieben habe auch nicht zwingend von Wireguard konfiguriert werden muss. Es gibt den "table" parameter, mit dem man das beeinflussen oder ganz abschalten kann. Wenn man andere Vorstellungen hat, welcher Traffic genau durch das VPN geroutet werden soll (z.B. nur bestimmte Services), dann kann und muss man das selbst machen. Der Einfachheit halber erledigt wg-quick das für den Standardfall automatisch, aber das ist nur eine Komfortfunktion.

    Erst die interne Entscheidung, in welchen Tunnel ein Paket "innerhalb" des Wireguardinterfaces geroutet wird, kann man nicht selbst machen. Nur dieser Teil der Routingentscheidung hängt wirklich von den AllowedIPs ab, aber das ist die sekundäre Funktion, sonst könnte dieser Parameter naheliegender etwa "RouteIPs" heißen. Tut er aber nicht.

    Die primäre Funktion ist das Filtern der ankommenden Pakete nach der Source-IP. Das ist eminent wichtig für die Sicherheit in Wireguard-VPNs. Sobald die Pakete aus dem Wireguard-Interface ins System kommen, kann man ihnen nicht mehr ansehen, von welchem Peer sie kamen. Eine Firewall könnte nichts mehr ausrichten. Sie könnte kein Spoofing verhindern. Deshalb wären auch keine Zugangsberechtigungen für einzelne Peers wirkungsvoll durchsetzbar. Nur weil der AllowedIPs Parameter dafür sorgt, dass ankommende Pakete in Wireguard gefiltert werden, kann sich eine Firewall oder ein Server darauf verlassen, dass die Peers anhand ihrer Source-IPs verifiziert unterscheidbar sind. Deswegen ist es falsch zu schreiben, dass man nicht angibt, "welche Daten von einem Partner empfangen werden dürfen". Von welchen Adressen Pakete kommen dürfen, ist in Wireguard tatsächlich zwingend anzugeben, und es ist das einzige, was überprüft wird.

    ja. auf einer komplexen ebene wollen wir unterscheiden, daß wg-quick mit dem wg parameter AllowedIPs und dem eigenen parameter Table das routing im host entsprechend konfiguriert. wg selbst entscheidet auf basis der AllowedIPs aus welchem tunnel packerle mit eben dieser source IP kommen dürfen bzw der destination IP in welchen tunnel es die packerle stopft. da gibt es keinen widerspruch.

    auf einer abstrakten ebene darf man aber der einfachheit geschuldet schon zusammenfassen, daß der AllowedIPs parameter dem entspricht "was an der gegenüberliegenden seite ist bzw was man von dort aus erreichen will".

    Also meine tunnels kommen immer von einer Adresse und da darf auch nur Fiete durch und sonst niemand. Und Firewall hab ich abgeschafft weil ich mich mit der immer selbst aussperre in meiner Eigenschaft als Fiete sozusagen. Ich werd jetzt aber dann doch mal die manpage lesen bevor ich den nächsten Tunnel grabe.

    The universe tends toward maximum irony. Don't push it.

    Einmal editiert, zuletzt von webdesignheld (19. September 2025 um 15:27)

    Anscheinend wurde ja die Lösung gefunden.

    Für das Ursprungsproblem möchte ich jedoch auch gerne nochmal einige Tools in den Ring werfen, die diverse Vorzüge oder Einsatzgebiete haben:

    RS 2000 G12 Pro BW25 (8C EPYC 9645, 16GB, 1TB) | RS 500 G12 BW25 (2C EPYC 9645, 4GB, 128GB) | RS Cyber Quack (1C,2GB,40GB)

    Zitat von NaN

    Naja, es ist da auch nur halbrichtig erklärt.

    Natürlich. Wenn es dir nicht in den Kram passt, dann sind sogar die offiziellen Man Pages "nur halb richtig". Übrigens ist es nicht nur die Man Page, auch die Wireguard Web-Seiten erklären das Routing im VPN anhand der Allowed IPs Einträge. Und mach dir mal den Spaß und frage eine KI nach der Funktion, was die dir erzählt.

    Zitat von NaN

    Wenn man andere Vorstellungen hat, welcher Traffic genau durch das VPN geroutet werden soll (z.B. nur bestimmte Services), dann kann und muss man das selbst machen.

    Darum geht es überhaupt nicht. Es geht darum, wohin wg die Pakete routet, die bereits im VPN sind. Welche Pakete da reinkommen, entscheidest du an anderer Stelle, das hab ich auch immer so geschrieben. Und da kann es wohl wenig Zweifel geben, dass sowohl die Man Page als auch meine Ausführungen recht haben: Die AllowedIPs entscheiden darüber, wie die Pakete innerhalb des VPNs geroutet werden. DAS ist relevant für die Nutzer, die sich ihr VPN Netz aufbauen und dabei einen zentralen Knoten für Roadwarror und LAN-LAN Netze nutzen.

    Auch wenn du die Überprüfung der eingehenden Source Adressen als "Hauptfunktion" bezeichnest, so ist es in der Praxis doch das Routing, dass mit dieser Option konfiguriert wird. Darüber werden die Datenströme im VPN gelenkt. Das ist der Punkt, über den sich die Anwender Gedanken machen und ihr Netz-Setup planen. Von daher. Turne auf deiner "Hauptfunktion" so lange herum, wie du willst, in der Praxis spielt die andere Funktion die Hauptrolle.

    Solange meine Lösungen für Otto-Normal-User funktionieren, der offiziellen Dokumentation entsprechen und nur von Besserwissern so bemängelt werden, ist das für mich ok. Bleib du mal weiter in deiner Bubble mit überprüften Absender-Adressen, und lass andere funktionierende Wireguard-Setups machen. Dann ist allen geholfen.

    Zitat von NaN

    Ich hoffe für dich, dass du irgendwann kapierst, wie sehr dich deine Unfähigkeit, sachliche Korrekturen zu akzeptieren, in deiner Kommunikation einschränkt.

    Sachliche Kommentare und Korrekturen sind ok. Aber das war pure Besserwisserei über ein Randtheme mit keinerlei praktischer Relevanz für das Thema, noch dazu so dargestellt, als sei meine Darstellung falsch - was nachweislich gemäß der offiziellen Doku nicht so ist.

    Also übe sachliche Kritik, dann bekommst du auch sachliche Antworten. Ansonsten halt auf dem Niveau, das passt.