Kein curl / Wget bei opnsense Client über Wireguard

[itsed]

Hallo liebes Forum,
ich versuche schon seit Tagen mehrere Clients über Wireguard zu routen. Ich habe es fast geschaft. Download / Upload funktioniert gut. Performance passt auch. Keine Pakete gehe verloren. Leider kann ich aber auf meinen Clients kein wget oder curl ... ausführen. Ich habe keine Ahnung, warum das nicht möglich ist. Leider funktioniert KEINES der Tutorials online. Bitte dringend um Hilfe.

 

[itsed]

Mehr Bilder

 

[blurrrr]

Also jetzt mal ohne die Bilder durchgesehen zu haben...

Download / Upload funktioniert gut. Performance passt auch. Keine Pakete gehe verloren. Leider kann ich aber auf meinen Clients kein wget oder curl ... ausführen.

Bis auf den letzten Teil schon doch alles zu passen? Ich würde vielleicht mal in erster Instanz schauen, ob die Dinge auch wirklich so laufen, wie Du glaubst, dass sie laufen Stichwort: "Traceroute" (in einer Shell/Eingabeaufforderung - Windows "tracert", OSX/Linux "traceroute"). Überprüf das einfach mal zuerst. Dazu wäre dann noch eine konkretere Beschreibung Deines Vorhabens ganz hilfreich

 

[itsed]

Hi. Ja traceroute passt natürlich. Ich will einfach nur einen Router der die clients von seinem LAN über das wireguard routet. Scheint irgendwie bei 443 zu hängen. Ich habe keine Ahnung.

 

[blurrrr]

Kann es vielleicht sein, dass die Gegenstelle einfach nicht mit Deinem Netz will (Firewall und so)? Keine Ahnung, was als VPN-Gateway an der Gegenstelle läuft, aber ein Blick in die Logs ist meistens Gold wert Steht nichts in den Logs hätte ich in erster Instanz auf ein Routing-Problem getippt, funktioniert das aber, ist es meistens irgendeine Firewall-Regel, welche die Kommunikation unterbindet (ICMP ist da meist noch so eine Sonderlocke, nur weil ICMP funktioniert, heisst es noch lange nicht, dass auch alles andere funktioniert), also: Beim testen schön die Logs der Firewalls "beider" Seiten schauen

 

[itsed]

Denk nicht. Da ich mit anderen Clients, welche direkt per VPN verbunden sind ohne Probleme CURL und WGET nutzen kann. Das muss quasi an den Firewall Einstellungen der OPNSense liegen. sudo apt-get update, upgrade und install funktioniert ohne Probleme. Jemand ne Idee?
Komischerweise funktioniert es einmal bzw. manchmal und dann wieder überhaupt nicht. Hier der Wireshark von einem der Ubuntu Clients

 

[itsed]

Irgendjemand eine Idee warum das so random ist?

 

[blurrrr]

anderen Clients, welche direkt per VPN verbunden sind

Roadwarrior ist nicht gleich Site-to-Site, aber sei's drum... Mach die Firewall-Logs auf und guck rein, von einem "ich denke nicht" kann sich keiner was kaufen. Ein Wireshark auf dem Client bringt auch erstmal herzlich wenig, wenn ALLE Clients das Problem haben. Schmeisst irgendwas auf dem Weg die Pakete weg (drop) -> schade, dumm gelaufen, wirst Du so nicht sehen. Man könnte jetzt "mutmaßen" (z.B. bzgl. Retransmission), dass der Client es noch weiter versucht, aber dafür kann es auch andere Gründe geben (ebenso beim Reset (RST)).

Mir drängt sich auch irgendwo die Frage auf: Wofür die NAT-Regel? Für IPv6 sicherlich nicht und WAN-seitig sieht mir das sehr schwer nach einer Fritzbox aus, die macht sowieso schon NAT in Richtung Internet und beherrscht statische Routen, womit sich der NAT-Punkt eigentlich mal komplett erledigt hätte (doppeltes NAT ist sowieso nicht schön).

Und so ganz nebenbei: Ab einem bestimmten Punkt ist es nicht mehr ganz so trivial... Einfach nur zu sagen "geht nicht" und einfach mal "auszugsweise" (z.B. von 1/2 Firewalls) ein paar Screenshots zu verteilen, macht es nicht wirklich besser. In "allererster" Linie sollte mit Worten (oder ggf. mit einer Skizze) beschrieben werden, wie der IST-Zustand ist und wohin die Reise gehen soll (SOLL-Zustand). Wenn man ggf. schon "kurz vor dem Ziel" ist, sollte dennoch beschrieben werden, was genau man eigentlich erreichen will. Ich kann hier auch nur mutmaßen, z.B. "Hm... will er jetzt den Traffic von einem Standort über den anderen leiten und von dort ins Netz schicken?", oder auch "Geht es nur darum, dass der Traffic nicht durch vernünftig durch den Tunnel läuft? Aber warum spricht er dann "später" von "externen" Adressen" (curl/wget an dieser Stelle heisst noch lange nicht, dass Du mit "extern" sprichst, könnte auch eine Gegenstelle im anderen privaten Netz sein). Ebenso hiess es "mehrere Clients über Wireguard"... tja... mehrere Roadwarrior-Configs, oder doch ein ganzes Subnetz?

Also... nochmal kurz knapp und knackig (weil ich bzgl. Ratereien und Info-Bröckchen auch keine Lust habe (und vor allem keine Zeit)). Wie ist grundsätzlich der Aufbau? Zum Beispiel:

Netz A -> Firewall A -> Router A -> ----<Internet>---- <- Router B <- Firewall B <- Netz B

Damit wäre der Grundaufbau schon mal klar....

Netz A -> Firewall A -> ----<VPN>---- -> Firewall B -> Router B (+NAT) -> Internet

Dann wäre die gewünschte Strecke auch klar....

Denke Du weisst, was ich damit sagen will... So stehen die Chancen auf jeden Fall schon mal wesentlich besser, dass man eine Lösung finden kann, anstatt nur rumzuraten.

Jetzt davon mal ganz ab und wieder zurück zum Ursprungsthema (die o.g. Dinge darfst Du aber trotzdem gern noch nachreichen)... So wie ich das verstanden habe, hast Du a) das Site2Site-VPN und b) Roadwarrior-Configs. Die Roadwarrior-Configs funktionieren einfach, während es beim Site2Site-VPN nur "teilweise" der Fall ist (zumindestens habe ich das bisher so verstanden). Laufen die beiden Sachen denn auf Firewall A bzw. hängen alle Clients hinter Firewall A?

Zudem sprichst Du wget und curl an, was auf Web-Sachen hinauslaufen dürfte (http/https) und alles andere läuft ja Deiner Aussage nach (oder ggf. auch nur "manchmal"?). Kannst mal was ohne SSL versuchen (also rein http). Ansonsten... Keine Ahnung wie das mit dem Site2Site-VPN bei Wireguard läuft (hab ich mich noch garnicht mit beschäftigt), aber ich kenne ein anderes Szenario, wo es auch zu "komischen Effekten" kommen kann: Wenn sich z.B. 2 Clients mit den gleichen Accounts anmelden, bekommt der zuletzt eingewählte Client quasi die Verbindung. Der erste steht mitunter auch noch auf verbunden, bekommt aber keine Pakete mehr und kann auch nicht mehr ins Zielnetz. Wenn dann noch ein Keepalive im Spiel ist, kommt es mitunter auch mal vor, dass das Routing ständig zwischen diesen beiden Clients wechselt (was dann auch zu ekligen Effekten führt).

 

[itsed]

Roadwarrior ist nicht gleich Site-to-Site, aber sei's drum... Mach die Firewall-Logs auf und guck rein, von einem "ich denke nicht" kann sich keiner was kaufen. Ein Wireshark auf dem Client bringt auch erstmal herzlich wenig, wenn ALLE Clients das Problem haben. Schmeisst irgendwas auf dem Weg die Pakete weg (drop) -> schade, dumm gelaufen, wirst Du so nicht sehen. Man könnte jetzt "mutmaßen" (z.B. bzgl. Retransmission), dass der Client es noch weiter versucht, aber dafür kann es auch andere Gründe geben (ebenso beim Reset (RST)).

Mir drängt sich auch irgendwo die Frage auf: Wofür die NAT-Regel? Für IPv6 sicherlich nicht und WAN-seitig sieht mir das sehr schwer nach einer Fritzbox aus, die macht sowieso schon NAT in Richtung Internet und beherrscht statische Routen, womit sich der NAT-Punkt eigentlich mal komplett erledigt hätte (doppeltes NAT ist sowieso nicht schön).

Und so ganz nebenbei: Ab einem bestimmten Punkt ist es nicht mehr ganz so trivial... Einfach nur zu sagen "geht nicht" und einfach mal "auszugsweise" (z.B. von 1/2 Firewalls) ein paar Screenshots zu verteilen, macht es nicht wirklich besser. In "allererster" Linie sollte mit Worten (oder ggf. mit einer Skizze) beschrieben werden, wie der IST-Zustand ist und wohin die Reise gehen soll (SOLL-Zustand). Wenn man ggf. schon "kurz vor dem Ziel" ist, sollte dennoch beschrieben werden, was genau man eigentlich erreichen will. Ich kann hier auch nur mutmaßen, z.B. "Hm... will er jetzt den Traffic von einem Standort über den anderen leiten und von dort ins Netz schicken?", oder auch "Geht es nur darum, dass der Traffic nicht durch vernünftig durch den Tunnel läuft? Aber warum spricht er dann "später" von "externen" Adressen" (curl/wget an dieser Stelle heisst noch lange nicht, dass Du mit "extern" sprichst, könnte auch eine Gegenstelle im anderen privaten Netz sein). Ebenso hiess es "mehrere Clients über Wireguard"... tja... mehrere Roadwarrior-Configs, oder doch ein ganzes Subnetz?

Also... nochmal kurz knapp und knackig (weil ich bzgl. Ratereien und Info-Bröckchen auch keine Lust habe (und vor allem keine Zeit)). Wie ist grundsätzlich der Aufbau? Zum Beispiel:

Netz A -> Firewall A -> Router A -> ----<Internet>---- <- Router B <- Firewall B <- Netz B

Damit wäre der Grundaufbau schon mal klar....

Netz A -> Firewall A -> ----<VPN>---- -> Firewall B -> Router B (+NAT) -> Internet

Dann wäre die gewünschte Strecke auch klar....

Denke Du weisst, was ich damit sagen will... So stehen die Chancen auf jeden Fall schon mal wesentlich besser, dass man eine Lösung finden kann, anstatt nur rumzuraten.

Jetzt davon mal ganz ab und wieder zurück zum Ursprungsthema (die o.g. Dinge darfst Du aber trotzdem gern noch nachreichen)... So wie ich das verstanden habe, hast Du a) das Site2Site-VPN und b) Roadwarrior-Configs. Die Roadwarrior-Configs funktionieren einfach, während es beim Site2Site-VPN nur "teilweise" der Fall ist (zumindestens habe ich das bisher so verstanden). Laufen die beiden Sachen denn auf Firewall A bzw. hängen alle Clients hinter Firewall A?

Zudem sprichst Du wget und curl an, was auf Web-Sachen hinauslaufen dürfte (http/https) und alles andere läuft ja Deiner Aussage nach (oder ggf. auch nur "manchmal"?). Kannst mal was ohne SSL versuchen (also rein http). Ansonsten... Keine Ahnung wie das mit dem Site2Site-VPN bei Wireguard läuft (hab ich mich noch garnicht mit beschäftigt), aber ich kenne ein anderes Szenario, wo es auch zu "komischen Effekten" kommen kann: Wenn sich z.B. 2 Clients mit den gleichen Accounts anmelden, bekommt der zuletzt eingewählte Client quasi die Verbindung. Der erste steht mitunter auch noch auf verbunden, bekommt aber keine Pakete mehr und kann auch nicht mehr ins Zielnetz. Wenn dann noch ein Keepalive im Spiel ist, kommt es mitunter auch mal vor, dass das Routing ständig zwischen diesen beiden Clients wechselt (was dann auch zu ekligen Effekten führt).

Vielen Dank für deine Nachricht. Ich versuche Clients im Heimnetz über das VPN über der festen IP des VPS ins Internet zu schicken. Die Clients hängen als im virtual lan und dhcp hinter der Firewall A.

Netz A (192.168.10.0/24) -> OPENSense Firewall A (10.66.66.2)-> ----<VPN>---- -> (10.66.66.2) VPS IONOS Firewall B UFW -> Internet
WAN ist 192.168.1.1 (ASUS RT-AX88U) und dann über Vodafone Cable Router. Ich weiß leider nicht, wie ich das verständlicher aufzeigen kann.

Also mit curl http habe ich keine Probleme. Das läuft zuverlässig. Scheint ein Problem mit SSL zu sein oder?

Hier die Firewall vom VPS


hier die Logs vom VPS


Hier tcptrack -i wg0 vom VPS


Ich verstehe nicht, warum Firewall A blocked. Es ist eigentlich alles offen.





Vielen Dank für deine HIlfe!

 

[blurrrr]

Klick doch mal auf das "i" ganz rechts bei den Drop-Meldungen im Log. Davon ab bzgl. Deiner Firewall-Regel-Screenshots, da gibt es auch noch "16"(!) automatisch generierte Regeln, vielleicht schaust Du nochmal alle automatischen erzeugten Regeln durch, vielleicht ist da noch etwas im argen

 

[itsed]

Klick doch mal auf das "i" ganz rechts bei den Drop-Meldungen im Log. Davon ab bzgl. Deiner Firewall-Regel-Screenshots, da gibt es auch noch "16"(!) automatisch generierte Regeln, vielleicht schaust Du nochmal alle automatischen erzeugten Regeln durch, vielleicht ist da noch etwas im argen

Leider habe ich zu wenig Erfahrung, welche Regel in Konflikt stehen könnte. Haben Sie vielleicht eine Idee? Hier die Firewall Rules Floating:


Habe leider auch schon vergeblich versucht, herauszufinden welche Regel für den Block verantwortlich ist.

 

[blurrrr]

Habe leider auch schon vergeblich versucht, herauszufinden welche Regel für den Block verantwortlich ist.

Ähm.... Name-Label "Default deny / state violation rule"... schaut man dann in die Liste der Firewall-Regeln, findet sich dort auf Platz 2 eine Regeln mit welcher Beschreibung?

Ich weiss jetzt nicht, wie es bei Deiner Firewall so läuft, aber die Regeln werden normalerweise von oben nach unten abgearbeitet, frei nach dem Motto: Erste Regel die passt wird genutzt, Rest wird ignoriert. <einen kurzen Augenblick später...> Schau mal bei dem Screenshot mit Deinen Firewall-Regeln ganz unten, da steht etwas zu der besagten Thematik. Für mich sieht das erstmal so aus, als wäre es egal was Du machst, das wird so nicht funktionieren....

Variante a) Regeln von oben nach unten abarbeiten, was zuerst "passt" wird genutzt und da steht dann direkt sowas wie "egal was, schmeiss alles weg"....mh... nicht gut.
Variante b) Nur nutzen, wenn nichts anderes passt, auch irgendwie eher "naja"...

Mal ein genereller Tip (für sämtliche Firewalls (und auch andere Dinge))... Lass die Finger von irgendwelchen Dingen, die "automagisch" irgendwelche "Dinge" tun, zwar musst Du Dich dann intensiver damit auseinander setzen, aber lernst auch wesentlich mehr (und das Verständnis dafür wächst).

Ansonsten mal zum generellen Konzeption von Firewall-Regeln (auch das gilt generell und ist nicht auf einen Hersteller/ein Produkt beschränkt)...:

1) Anti-Lockout (Regel um sich selbst nicht auszusperren)
2) "interne" Regeln (z.B. lokales Netz A darf via HTTP in Netz B + Netz B darf via SSH in Netz A, etc.)
3) Alles interne verbieten (RCF1918 <-> RF1918 verbieten, da kannst Du Dir z.B. Netz-"Gruppen" für anlegen)

Soweit wäre der interne Teil jetzt schon mal durch, es folgt der externe:

4) Intern nach "Any" erlauben (Internetzugriff, etc., durch die Regel bei Punkt 3 wurde jetzt schon zuvor ausgeschlossen, dass interne Clients einfach in andere interne Netze dürfen, somit bleibt nur noch der Weg ins "Internet". Allerdings wurde mir der Regel unter 3 z.B. auch der Zugriff auf "vorgelagerte" Netze direkt unterbunden (bei Dir z.B. "WAN ist 192.168.1.1 (ASUS RT-AX88U)").

5) Dinge für eingehende Verbindungen von "extern" (z.B. für irgendwelche Freigaben, etc. meist in Kombi mit DNAT-Regeln (Portfreigaben))

6) Clean-Up-Rule (alles verbieten, was vorher nicht aufgeführt wurde)

Punkt 5 trifft bei Dir ggf. auch garnicht zu, kannst Du ggf. also auch erstmal ignorieren. Manche sagen auch, dass man sich den Unsinn mit Punkt 6 auch sparen kann, weil Firewalls meist sowieso hingehen und alles verbieten, was nicht vorher erlaubt wurde, aber dieses "Konstrukt" hilft dabei den Überblick zu bewahren (Regeln von "oben nach unten", i.d.R. gilt eben: was zuerst kommt wird genutzt, Rest interessiert nicht mehr) und da gibt es auch kein wenn und aber (und keine Automatismen im Hintergrund)

 

[blurrrr]

Kleiner Nachtrag: Kannst "kurzzeitig"(!) auch mal die ein oder andere Regel einfach nur "deaktivieren" zum testen (Regel aus, testen, Regel ein)

 

[blurrrr]

Zweiter kleiner Nachtrag: Da derzeit fast alles bei Dir läuft und ich irgendwo was von "WG" gelesen habe: Bitte fang jetzt nicht an und schmeiss alle Regeln über den Haufen, das machst Du mal in einer ruhigen Minute (ggf. mit Testsystem), bevor die WG-Mitglieder Dir richtig Stress machen, weil's Internet nicht mehr funktioniert

 

[the other]

Moinsen,
ich habe auch ganz viel "WG" gelesen, denke aber es ist WireGuard (WG) gemeint...
Das schmälert aber nicht deine Aussage @blurrrr , denn "mal schnell schnell an der Firewall rumspielen" führt meistens zur doppelten Menge an zeitlichem Aufwand. Also: keep calm, have a cup of tea and take time to set your ruleset!

OPNsense arbeitet nach dem gleichen Prinzip wie von @blurrrr beschrieben:
Reihenfolge beachten (Top > Down), first match wins, andere Regeln werden dann nicht mehr bearbeitet...der Klassiker also.
ANDERS sieht es dagegen mit den Floating rules us. Zumindest für die PFsense wird oft empfohlen, diese spezielle Art der Regel nur dann zu nutzen, wenn a) deren Arbeitsweise WIRKLICH verstanden wurde und b) wenn es denn sein muss.

Daher (wenn dann die Tasse Tee neben dir steht) vielleicht mal überlegen, ob du dieses Floatingrules mal deaktivierst (musste ja nicht gleich entfernen) und statt dessen für die jeweiligen Interfaces die Regeln gesondert anlegst.

Zum Thema IPv6: nutzt du denn IPv6 überhaupt oder ist das einfach nur irgendwie "aktiviert"? Wenn keine Nutzung, schmeiß es raus (unter Interfaces zB oder auch Globalen Settings (bei pfsense, müsste bei OPNsense aber ähnlich sein).

Da ich selber von Wireguard null Ahnung habe, schweige ich ansonsten mal besser...

Und: ich persönlich verzichte gerne auf ein "Sie" und bleibe beim "du"...

 

[itsed]

Vielen Dank. Wird gemacht. Ich habe zumindest immer eine "Snapshot" der OPNSense, welche bisher fleißig genutzt wird
Es gibt auch ein kleinen Fortschritt. wget xzy über https funktioniert. Jedoch wget -s und ookla speedtest nicht. Woran kann das liegen? Ich verstehe das nicht.

 

[blurrrr]

"-s"? Ich kenne nur "-S" und da geht es auch nur um die Ausgabe der Header-Informationen (Web/FTP). Bzgl. Speedtest gibt es ein Paket namens "speedtest-cli", meinst Du das, oder sprechen wir von etwas anderem?

Interessant wäre jetzt auch zu wissen, was genau Du gemacht hast, dass die HTTPS-Verbindungen jetzt funktionieren