Wireguard ins Heimnetzwerk

[HeadphoneGuy]

Ich beiße mir gerade die Zähne an PFSense 2.5.2 und Wireguard aus.

Interne Netzwerke:
10.255.4.0/24
10.255.5.0/24
192.168.0.0/19

Transfernetz:
10.255.12.0/24 Untangle: 10.255.12.1 PFsense: 10.255.12.2

Wireguard Netz: 10.40.40.0/24 Pfsense: 10.40.40.1 Client: 10.40.40.3

Aus den internen Netzen komme ich über das Transfernetz problemlos bis zu 10.40.40.1 genauso kann ich vom WG0 Interface auf PFSense bis ins interne Netz pingen.. Der Tunnel ist aufgebaut und es fließen auch Daten vom Client zur PFSense. Retour kommt allerdins nichts. Das WG0 Interface auf der PFSense ist vom Client aus nicht zu erreichen.

Die Verbindung wird aus einem weiteren Transfernetz im LAN aufgebaut. Also definitiv nichts was am Provider liegen kann.

Natives Wireguard im Untangle ist mir für mein Heimnetz zu teuer.

 

[LieberNetterFlo]

also ich verbinde mich mit meinem Handy zu meiner pfSense via Wireguard ... Roadwarrior quasi. Unterscheidet sich meine Config stark von deiner? Wenn nicht könnte ich Screenshots hier reinstellen.

bei mir funktioniert eigentlich alles super, inkl. IPv6.

 

[kamanu]

Du nutzt 2 Firewalls nebeneinander? Generell schonmal ein Quelle potentieller Fehler. Macht die pfsense außer Wireguard noch was? Falls nein tut's auch ne VM (oder nen Pi) mit pivpn.io.

 

[snaxilian]

Wenn der Weg hin funktioniert aber zurück nicht dann sind es in 95% der Fälle fehlende Routingeinträge.

 

[HeadphoneGuy]

Die PFSense soll eigentlich nur Wireguard machen für Roadwarrior Einsatz.

Routing zwischen den LAN Netzen und dem Wireguard Interface scheint zu klappen. Pings gehen jedenfalls aus den Netzen der Untangle bis zum Wireguard Interface durch.

Die Firewall von PFSense hätte ich am liebsten komplett auf Durchzug gestellt und erst auf der Untangle gefiltert.

Dass das Routing den Fehler auslöst würde mich wundern. Effektiv scheidert es irgendwo zwischen Wireguard Interface und dem Testclient. Windows Firewall ist dort aus und der angemeldete User ist lokaler Admin.

Ping von 10.255.8.xxx auf 10.40.40.1 klappt.
Ping von 10.40.40.1 auf 10.255.8.xxx oder 192.168.0.20 (DNS) klappt auch.

Ich komme von den LAN Netzen der Untangle bis an das Wireguard Interface. Da sollte der Weg ins Netz auch klappen . Allerdings komm ich durch den Tunnel nicht mal an das Wireguard Interface. Vom Wireguard Interface allerdings auch nicht auf den Client. Das sollte eigentlich auch bei einem absolutem Routing Clusterfxxx funktionieren da es sich noch im selben Subnetz abspielt.

PFSense und Untangle laufen beide unter Hyper-V auf einem Server 2019

Danke für Eure tatkräftige unterstützung.

Routing Untangle

Routing PFSense

Topologie:

 

[Raijin]

Der Tunnel ist aufgebaut und es fließen auch Daten vom Client zur PFSense. Retour kommt allerdins nichts. Das WG0 Interface auf der PFSense ist vom Client aus nicht zu erreichen.

Solange die VPN-Verbindung noch nicht vernünftig läuft, also beidseitige Pings möglich sind, brauchst du mit Pings in/aus andere(n) Subnetze(n) gar nicht erst anfangen.

Pings aus den lokalen Netzen auf andere IPs desselben Routers könnten irreführend sein, weil der Router ggfs merkt, dass er ja selbst angesprochen wird, nur auf einem anderen Interface, und deswegen den Ping lokal beantwortet und eben nicht im eigentlichen Sinne forwarded. Mit pfSense habe ich das noch nicht ausprobiert, aber bei einer Cisco ASA 5506-X ist mir das mal aufgefallen. 3 Interfaces konfiguriert, Firewall blockt gegenseitigen Zugriff, aber trotzdem konnte ich die IP des anderen Interfaces der ASA pingen, aber keinen Teilnehmer hinter der ASA.

Wie auch immer, das spielt letztendlich keine Rolle solange die VPN-Verbindung nicht voll funktionsfähig ist. Sonst dokterst du im Zweifelsfalle an der falschen Stelle rum. Sofern die pfSense kein ICMP auf dem VPN-Interface blockiert, muss der Ping vom VPN-Client auch ankommen und beantwortet werden. Ist das nicht der Fall, läuft irgendwas mit dem VPN schief. Ich würde die VPN-Verbindung nochmal komplett neu aufsetzen.

 

[LieberNetterFlo]

ich würde tatsächlich auch was anderes nehmen außer pfSense, wenn es doch nur ein Wireguard VPN Server sein soll? https://pivpn.io/ wurde ja schon angesprochen.

 

[snaxilian]

Im Zweifel mit tcpdump auf allen beteiligten Geräten und Interfaces prüfen ob die ICMPs wirklich korrekt rausgehen und ankommen. Wenn ich auf einer Firewall oder Router sehe, dass Anfragen auf ethX ankommen aber nicht auf ethY raus gehen, dann weiß man, dass das betroffene Gerät entweder nicht routet oder entsprechende FW Regeln fehlen. Routing lässt sich schnell prüfen und Firewalls bieten logging, ggf. das Log-Level anpassen.

 

[HeadphoneGuy]

Grundsätzlich scheint es jetzt zu laufen aber eben nur Grundsätzlich. Wenn es um Linux geht bin ich ein kompletter noob. TCP Dump hab ich gefunden nur anfangen kann ich mit dem .tar.gz file genau gar nichts außer mit 7zip entpacken.

Config am Notebook die mitlerweile funktioniert:

[Interface]
PrivateKey = XXX=
Address = 10.40.40.3/24
DNS = 192.168.0.20
MTU = 1420

[Peer]
PublicKey = YYY=
AllowedIPs = 0.0.0.0/0
Endpoint = 212.186.ZZ.ZZ:51820

Config am Telefon (Samsung Galaxy A51) die nicht funktioniert. Klappt auch nicht wenn ich die IPConfig vom Notebook eintrage.

Sollte eigentlich das gleiche sein. Tunnel kommt hoch aber wieder kein Verkehr in Richtung Client.

 

[snaxilian]

Mea culpa. Da habe ich wohl angenommen wer sich mehrere Firewalls hin stellt und sich irgendwas zusammen frickelt hat grundlegendes Wissen über Analyse und Fehlersuche im Bereich Netzwerk.
tcpdump ist neben nc (oder telnet) eigentlich das Schweizer Taschenmesser der Tools. Das ist auch nix linux-spezifisches, unter Windows kannst das genauso verwenden. Optional gibt's mit Wireshark auch ein grafisches Tool dazu.
Hilfreich ist, wenn man die Suchfilter eingrenzt, also auf das gewünschte Interface, ggf. nur die Header der Pakete, Protokoll und ggf. Zielport damit man alles andere direkt rausfiltert. Man kann aber auch tcpdump Aufzeichnungen in Wireshark laden und dann dann dort nachträglich filtern und suchen.
Beliebige Übersicht und Einführung inkl. Beispielen: https://wiki.ubuntuusers.de/tcpdump/

 

[HeadphoneGuy]

Hab vorhin noch 3 funktionierende Windows Clients auf die Reihe gebracht. Dann versehentlich auf "Restart Service" geklickt und seit dem geht wieder nichts. Client Reboot und PFSense reboot danach hat auch nichts gebracht. Tot wie es scheint.

Da werden Produkte wie A1 Dataguard die einfach über einen privaten APN abgewickelt werden schon attraktiv.

 

[snaxilian]

Ist halt wie bei allem im Leben. Entweder du bringst eigene Zeit auf um Wissen zu erlangen und damit etwas umzusetzen oder du tauscht Zeit gegen Geld und zahlst dafür, dass andere ihr Wissen nutzen. 🤷‍♂️