Wireguard und Roadwarrior

[JanKey]

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?

[MADhase]

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!)

[FlorianS]

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:

• WireGuard E2S-Peer <WireGuard-Benutzer> korrekt in Datenbank konfiguriert

• Code: Alles auswählen

  wireguard get

  zeigt Peer mit korrektem Public Key, IP 10.0.10.2, Flag USER

• 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)

[FlorianS]

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:

• 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

[jansc]

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.  

[FlorianS]

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

[FlorianS]

(Da ich ja keinen VPN-Zugriff habe und nur selten vor Ort bin, kann ich nicht immer sofort reagieren und testen.)