13
Wireguard PFsense zu Securepoint - Kein traffic
Hallo,
ich probiere mich gerade daran eine pfsense mittels wireguard mit einer securepoint zu verbinden.
Die Verbindung funktioniert aber ich kann die IPs auf der anderen seite nicht anpingen oder sonstige Verbindungen herstellen.
Meine Schulung bei Securepoint ist schon recht lange her... Vermutlich fehlen hier irgendwo 2 Haken, aber ich finde nicht wo.
Netzwerk 1 R
Virtuelle Securepoint bei Wortmann und dahinter ein Windows-Server SRV05
10.100.0.11 im Transfernetzwerk
Netzwerk 2 O
Virtuelle pfsense 2.72 (aktuellste Version) und dahinter ein Windows-Server SRV01
10.100.0.1 im Transfernetzwerk
Was funktioniert.
Ich habe auf einem PC bei mir zu Hause den Wireguard-Client installiert.
Ich kann mich mit Netzwerk 2 verbinden und auf SRV01 zugreifen (ping + smb)
Ich habe auf dem Server SRV05 Netzwerk 1 den Wireguard-Client installiert.
Ich kann mich mit Netzwerk 2 verbinden und auf SRV01 zugreifen (ping + smb)
Dann habe ich die Konfiguration von SRV05 im Netzwerk 1 genommen und mit dieser als Vorlage einen Wireguard-Verbindung bei der Securepoint in Netzwerk 1 benutzt. Den Client habe ich wieder deinstalliert damit der nicht stört.
Das funktioniert nicht.
Laut Status sagen sowohl die Securepoint als auch die pfsense, dass sie verbunden sind.
Aber ich kann von SRV05 nicht auf SRV01 zugreifen.
Es müsste ja zumindest die Richtung SRV05->SRV01 funktionieren.
Die Regeln hat alle die Securepoint selber angelegt.
Laut Anleitung sollte das out of the box funktionieren.
Die Logs haben mich nicht weitergebracht.
Die Regeln auf der pfsense sind aktuell zum testen alles und any.
10.100.0.0/24 ist das Transfer-Netzwerk
Aber irgendwas fehlt.
Vieleicht hat ja Jemand einen Tipp.
PFSense
WL1 ist bei mir Zuhause
RZ ist Netzwerk 1R
Securepoint
10.100.0.0/24 ist das Transfernetzwerk
Regeln Securepoint
Ich wäre gerne bereit Jemanden dafür zu bezahlen der sich damit auskennt und in den nächsten Tagen Zeit hätte das Remote einzurichten bevor ich mir einen Finger abbreche.
ich probiere mich gerade daran eine pfsense mittels wireguard mit einer securepoint zu verbinden.
Die Verbindung funktioniert aber ich kann die IPs auf der anderen seite nicht anpingen oder sonstige Verbindungen herstellen.
Meine Schulung bei Securepoint ist schon recht lange her... Vermutlich fehlen hier irgendwo 2 Haken, aber ich finde nicht wo.
Netzwerk 1 R
Virtuelle Securepoint bei Wortmann und dahinter ein Windows-Server SRV05
10.100.0.11 im Transfernetzwerk
Netzwerk 2 O
Virtuelle pfsense 2.72 (aktuellste Version) und dahinter ein Windows-Server SRV01
10.100.0.1 im Transfernetzwerk
Was funktioniert.
Ich habe auf einem PC bei mir zu Hause den Wireguard-Client installiert.
Ich kann mich mit Netzwerk 2 verbinden und auf SRV01 zugreifen (ping + smb)
Ich habe auf dem Server SRV05 Netzwerk 1 den Wireguard-Client installiert.
Ich kann mich mit Netzwerk 2 verbinden und auf SRV01 zugreifen (ping + smb)
Dann habe ich die Konfiguration von SRV05 im Netzwerk 1 genommen und mit dieser als Vorlage einen Wireguard-Verbindung bei der Securepoint in Netzwerk 1 benutzt. Den Client habe ich wieder deinstalliert damit der nicht stört.
Das funktioniert nicht.
Laut Status sagen sowohl die Securepoint als auch die pfsense, dass sie verbunden sind.
Aber ich kann von SRV05 nicht auf SRV01 zugreifen.
Es müsste ja zumindest die Richtung SRV05->SRV01 funktionieren.
Die Regeln hat alle die Securepoint selber angelegt.
Laut Anleitung sollte das out of the box funktionieren.
Die Logs haben mich nicht weitergebracht.
Die Regeln auf der pfsense sind aktuell zum testen alles und any.
10.100.0.0/24 ist das Transfer-Netzwerk
Aber irgendwas fehlt.
Vieleicht hat ja Jemand einen Tipp.
PFSense
RZ ist Netzwerk 1R
Securepoint
Regeln Securepoint
Ich wäre gerne bereit Jemanden dafür zu bezahlen der sich damit auskennt und in den nächsten Tagen Zeit hätte das Remote einzurichten bevor ich mir einen Finger abbreche.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 670343
Url: https://administrator.de/forum/wireguard-pfsense-zu-securepoint-kein-traffic-670343.html
Ausgedruckt am: 24.12.2024 um 14:12 Uhr
13 Kommentare
Neuester Kommentar
Update: Ich habe gerade die Ping-Test-Funktion in der Securepoint gefunden.
PING 10.100.0.1 (10.100.0.1) from 10.100.0.11: 56 data bytes
64 bytes from 10.100.0.1: seq=0 ttl=64 time=16.282 ms
64 bytes from 10.100.0.1: seq=1 ttl=64 time=15.901 ms
64 bytes from 10.100.0.1: seq=2 ttl=64 time=15.733 ms
64 bytes from 10.100.0.1: seq=3 ttl=64 time=16.396 ms
64 bytes from 10.100.0.1: seq=4 ttl=64 time=16.205 ms
Auch der Ping auf SRV01 funktioniert in der SP.
Die Verbindung scheint also zu funktionieren, aber die SP ist der Meinung, dass ich das besser nicht von einem pc machen sollte. Ich suche mal weiter.
PING 10.100.0.1 (10.100.0.1) from 10.100.0.11: 56 data bytes
64 bytes from 10.100.0.1: seq=0 ttl=64 time=16.282 ms
64 bytes from 10.100.0.1: seq=1 ttl=64 time=15.901 ms
64 bytes from 10.100.0.1: seq=2 ttl=64 time=15.733 ms
64 bytes from 10.100.0.1: seq=3 ttl=64 time=16.396 ms
64 bytes from 10.100.0.1: seq=4 ttl=64 time=16.205 ms
Auch der Ping auf SRV01 funktioniert in der SP.
Die Verbindung scheint also zu funktionieren, aber die SP ist der Meinung, dass ich das besser nicht von einem pc machen sollte. Ich suche mal weiter.
Moin.
Hast du auf der pfSense denn überhaupt die nötigen statischen Routen zu den anderen Netzen angelegt? Diese erstellt die pfSense nicht automatisch aus den AllowedIPs! Du musst also für die Peers jeweils ein GW mit dessen IP im Transfernetz anlegen und diesem die jeweiligen dahinter liegenden Subnetze statisch zuweisen, damit die Pakete ihren Weg wieder zurück finden.
Doku pfSense
Auf der Client-Seite musst du das natürlich auch sicherstellen, also prüfen ob dort die Routen angelegt wurden, und wenn sie nicht automatisch angelegt werden, wie auf der pfSense manuell anlegen.
Mikrotik und pfSense sind zwei Beispiele die diese Routen nicht automatisch anlegen.
Gruß gastric
Frohes 🎄
Hast du auf der pfSense denn überhaupt die nötigen statischen Routen zu den anderen Netzen angelegt? Diese erstellt die pfSense nicht automatisch aus den AllowedIPs! Du musst also für die Peers jeweils ein GW mit dessen IP im Transfernetz anlegen und diesem die jeweiligen dahinter liegenden Subnetze statisch zuweisen, damit die Pakete ihren Weg wieder zurück finden.
Doku pfSense
Auf der Client-Seite musst du das natürlich auch sicherstellen, also prüfen ob dort die Routen angelegt wurden, und wenn sie nicht automatisch angelegt werden, wie auf der pfSense manuell anlegen.
Mikrotik und pfSense sind zwei Beispiele die diese Routen nicht automatisch anlegen.
Gruß gastric
Frohes 🎄
1
Hallo,
so, ich habe dies angelegt.
Ja, ich dachte er würde das automatisch machen. sorry.
Nun kann ich von srv05 die 10.100.0.1 anpingen. den Rest aber nicht und in die andere Richtig von srv01 gar nichts.
SRV05
R
LAN IP 10.95.10.10
Transfer IP: 10.100.0.11
SRV01
O
LAN IP 10.150.10.10
Transfer IP: 10.100.0.1
Und Danke für Deine Zeit und Muße.
so, ich habe dies angelegt.
Ja, ich dachte er würde das automatisch machen. sorry.
Nun kann ich von srv05 die 10.100.0.1 anpingen. den Rest aber nicht und in die andere Richtig von srv01 gar nichts.
SRV05
R
LAN IP 10.95.10.10
Transfer IP: 10.100.0.11
SRV01
O
LAN IP 10.150.10.10
Transfer IP: 10.100.0.1
Und Danke für Deine Zeit und Muße.
Und hier die securepoint. Die Einträge wurden alle automatisch erstellt.
Hier habe ich von Hand was hinzugefügt.
Hier habe ich von Hand was hinzugefügt.
Eine statische Router zu 10.100.0.0/24 darf ich auf der pfsense nicth anlegen, da diese mit wireguard in konflikt stehen würde.
Zitat von @StefanKittel:
Eine statische Router zu 10.100.0.0/24 darf ich auf der pfsense nicth anlegen, da diese mit wireguard in konflikt stehen würde.
Eine statische Router zu 10.100.0.0/24 darf ich auf der pfsense nicth anlegen, da diese mit wireguard in konflikt stehen würde.
Eine Route zum Transfernetz ist ja auch Blödsinn das Netz kennt der Router ja bereits, nee ich meine die Netze die hinter den gegenüberliegenden Routern sitzen !!
Bedenke auch das die Clients die hinter den Routern liegen den Router auch als DefaultGW haben müssen damit die Pakete den Weg zurück finden, ist das nicht der Fall sind auf dessen GW ebenfalls entsprechende Routen auf das WG Gateway anzulegen.
Die Firewall der Clients nicht vergessen, SMB und ICMP wird unter Windows per Default aus fremden Netzen geblockt.
Ja, die Firewall ist auf beiden Seiten deaktiviert und die beiden Server haben jeweils die pfsense/securepoint als GW.
Wenn ich mich mit einem Client in beide Seiten einwähle kann ich auf die Server mittels Ping und SMB zugreifen.
Vorschlöge wie man das eingrenzen kann?
Wenn ich mich mit einem Client in beide Seiten einwähle kann ich auf die Server mittels Ping und SMB zugreifen.
Vorschlöge wie man das eingrenzen kann?
Pakete Schritt für Schritt verfolgen, Traceroute und Wireshark sind dein Freunde und Helfer.
Denke auch daran das die AllowediPs immer alle beteiligten Netze beinhalten müssen.
Also ausgehend sämtliche Zielnetze enthalten müssen und ebenfalls eingehend betrachtet die Netze von denen Traffic erwartet wird. Das wird besonders dann wichtig wenn man mehrere Peers mit unterschiedlichen Netzen an einem zentralen Punkt miteinander verbinden will.
Generisches Beispiel:
Zentraler Server mit WG
- Transfernetz: 10.100.0.0/24
IP: 10.100.0.1/24
- PEER-Zweigstelle1: 10.100.0.2/32
AllowedIPs: 10.100.0.2/32, 10.10.1.0/24
- PEER-Zweigstelle2: 10.100.0.3/32
AllowedIPs: 10.100.0.3/32, 10.10.2.0/24
Zweigstelle1
- LAN: 10.10.1.0/24
- ALLOWEDIPs: 10.100.0.1/32, 10.10.2.0/24
Zweigstelle2
- LAN: 10.10.2.0/24
- ALLOWEDIPs: 10.100.0.1/32, 10.10.1.0/24
Denke auch daran das die AllowediPs immer alle beteiligten Netze beinhalten müssen.
Also ausgehend sämtliche Zielnetze enthalten müssen und ebenfalls eingehend betrachtet die Netze von denen Traffic erwartet wird. Das wird besonders dann wichtig wenn man mehrere Peers mit unterschiedlichen Netzen an einem zentralen Punkt miteinander verbinden will.
Generisches Beispiel:
Zentraler Server mit WG
- Transfernetz: 10.100.0.0/24
IP: 10.100.0.1/24
- PEER-Zweigstelle1: 10.100.0.2/32
AllowedIPs: 10.100.0.2/32, 10.10.1.0/24
- PEER-Zweigstelle2: 10.100.0.3/32
AllowedIPs: 10.100.0.3/32, 10.10.2.0/24
Zweigstelle1
- LAN: 10.10.1.0/24
- ALLOWEDIPs: 10.100.0.1/32, 10.10.2.0/24
Zweigstelle2
- LAN: 10.10.2.0/24
- ALLOWEDIPs: 10.100.0.1/32, 10.10.1.0/24
1
Hallo,
das hier zeigt der paket filter für das transfernetz an der pfsense für ICMPv4
09:35:14.311228 IP 10.100.0.1 > 10.100.0.11: ICMP echo request, id 8474, seq 9481, length 40
09:35:15.180939 IP 10.95.10.20 > 10.100.0.1: ICMP echo request, id 1, seq 22158, length 40
09:35:15.180957 IP 10.100.0.1 > 10.95.10.20: ICMP echo reply, id 1, seq 22158, length 40
09:35:16.195795 IP 10.95.10.20 > 10.100.0.1: ICMP echo request, id 1, seq 22159, length 40
09:35:16.195813 IP 10.100.0.1 > 10.95.10.20: ICMP echo reply, id 1, seq 22159, length 40
09:35:17.201133 IP 10.95.10.20 > 10.100.0.1: ICMP echo request, id 1, seq 22160, length 40
09:35:17.201159 IP 10.100.0.1 > 10.95.10.20: ICMP echo reply, id 1, seq 22160, length 40
09:35:18.206281 IP 10.95.10.20 > 10.100.0.1: ICMP echo request, id 1, seq 22161, length 40
09:35:18.206305 IP 10.100.0.1 > 10.95.10.20: ICMP echo reply, id 1, seq 22161, length 40
09:35:18.540510 IP 10.95.10.20 > 10.150.50.10: ICMP echo request, id 1, seq 22162, length 40
09:35:19.223363 IP 10.95.10.20 > 10.100.0.1: ICMP echo request, id 1, seq 22163, length 40
09:35:19.223389 IP 10.100.0.1 > 10.95.10.20: ICMP echo reply, id 1, seq 22163, length 40
09:35:19.312158 IP 10.100.0.1 > 10.100.0.11: ICMP echo request, id 8474, seq 9483, length 40
09:35:20.245276 IP 10.95.10.20 > 10.100.0.1: ICMP echo request, id 1, seq 22164, length 40
09:35:20.245304 IP 10.100.0.1 > 10.95.10.20: ICMP echo reply, id 1, seq 22164, length 40
09:35:21.248477 IP 10.95.10.20 > 10.100.0.1: ICMP echo request, id 1, seq 22165, length 40
das hier zeigt der paket filter für das Netz mit SRV01 an der pfsense für ICMPv4
09:38:42.814179 IP 10.150.50.10 > 10.95.10.20: ICMP echo request, id 1, seq 9564, length 40
09:38:43.526984 IP 10.95.10.20 > 10.150.50.10: ICMP echo request, id 1, seq 22405, length 40
09:38:43.527540 IP 10.150.50.10 > 10.95.10.20: ICMP echo reply, id 1, seq 22405, length 40
09:38:44.314077 IP 10.150.50.10 > 10.100.0.11: ICMP echo request, id 1, seq 9565, length 40
09:38:47.813801 IP 10.150.50.10 > 10.95.10.20: ICMP echo request, id 1, seq 9566, length 40
09:38:48.531609 IP 10.95.10.20 > 10.150.50.10: ICMP echo request, id 1, seq 22411, length 40
09:38:48.532132 IP 10.150.50.10 > 10.95.10.20: ICMP echo reply, id 1, seq 22411, length 40
09:38:49.313113 IP 10.150.50.10 > 10.100.0.11: ICMP echo request, id 1, seq 9567, length 40
09:38:50.869112 IP 10.150.62.12 > 10.150.50.28: ICMP echo request, id 1, seq 1894, length 40
09:38:50.869665 IP 10.150.50.28 > 10.150.62.12: ICMP echo reply, id 1, seq 1894, length 40
09:38:52.813976 IP 10.150.50.10 > 10.95.10.20: ICMP echo request, id 1, seq 9568, length 40
09:38:53.533084 IP 10.95.10.20 > 10.150.50.10: ICMP echo request, id 1, seq 22417, length 40
09:38:53.533592 IP 10.150.50.10 > 10.95.10.20: ICMP echo reply, id 1, seq 22417, length 40
09:38:54.324300 IP 10.150.50.10 > 10.100.0.11: ICMP echo request, id 1, seq 9569, length 40
Sieht für mich beides gut aus.
Ich suche mal die Funktion in der securepoint
das hier zeigt der paket filter für das transfernetz an der pfsense für ICMPv4
09:35:14.311228 IP 10.100.0.1 > 10.100.0.11: ICMP echo request, id 8474, seq 9481, length 40
09:35:15.180939 IP 10.95.10.20 > 10.100.0.1: ICMP echo request, id 1, seq 22158, length 40
09:35:15.180957 IP 10.100.0.1 > 10.95.10.20: ICMP echo reply, id 1, seq 22158, length 40
09:35:16.195795 IP 10.95.10.20 > 10.100.0.1: ICMP echo request, id 1, seq 22159, length 40
09:35:16.195813 IP 10.100.0.1 > 10.95.10.20: ICMP echo reply, id 1, seq 22159, length 40
09:35:17.201133 IP 10.95.10.20 > 10.100.0.1: ICMP echo request, id 1, seq 22160, length 40
09:35:17.201159 IP 10.100.0.1 > 10.95.10.20: ICMP echo reply, id 1, seq 22160, length 40
09:35:18.206281 IP 10.95.10.20 > 10.100.0.1: ICMP echo request, id 1, seq 22161, length 40
09:35:18.206305 IP 10.100.0.1 > 10.95.10.20: ICMP echo reply, id 1, seq 22161, length 40
09:35:18.540510 IP 10.95.10.20 > 10.150.50.10: ICMP echo request, id 1, seq 22162, length 40
09:35:19.223363 IP 10.95.10.20 > 10.100.0.1: ICMP echo request, id 1, seq 22163, length 40
09:35:19.223389 IP 10.100.0.1 > 10.95.10.20: ICMP echo reply, id 1, seq 22163, length 40
09:35:19.312158 IP 10.100.0.1 > 10.100.0.11: ICMP echo request, id 8474, seq 9483, length 40
09:35:20.245276 IP 10.95.10.20 > 10.100.0.1: ICMP echo request, id 1, seq 22164, length 40
09:35:20.245304 IP 10.100.0.1 > 10.95.10.20: ICMP echo reply, id 1, seq 22164, length 40
09:35:21.248477 IP 10.95.10.20 > 10.100.0.1: ICMP echo request, id 1, seq 22165, length 40
das hier zeigt der paket filter für das Netz mit SRV01 an der pfsense für ICMPv4
09:38:42.814179 IP 10.150.50.10 > 10.95.10.20: ICMP echo request, id 1, seq 9564, length 40
09:38:43.526984 IP 10.95.10.20 > 10.150.50.10: ICMP echo request, id 1, seq 22405, length 40
09:38:43.527540 IP 10.150.50.10 > 10.95.10.20: ICMP echo reply, id 1, seq 22405, length 40
09:38:44.314077 IP 10.150.50.10 > 10.100.0.11: ICMP echo request, id 1, seq 9565, length 40
09:38:47.813801 IP 10.150.50.10 > 10.95.10.20: ICMP echo request, id 1, seq 9566, length 40
09:38:48.531609 IP 10.95.10.20 > 10.150.50.10: ICMP echo request, id 1, seq 22411, length 40
09:38:48.532132 IP 10.150.50.10 > 10.95.10.20: ICMP echo reply, id 1, seq 22411, length 40
09:38:49.313113 IP 10.150.50.10 > 10.100.0.11: ICMP echo request, id 1, seq 9567, length 40
09:38:50.869112 IP 10.150.62.12 > 10.150.50.28: ICMP echo request, id 1, seq 1894, length 40
09:38:50.869665 IP 10.150.50.28 > 10.150.62.12: ICMP echo reply, id 1, seq 1894, length 40
09:38:52.813976 IP 10.150.50.10 > 10.95.10.20: ICMP echo request, id 1, seq 9568, length 40
09:38:53.533084 IP 10.95.10.20 > 10.150.50.10: ICMP echo request, id 1, seq 22417, length 40
09:38:53.533592 IP 10.150.50.10 > 10.95.10.20: ICMP echo reply, id 1, seq 22417, length 40
09:38:54.324300 IP 10.150.50.10 > 10.100.0.11: ICMP echo request, id 1, seq 9569, length 40
Sieht für mich beides gut aus.
Ich suche mal die Funktion in der securepoint
Das hier steht im Log der securepoint.
Ich habe dazu nur einen Post gefunden der einen Neustart empfohlen hat. Hat aber nichts geändert.
Ich habe dazu nur einen Post gefunden der einen Neustart empfohlen hat. Hat aber nichts geändert.
Update: Nach einem 2. Neustart kann ich von srv01 nun auch das transfernetz im RZ anpingen.
👍
An die Winblows Firewall und deren standardmässiges Blocken von ICMP hast du gedacht wenn du Winblows Endgeräte via VPN pingst?! 🤔
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Gilt übrigens auch von allem eingehenden Traffic mit Fremdnetz Absender IPs die die Windows Firewall blockiert. Ggf. musst du hier auch noch etwas "customizen".
Alle WG Details wie immer hier und in den weiterführenden Links.
🎅 🌲
An die Winblows Firewall und deren standardmässiges Blocken von ICMP hast du gedacht wenn du Winblows Endgeräte via VPN pingst?! 🤔
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Gilt übrigens auch von allem eingehenden Traffic mit Fremdnetz Absender IPs die die Windows Firewall blockiert. Ggf. musst du hier auch noch etwas "customizen".
Alle WG Details wie immer hier und in den weiterführenden Links.
🎅 🌲
Bin ja beruhigt, dass auch die erfahreneren Kollegen immer mal wieder vor den selben (häufig profanen) Hürden stehen, wie ich 😇
In diesem Sinne schöne Weihnachten an alle Forenmitglieder und viel Erfolg bei den feiertäglichen Basteleien in der „staden Zeit“ 😉
In diesem Sinne schöne Weihnachten an alle Forenmitglieder und viel Erfolg bei den feiertäglichen Basteleien in der „staden Zeit“ 😉
1
