blurrrr
Well-known member
Was genau meinst Du damit? Klar funktioniert es, wenn Quelle und Ziel im gleichen Netz sind, da sind aber auch keine Router involviert, oder wie ist das jetzt gemeint?
Test Fritzbox als Wireguard peer
- Ersteller hoitschau
- Erstellt am
was ich jetzt noch erforschen möchte ist Folgendes:
ich hab nun den Windows Client ins Fritzbox Netz gehängt.
ein curl http... auf einen Client im OpenSense Netzwerk funktioniert.
nur curl http... vom Client im OpnSense Netz zum Client im Fritzbox Netz funktioniert nicht,
Ebenso Ping, pingt der Windows Client in Richtung OpnSense Netz kommt die Antwort an
ich hab nun den Windows Client ins Fritzbox Netz gehängt.
ein curl http... auf einen Client im OpenSense Netzwerk funktioniert.
nur curl http... vom Client im OpnSense Netz zum Client im Fritzbox Netz funktioniert nicht,
Ebenso Ping, pingt der Windows Client in Richtung OpnSense Netz kommt die Antwort an
Ja hab da nur gemeint, das der cult http... Befehl grundsätzlich funktioniert, nur nicht mehr wenn das Ziel im Fritzbox Netz liegtWas genau meinst Du damit? Klar funktioniert es, wenn Quelle und Ziel im gleichen Netz sind, da sind aber auch keine Router involviert, oder wie ist das jetzt gemeint?
Zuletzt bearbeitet:
@Barungar Danke für den Hinweis, aber ich kann diese Option nirgends finden. Wo genau sollte die sein?
blurrrr
Well-known member
Wenn auf Seite der Fritzbox was schief läuft, keine Ahnung, ich hab es nicht so mit dem SOHO-Geräten (auch wenn hier auch eine Fritzbox steht, aber die macht nix, geht alles an die Firewall dahinter). Wireguard ist eh nicht so mein Thema und da das ganze auch noch - meines Wissens nach - als Labor gekennzeichnet ist bzw. nicht für alle Fritzboxen freigegeben ist... hat das für mich auch noch keine Marktreife. Mag sein, dass es irgendwo funktioniert, aber rumprügeln würde ich mich damit ehrlich gesagt nicht. Ich mache sowas auch beruflich und so ein Rumgebastel hat da keinen Platz, da müssen die Dinge funktionieren, also nutzt man auch Dinge die funktionieren (z.B. IPSec/OpenVPN)
Aber vielleicht haben @Barungar oder @tiermutter ja noch DIE Idee 
blurrrr
Well-known member
Kleiner Nachtrag: Mal ganz unabhängig von Fritzbox und *sense.. lass doch mal Mitschnitte auf Quelle und Ziel laufen und schau, wie es sich dort verhält bzw. eigentlich solltest Du das mal alles komplett mitschneiden... Quelle, Ziel, die entsprechenden Interfaces auf Fritzbox und *sense. Dann schnappste Dir eine Verbindung die nicht funktioniert und verfolgst die anhand der Timestamps einmal komplett durch inkl. Rückweg der Antwort. Irgendwas wird sich da schon finden lassen, wenn etwas nicht funktioniert 
haha genau darum hab ich die Fritzbox zum testen geholt.Wenn auf Seite der Fritzbox was schief läuft, keine Ahnung, ich hab es nicht so mit dem SOHO-Geräten (auch wenn hier auch eine Fritzbox steht, aber die macht nix, geht alles an die Firewall dahinter). Wireguard ist eh nicht so mein Thema und da das ganze auch noch - meines Wissens nach - als Labor gekennzeichnet ist bzw. nicht für alle Fritzboxen freigegeben ist... hat das für mich auch noch keine Marktreife. Mag sein, dass es irgendwo funktioniert, aber rumprügeln würde ich mich damit ehrlich gesagt nicht. Ich mache sowas auch beruflich und so ein Rumgebastel hat da keinen Platz, da müssen die Dinge funktionieren, also nutzt man auch Dinge die funktionieren (z.B. IPSec/OpenVPN)
In der nächsten Firmware 7.50 ist Wireguard offiziell im FritzOS implementiert.
Dann kann ich die Fritzbox den Kunden empfehlen.
Ich hab ja Wireguard schon eine Weile produktiv im Einsatz über die OpnSense mit den Wireguard Software Clients auf den Geräten, und sehe nur vorteile.
https://www.heise.de/ratgeber/Firmw...Betriebssystem-FritzOS-7-50-kann-7311838.html
"Wir maßen seinerzeit mit WireGuard den doppelten VPN-Durchsatz (Down/Upstream-Mittelwert 146 Mbit/s) gegenüber IPsec (70 Mbit/s)."
Ich finde das merkt man im Einsatz effektiv, kann dir das wirklich nur empfehlen.
Ausser dass ich die Einstiegshürde doch etwas höher empfunden habe, als allgemein so kommuniziert wird.
AVM hat das aber gut vereinfacht, damit kommt man glaube ich schnell zu einem guten Setup.
Nun halt noch der Versuch, 2 Netze zu verbinden, nicht nur Client zu Server.
Hast natürlich recht, war schon dran.Kleiner Nachtrag: Mal ganz unabhängig von Fritzbox und *sense.. lass doch mal Mitschnitte auf Quelle und Ziel laufen und schau, wie es sich dort verhält bzw. eigentlich solltest Du das mal alles komplett mitschneiden... Quelle, Ziel, die entsprechenden Interfaces auf Fritzbox und *sense. Dann schnappste Dir eine Verbindung die nicht funktioniert und verfolgst die anhand der Timestamps einmal komplett durch inkl. Rückweg der Antwort. Irgendwas wird sich da schon finden lassen, wenn etwas nicht funktioniert
Ich sehe im Trace auf der Opnsense, dass die Pakete nicht manipuliert werden.
OpnSense Trace
10.0.5.11 zu 192.168.0.49
192.168.0.49 zu 10.0.5.11
Fritzbox Trace
192.168.0.49 zu 192.168.1.41
10.0.5.11 zu 192.168.0.49
Die OpnSense ändert den Paketheader also nicht zu 10.0.5.1.
Die Fritzbox manipuliert die Source-IP der Pakete zu 10.0.5.11
Die Clients im OpnSense Netzwerk senden also die Antworten jeweils zum Wireguard Interface der Fritzbox 10.0.5.11.
Die Clients im Fritzbox Netzwerk antworten direkt zur Client IP, woher die Anrfrage kam, 192.168.0.49
Ok, die Wireguard Software Clients unter Windows und Android verhalten sich wie die Fritzbox,
Die Pakete werden von der IP des Wireguard Interface des Clients zugestellt.
Somit schau ich mal ob ich da bei der OpnSense was aktivieren kann.
Ich les mich grad bei IPSec noch ein.
https://doc.astlinux-project.org/userdoc:tt_ipsec_vpn_strongswan
Kannst du mir sagen ob ich per IPSec 2 Netze verbinden kann, wenn die LTE Fritzbox hinter einem Carrier NAT sitzt und nicht von aussen erreichbar ist?
Es scheint als muss die Fritzbox per Domain erreichbar sein.
Ich brauche eine Lösung bei der sich die Fritzbox inside out zu einem Server verbindet, und dann beide Netze verbunden sind.
Die Pakete werden von der IP des Wireguard Interface des Clients zugestellt.
Somit schau ich mal ob ich da bei der OpnSense was aktivieren kann.
Ich les mich grad bei IPSec noch ein.
https://doc.astlinux-project.org/userdoc:tt_ipsec_vpn_strongswan
Kannst du mir sagen ob ich per IPSec 2 Netze verbinden kann, wenn die LTE Fritzbox hinter einem Carrier NAT sitzt und nicht von aussen erreichbar ist?
Es scheint als muss die Fritzbox per Domain erreichbar sein.
Ich brauche eine Lösung bei der sich die Fritzbox inside out zu einem Server verbindet, und dann beide Netze verbunden sind.
blurrrr
Well-known member
Wenn die LTE-Fritzbox die Verbindung initiiert sollte da theoretisch nichts gegen sprechen.
? Wenn beide VPN-Gateways jeweils hinter einem NAT hängen, wird das mit IPSec eher nix (falls das gemeint war). Ansonsten halt Wireguard (k.A.), oder eben OpenVPN.
Barungar
Well-known member
Ich habe die Einstellung im FritzBox LAN-LAN VPN.
tiermutter
Well-known member
Mir fällt es schwer jetzt nachträglich durch den ganzen Thread zu blicken und mit Fritte kenne ich mich ja auch nicht aus...Aber vielleicht haben @Barungar oder @tiermutter ja noch DIE Idee
war die MTU schonmal im Gespräch und kann diese in der Konstellation angepasst werden?
Ich fahre hier für einen Windows 10 Roadwarrior mit 1395 ganz gut, 1420 (default) und 1412 (soll angeblich bestens geeignet sein) liefern hier auch keine befriedigenden Ergebnisse. Unter Android nutze ich die default MTU ohne Probleme.
tiermutter
Well-known member
Wenn aber auch eine Sense im Einsatz ist und eine Fritte für den Test angeschafft wurde, dann würde ich sagen:
Fritte verkaufen, dafür eine kleine Sense anschaffen und dann OVPN oder IPsec nutzen.
Wireguard ist zwar toll und schön, aber nur was Geschwindigkeit angeht. Ansonsten sehe ich es als eher instabiles Spielzeug, was man nur verwenden sollte, wenn man im Ernstfall ein Fallback hat (sofern das VPN wichtig ist).
Fritte verkaufen, dafür eine kleine Sense anschaffen und dann OVPN oder IPsec nutzen.
Wireguard ist zwar toll und schön, aber nur was Geschwindigkeit angeht. Ansonsten sehe ich es als eher instabiles Spielzeug, was man nur verwenden sollte, wenn man im Ernstfall ein Fallback hat (sofern das VPN wichtig ist).
Barungar
Well-known member
Nur als Anmerkung am Rand. Ich glaube schon der PING wollte nicht. Da ist die MTU aber ziemlich unerheblich, da die meisten Systeme PINGs in der Größenordnung 56 - 64 Byte versenden. Hier wäre also erst eine MTU im Bereich von 50-100 Byte kritisch.
tiermutter
Well-known member
Ah ok... wie gesagt... habe jetzt nicht den ganzen Thread gelesen... gibt es eine Zusammenfassung?
@tiermutter Das find ich schon lange interessant.
Die MTU wird im Zusammenhang mit Wireguard oft erwähnt, hab aber bis jetzt noch nie einen Grund gefunden die zu ändern. Leider findet sich in den verschiedenen Foren viele falsche Infos bezüglich Wireguard.
Und schlussendlich brauche ich ein Gerät, dass ich Kunden empfehlen kann, und nicht selber Supporten muss.
Da Fallen halt Lösungen wir Rasperrys und selber installierte OpnSense raus.
In meinem Szenario ist ein fertiger Router mit VPN die beste Lösung.
Es muss ja auch nicht zwingend Wireguard sein, aber ich nehm halt neue Dinge gerne mit aktueller Technik in Betrieb.
Und nochmals ein Hinweis meinerseits, es scheint ja da sehr viele Wireguard Skeptiker zu geben.
Ich kenne niemanden der nach der Inbetriebnahme von Wireguard wieder zurück zu einer anderen VPN Technik gewechselt hat.
@blurrrr Ja die OpnSens hat ne fixe IP, nur die Fritzbox ist hinter einem Carrier NAT. Ich werd das somit nächstens mal testweise in Betrieb nehmen.
@Barungar Da scheint die Laborfirmware die Menüs anders zu bezeichnen. Du meinst also in den Netzwerk-Einstellungen, nicht in den WAN-Einstellungen bei den VPN Settings?
Muss das am Abend nochmals anschauen, hab grad keinen Zugriff auf die Fritzbox.
Du hast nicht per Zufall einen Screenshot des Menüs zur Hand?
Und die Zusammenfassung dieses Treads ist recht kurz,tracen und analysieren ist wie immer besser als Vermutungen anzustellen.
Die OpnSense ändert im Paketheader die Source-IP also nicht zu 10.0.5.1.
Die Fritzbox manipuliert die Source-IP der Pakete zu 10.0.5.11
Die Clients im OpnSense Netzwerk senden also die Antworten jeweils zum Wireguard Interface der Fritzbox 10.0.5.11.
Die Clients im Fritzbox Netzwerk antworten direkt zur Client IP, woher die Anrfrage kam, 192.168.0.49
Ich werd nun schauen ob ich die OpnSense dazu bringen kann, die Source-IP aud die IP des Wireguard Interface 10.0.5.1 anzupassen.
Die MTU wird im Zusammenhang mit Wireguard oft erwähnt, hab aber bis jetzt noch nie einen Grund gefunden die zu ändern. Leider findet sich in den verschiedenen Foren viele falsche Infos bezüglich Wireguard.
Und schlussendlich brauche ich ein Gerät, dass ich Kunden empfehlen kann, und nicht selber Supporten muss.
Da Fallen halt Lösungen wir Rasperrys und selber installierte OpnSense raus.
In meinem Szenario ist ein fertiger Router mit VPN die beste Lösung.
Es muss ja auch nicht zwingend Wireguard sein, aber ich nehm halt neue Dinge gerne mit aktueller Technik in Betrieb.
Und nochmals ein Hinweis meinerseits, es scheint ja da sehr viele Wireguard Skeptiker zu geben.
Ich kenne niemanden der nach der Inbetriebnahme von Wireguard wieder zurück zu einer anderen VPN Technik gewechselt hat.
@blurrrr Ja die OpnSens hat ne fixe IP, nur die Fritzbox ist hinter einem Carrier NAT. Ich werd das somit nächstens mal testweise in Betrieb nehmen.
@Barungar Da scheint die Laborfirmware die Menüs anders zu bezeichnen. Du meinst also in den Netzwerk-Einstellungen, nicht in den WAN-Einstellungen bei den VPN Settings?
Muss das am Abend nochmals anschauen, hab grad keinen Zugriff auf die Fritzbox.
Du hast nicht per Zufall einen Screenshot des Menüs zur Hand?
Und die Zusammenfassung dieses Treads ist recht kurz,tracen und analysieren ist wie immer besser als Vermutungen anzustellen.
Die OpnSense ändert im Paketheader die Source-IP also nicht zu 10.0.5.1.
Die Fritzbox manipuliert die Source-IP der Pakete zu 10.0.5.11
Die Clients im OpnSense Netzwerk senden also die Antworten jeweils zum Wireguard Interface der Fritzbox 10.0.5.11.
Die Clients im Fritzbox Netzwerk antworten direkt zur Client IP, woher die Anrfrage kam, 192.168.0.49
Ich werd nun schauen ob ich die OpnSense dazu bringen kann, die Source-IP aud die IP des Wireguard Interface 10.0.5.1 anzupassen.
tiermutter
Well-known member
Ich arbeite quasi täglich mit Wireguard. Quasi täglich funktioniert der Tunnel (insbesondere unter Win10) dann zeitweise nicht.
Was das Debuggen angeht ist Wireguard ja auch so ein Blödmann, der sagt ja quasi immer dass die Verbindung besteht, selbst dann wenn das gar nicht möglich ist. In den (Client-)Logs habe ich auch noch nie etwas wirklich Brauchbares gefunden. Demnach wechsle ich immer wieder zumindest zeitweise zu OVPN, welches ich als Fallback aktiv habe.
Der Speed ist halt geil, nur deswegen nutze ich es, ansonsten ist WG aus diversen Gründen wirklich Kasperkram. Hier stehen sicherlich noch weitere 10 Meinungen zu WG, falls von Interesse
https://forum.heimnetz.de/threads/wireguard-vs-openvpn.202/Das ist schon komisch, ich tunnle allen Traffic meines Smartphone und meines Laptops nach Hause, wechsle regelmässig zwischen WLAN und Mobilfunk und hatte noch nie Probleme mit dem Tunneln.
Es funktioniert sogar der Tunnel des Laptops wenn der Laptop über den Smartphone Hotspot verbunden ist, wenn auch das Smartphone per Tunnel mit der Firewall verbunden ist. Das find ich schon echt gut.
Und auch das unterbrechungsfreie streaming beim Netzwechsel begeistert micht, das hatte ich so noch mit keiner anderen VPN Lösung.
Das einzig mühsame war, dass nirgends dokumentiert ist, dass man im Windows-Client zusätzlich zu 0.0.0.0/24 noch das gegenüberliegende Netz eintragen muss.
Das ist unter Android und Linux nicht nötig.
Aber ja, da wird jetzt sicher noch einiges gehen, wenn Hersteller wie AVM das in die Produkte implementieren.
Ich bin jedenfalls sicher, dass dies die Zukunft ist.
Es funktioniert sogar der Tunnel des Laptops wenn der Laptop über den Smartphone Hotspot verbunden ist, wenn auch das Smartphone per Tunnel mit der Firewall verbunden ist. Das find ich schon echt gut.
Und auch das unterbrechungsfreie streaming beim Netzwechsel begeistert micht, das hatte ich so noch mit keiner anderen VPN Lösung.
Das einzig mühsame war, dass nirgends dokumentiert ist, dass man im Windows-Client zusätzlich zu 0.0.0.0/24 noch das gegenüberliegende Netz eintragen muss.
Das ist unter Android und Linux nicht nötig.
Aber ja, da wird jetzt sicher noch einiges gehen, wenn Hersteller wie AVM das in die Produkte implementieren.
Ich bin jedenfalls sicher, dass dies die Zukunft ist.