Hallo,
Ich hätte ein kleines Problem mit unserem Wireguard. Ich habe versucht aus der Wiki-Anleitung schlau zu werden und habe es auch soweit hinbekommen das an meinen Clients (Laptop Win11 und I-Phone) angezeigt wird das die Verbindung existiert und aktiv ist.
Allerdings bekomme ich keine Kommunikation zu unseren Netzwerken hin. In der Firewall selber wird die Wireguard Verbindung im Widget auch nicht angezeigt.
Es gibt folgende Portfilter Regeln:
internes Netz -> Wireguard-Netz
Wireguard-Netz -> internes Netz
Wireguard VPN User -> internes Netz
Internes Netz -> Wireguard User
Alles erlaubt (für Testzwecke)
Ich finde das alles leider viel zu umständlich und denke mal das ich hier irgendwas vergessen hab bzw falsch konfiguriert.
Hat da einer ne Idee?
Wireguard und Roadwarrior
Moderator: Securepoint
Kann ich so bestätigen. Bei mir zeigt Wireguard eine aktive Verbindung, an der Firewall jedoch ist es "Rot". Das ist ja irgendwo falsch. Selbst wenn Portfilter, etc. dann noch nicht richtig gesetzt wären, so müsste doch zumindest bei aufgebautem Tunnel auf beiden Seiten ein grünes Lämpchen sein, oder wo liegt der Fehler?
PS: keine Verbindung durch den Tunnel möglich, trotz gesetzter "ANY" Regeln im Netzwerk (zu Testzwecken!)
PS: keine Verbindung durch den Tunnel möglich, trotz gesetzter "ANY" Regeln im Netzwerk (zu Testzwecken!)
Hallo liebes Forum, es sind nun schon ein paar Monate vergangen seit dem letzten Post, wir schreiben mittlerweile UTM 14.1.4. Ganz ähnliches Problem bei mir: Ich scheitere nach vielen Stunden Tüfteln im gruseligen GUI (Recherche im Securepoint Wiki, mit Google KI, Claudi KI, ChatGPT) am Einrichten einer WireGuard E2S-Verbindung/Roadwarriorverbindung hinter einer Fritzbox 7590 mit DynDNS und Portforwarding 51820 auf Securepoint Firewall. Clients (iPhone, MBP) stellen Verbindung erfolgreich her. Bei mir steht sogar im WireGuard Widget auf der Securepoint der eingerichtete Peer, aber immer mit rotem Punkt und kein Datenverkehr möglich.
Claude:
Was du dem Support mitgeben kannst
Problembeschreibung:
Vielleicht stimmen Firewall-Regeln noch nicht? Vielleicht stimmt etwas mit den verwendeten Schlüsseln nicht?
Gibt es hier vielleicht jemand, der weiterhelfen kann?
Florian (fertig mit den Nerven)
Claude:
Was du dem Support mitgeben kannst
Problembeschreibung:
- WireGuard E2S-Peer <WireGuard-Benutzer> korrekt in Datenbank konfiguriert
- zeigt Peer mit korrektem Public Key, IP 10.0.10.2, Flag USER
Code: Alles auswählen
wireguard get Code: Alles auswählen
wireguard ping → no peer_id_list- Dienst läuft mit Flag NOSERVICE – Peer wird nicht in aktive wg0-Konfiguration geladen
- UDP-Pakete kommen auf A0 an, wg0 bleibt leer
Code: Alles auswählen
appmgmt stop application wireguard → failed to stop wireguard
Vielleicht stimmen Firewall-Regeln noch nicht? Vielleicht stimmt etwas mit den verwendeten Schlüsseln nicht?
Gibt es hier vielleicht jemand, der weiterhelfen kann?
Florian (fertig mit den Nerven)
Zuletzt geändert von FlorianS am So 24.05.2026, 16:22, insgesamt 1-mal geändert.
Bin mittlerweile mit KI-Hilfe schon weiter. Im Widget ist die VPN-Verbindung schon grün, aber Pings und Netzwerkverkehr funktionieren noch nicht.
Zusammenfassung: WireGuard wg0 → bridge0 Forward-Traffic DEFAULT DROP trotz ACCEPT-Regel
Inhalt:
Liest da jemand mit, der den entscheidenden Tipp hat?
Gute Nacht
Zusammenfassung: WireGuard wg0 → bridge0 Forward-Traffic DEFAULT DROP trotz ACCEPT-Regel
Inhalt:
- UTM: Black Dwarf Gen 5, UTM 14.1.5
- WireGuard Interface wg0 (10.0.10.1/24)
- LAN: bridge0 (LAN+WLAN gebrückt), 192.168.2.0/24
- Problem: Traffic von VPN-Client (10.0.10.2) über wg0 zu LAN-Geräten (192.168.2.x) wird trotz aktiver ACCEPT-Regel mit „DEFAULT DROP" geblockt
- Paketfilter-Log zeigt:
Code: Alles auswählen
DROP: (DEFAULT DROP) 10.0.10.2 wg0 → bridge0 192.168.2.x Echo Request - UTM selbst kann von 10.0.10.1 ins LAN pingen (funktioniert)
- Implizite WireGuard-Regel aktiv, VPN-Gruppe aktiv
Liest da jemand mit, der den entscheidenden Tipp hat?
Gute Nacht
Wenn Sie im Paketfilter einen Drop: (Default Drop) sehen, kommen die Pakete schon einmal bei der UTM an und werden entpackt.
Hier stimmt jetzt noch etwas mit der Regel nicht, bei der Meldung Default Drop wurde für das Datenpaket keine gültige Regel gefunden.
Bsp
Wg-RW Netz >> Internes Netz >> icmp-echo-req
Entweder gibt es keine solche Regel, oder mit den Netzwerkobjekten oder den Zonen stimmt etwas nicht.
Hier stimmt jetzt noch etwas mit der Regel nicht, bei der Meldung Default Drop wurde für das Datenpaket keine gültige Regel gefunden.
Bsp
Wg-RW Netz >> Internes Netz >> icmp-echo-req
Entweder gibt es keine solche Regel, oder mit den Netzwerkobjekten oder den Zonen stimmt etwas nicht.
Danke für die Anregung. Leider noch kein Erfolg.
WireGuard Road-Warrior, wg0 Forward-Traffic zu bridge0 wird mit DEFAULT DROP geblockt. Keine Paketfilter-Regel greift. tcpdump zeigt Pakete kommen an wg0 an, aber keine Antworten.
Sollten da evtl. mit Shell-Zugriff auf die UTM die internen iptables-Chains direkt analysiert werden? Wie kann ich direkten Support bekommen?
Gruß
Florian
WireGuard Road-Warrior, wg0 Forward-Traffic zu bridge0 wird mit DEFAULT DROP geblockt. Keine Paketfilter-Regel greift. tcpdump zeigt Pakete kommen an wg0 an, aber keine Antworten.
Sollten da evtl. mit Shell-Zugriff auf die UTM die internen iptables-Chains direkt analysiert werden? Wie kann ich direkten Support bekommen?
Gruß
Florian
Moin,
ich hatte auch meine Probleme mit Wireguard als RW-Verbindung und der UTM. Aber mittlerweile weiß ich, mich durchzuhangeln.
Vorweg: Ich wählte als "Peer" bisher immer nur lokale Benutzer. Darauf bezieht sich das Folgende.
Man muss bei Wireguard einige Einstellungen vornehmen, die – zumindest mir – anhand des Wikis so nicht direkt erkenntlich/schlüssig sind. Die Sichtweise des Wiki ist zu oft auf jemanden gemünzt, der sich mit den einzelnen Programmen/Diensten der UTM en detail bereits auskennt. Es wird m. E. zu wenig wert auf den durchschnittlichen ITler gelegt. Aber ich schweife ab.
Was meine Fallstricke damals waren: Ich musste (händisch) sowohl eine Netzwerkgruppe als auch eine Zone für das Wireguard-Transfernetz erzeugen und, um meinen Zwecken gerecht zu werden auch, einzelne Netzwerkobjekte für die einzelnen Roadwarrior selbst. Also eine Zone für das Netzwerk selbst sowie eine Interface-geflaggte Zone für die Wireguard-Schnittstelle/IP-Adresse im Transfernetz der UTM. Erst dann konnte ich die korrekten Firewalleinstellungen vornehmen.
In den Einstellungen des jeweiligen Roadwarriors muss man übrigens zwingend einige Punkte unter dem Punkt VPN -> Wireguard ausfüllen sowie unter dem (einzelnen Punkt) Wireguard selbst. (Hätte die Wireguard-Einstellungen nicht besser zusammenlegen sollen? Das Aufsplitten verwirrt.)
Also man muss jedenfalls dort händisch (warum?!?!) eine dedizierte IP-Adresse des Transfernetzes für die Wireguard-Verbindung eintragen. IPv4 und/oder IPv6, je nachdem, welchen IP-Standard man nutzen möchte. Dass man hier selber den Überblick über die IP-Adressen behalten muss, halte ich für verbesserungswürdig und auch -fähig, möchte aber auch darauf hinweisen, dass die manuelle Vergabe/Änderung der Adresse nicht veränderbar sein sollte! Aber der IP-Adressbereich sollte – allein schon zum besseren Verständnis für das Feld "IPvX Peer Adresse" (hier sowie an anderen Stellen würde korrektes/stringentes Deutsch und vielleicht auch intuitiveres Wording die Qualitätsanmutung unterstützen) zumindest vorgegeben werden.
Bei mir war noch ein Einrichtungsproblem, dass der private Schlüssel zwingend im Format x25519 angelegt werden muss. Auch hier sollte die UTM den Benutzer führen und nur solche Formate zur Auswahl anbieten, die im Rahmen einer Wireguard-VPN-Einrichtung auch nutzbar sind.
Nachdem diese Punkte geklärt waren, war der Rest eigentlich UTM-typisch.
ich hatte auch meine Probleme mit Wireguard als RW-Verbindung und der UTM. Aber mittlerweile weiß ich, mich durchzuhangeln.
Vorweg: Ich wählte als "Peer" bisher immer nur lokale Benutzer. Darauf bezieht sich das Folgende.
Man muss bei Wireguard einige Einstellungen vornehmen, die – zumindest mir – anhand des Wikis so nicht direkt erkenntlich/schlüssig sind. Die Sichtweise des Wiki ist zu oft auf jemanden gemünzt, der sich mit den einzelnen Programmen/Diensten der UTM en detail bereits auskennt. Es wird m. E. zu wenig wert auf den durchschnittlichen ITler gelegt. Aber ich schweife ab.
Was meine Fallstricke damals waren: Ich musste (händisch) sowohl eine Netzwerkgruppe als auch eine Zone für das Wireguard-Transfernetz erzeugen und, um meinen Zwecken gerecht zu werden auch, einzelne Netzwerkobjekte für die einzelnen Roadwarrior selbst. Also eine Zone für das Netzwerk selbst sowie eine Interface-geflaggte Zone für die Wireguard-Schnittstelle/IP-Adresse im Transfernetz der UTM. Erst dann konnte ich die korrekten Firewalleinstellungen vornehmen.
In den Einstellungen des jeweiligen Roadwarriors muss man übrigens zwingend einige Punkte unter dem Punkt VPN -> Wireguard ausfüllen sowie unter dem (einzelnen Punkt) Wireguard selbst. (Hätte die Wireguard-Einstellungen nicht besser zusammenlegen sollen? Das Aufsplitten verwirrt.)
Also man muss jedenfalls dort händisch (warum?!?!) eine dedizierte IP-Adresse des Transfernetzes für die Wireguard-Verbindung eintragen. IPv4 und/oder IPv6, je nachdem, welchen IP-Standard man nutzen möchte. Dass man hier selber den Überblick über die IP-Adressen behalten muss, halte ich für verbesserungswürdig und auch -fähig, möchte aber auch darauf hinweisen, dass die manuelle Vergabe/Änderung der Adresse nicht veränderbar sein sollte! Aber der IP-Adressbereich sollte – allein schon zum besseren Verständnis für das Feld "IPvX Peer Adresse" (hier sowie an anderen Stellen würde korrektes/stringentes Deutsch und vielleicht auch intuitiveres Wording die Qualitätsanmutung unterstützen) zumindest vorgegeben werden.
Bei mir war noch ein Einrichtungsproblem, dass der private Schlüssel zwingend im Format x25519 angelegt werden muss. Auch hier sollte die UTM den Benutzer führen und nur solche Formate zur Auswahl anbieten, die im Rahmen einer Wireguard-VPN-Einrichtung auch nutzbar sind.
Nachdem diese Punkte geklärt waren, war der Rest eigentlich UTM-typisch.