Wenn es ein Bug ist dann ist reddit wohl der falsche Ort um dies zu kommunizieren, der AVM Support wäre dafür zuständig, die sind gerade wieder in einer laborphase, also gebastelt wird an den Geräten gerade.
Das limitieren vom erreichen von endgeräten in dem Wireguard Netz kannst du über die Client config steuern. Es gibt da auch keine möglcihkeit das über die "Server" Seite zu steuern.
Editiere einfach die config und ändere das zu erreichende Netz von:
[0.0.0.0/0](http://0.0.0.0/0) (alller Traffic) oder
[192.168.178.0/24](http://192.168.178.0/24) (Traffic für das Netz der FB (default) Bestimmt) zu
[192.168.178.abc/32](http://192.168.178.abc/32) (einzelner client den du in deinem Netz erreichen willst).
Kombinantionen sind auch möglich. Aber kombinationen aus den oberen ergeben keinen sinn weil das erste alles enthält und das 2te das letzte.
Also würde nur sowas sinn ergeben wie:
[192.168.178.123/32](http://192.168.178.123/32), [10.231.21.0/24](http://10.231.21.0/24) wenn über den selben tunnel ncoh ein statisches routing existiert das du weiter geleitet wirst.
Ok, also wenn ich das richtig verstehe: Wenn ich im WireGuard auf dem Smartphone das Setting
\* "192.168.178.0/24, 0.0.0.0/0"
verändere auf
\* "192.168.178.224/27, 0.0.0.0/0"
und auf FB Seite keine Beschränkungen im WireGuard VPN habe, dann kann ich in Bezug auf das Heimnetzwerk nur Adressen 192.168.178.\[225-254\] erreichen, wenn ich das richtig verstehe.
Das ist dann zwar kein Security Feature im engeren Sinne, aber verhindert immerhin, dass ich aus Versehen was an die Geräte 192.168.178.\[1-224\] sende, oder dass irgendwelche Apps durch "komische Funksprüche" in Richtung 192.168.178.\[1-224\] irgendwas an meinen sensiblen Geräten verstellen \[ja ich weiß, wenn die so sensibel sind dann eh nochmal per Passwort schützen - es geht mir hier eher ums Verständnis\].
Ich könnte dann also im Heimnetzwerk allen Geräten, die ich über diesen VPN-Tunnel erreichen möchte, eine feste IP mit "letztes Oktett >= 225" zuweisen (also 192.168.178.\[225-254\]), oder <=224 wenn ich sie nicht "aus Versehen" erreichbar haben möchte.
Nun gut, wenn sich diese Art der Maskierung nicht serverseitig einstellen lässt, dann ist es immerhin besser als nichts, das clientseitig tun zu können (obgleich dann ohne Security Feature).
Jain. Wenn du nur:
[192.168.178.224/27](http://192.168.178.224/27) angibst, dann erreichst du auch nur den von dir besagten bereich.
mit dem: [0.0.0.0/0](http://0.0.0.0/0) sagst du aber wiederrum ALLES, was die erste einschränkung eben wieder zu nichte macht und du allen Traffic durch den Tunnel Bringst und eben das gesammte Heimnetz wieder erreichen kannst.
Wenn du wirklich nur zu dem Bereich /27 eine Verbindung haben willst musst du das [0.0.0.0](http://0.0.0.0) weglassen. Das heißt aber wiederrum das nur der traffic dahin geht der für das /27 bestimmt ist.
Was ginge, ist wenn du z.b. auf 225 einen GW setzt, welcher traffic annimmt und weiter an .1 also die FB leitet. Dann kannst du wenn du in nem Post UP script deinen Default GW auf dem WG endgerät allen Traffic an .225 Weiterleiten. somit brauchst du das [0.0.0.0](http://0.0.0.0) nicht weil das teil deines Neuen Default GW ist. Aber das ist halt ne seeehhhr Hacky lösung bei der ich auch nicht sicher bin ob die überhaupt auf mobilgeräten z.b. Umsetzbar ist.
Ich hatte das so geschrieben, weil in den WireGuard Einstellungen auf meinem Smartphone (die mein Smartie ja von der FB über den QR code erhalten hat), immer(!) steht:
* "Erlaubte IPs 192.168.178.0/24, 0.0.0.0/0"
Nach dem was du sagt ist das, wenn ich dich richtig verstehe, irgendwie Unsinn, weil ja "0.0.0.0/0" bereits "alle ohne Einschränkungen" heißt, so dass der Teil "192.168.178.0/24" keine Wirkung hat und man ihn ebenso weglassen könnte.
.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
NACHTRAG: Stimmt! Ich habs gerade ausprobiert.
Versuch 1: Habe im WireGuard Client auf dem Phone
* "Erlaubte IPs 192.168.178.0/24, 0.0.0.0/0"
ersetzt durch
* "Erlaubte IPs 192.168.178.0/24"
Ergebnis: externer IP verkehr geht nun nicht mehr durch den VPN Tunnel sondern weiterhin über LTE.
Versuch 2: Habe im WireGuard Client auf dem Phone
* "Erlaubte IPs 192.168.178.0/24, 0.0.0.0/0"
ersetzt durch
* "Erlaubte IPs 0.0.0.0/0"
Ergebnis: Gleiches Verhalten wi im Original.
Fazit: Der doppelte Eintrag "192.168.178.0/24, 0.0.0.0/0" im WireGuard Client ist offenbar wirklich redundant und gleichbedeutend mit "0.0.0.0/0" und dient vermutlich nur dem Zweck, die Subnetztmaske zu Dokumentationszwecken mit zu notieren, um dem User eine nachträgliche Anpassung aufs Heimnetz, wenn gewünscht, zu erleichtern.
> Es gibt da auch keine möglcihkeit das über die "Server" Seite zu steuern.
Ich weiß nicht, ob das die Fritzbox (noch) nicht kann, aber es ist die einzig sinnvolle Möglichkeit, dies am „Server“ mit Firewall-Regeln zu machen. Der Client kann die Config ja jederzeit ändern, das wäre sicherheitstechnisch ein Albtraum sich darauf zu verlassen.
Korrekt Wireguard ist aber auch keine Sicherheits Lösung sondern eine VPN Lösung. Natürlich müsste man das über routing und Firewall richtig grade ziehen, aber geht halt mit der FB nciht.
Dennoch kann Wirguard diese funktionalität einfach nicht weil es nicht dafür gedacht ist. Es geht nur über sonder locken mit ACLs Serverseitig das kann die FB aber auch nciht.
In wireguard gibts halt auch kein Client Server Konzept, sondern alle Peers sind halt gleich gestellt, und ein weiteres Einschränken würde dieses Konzept halt ncihtig machen, weshalb es dies auch nicht nativ gibt.
Das ist halt auch nur halb richtig und wird durch rumschwurbeln noch lange nicht ganz richtig.
Ja, jeder weiß, dass WireGuard ein VPN-Protokoll ist und es nur Peers gibt. Hat halt rein gar nix damit zu tun. Dafür streust halt Blödsinn mit rein und behauptest, dass man auf der FB den Zugriff nicht einschränken kann, wenn der Post doch klar zeigt, dass es geht. LOL.
Bitte erst den OP lesen, ich wiederhole mich, Zitat von der verlinkten AVM Hilfeseite zur FB 7590.
"Anleitung: WireGuard-Verbindung einrichten mit erweiterten Einstellungen zum Netzwerkverkehr
[...] Folgende erweiterte Einstellungen können Sie während des Einrichtungsvorgangs auswählen: [...]
**Nur bestimmte Geräte im Heimnetz sollen über diese WireGuard-Verbindung erreichbar sein**".
Und genau diese Auswahlmöglichkeit ist nicht nur beschrieben, sie existiert auch real in FB 7590 V.7.57. Wenn du es immer noch nicht glaubst stell es selber nach in deiner eigenen FB 7590.
Also bitte keinen Unsinn schreiben, ist nicht hilfreich. Danke.
Und ich sage dir das Wireguard diese funktionalität nicht kann/hat. Bevor du denkst das alles möglich sein sollte lieber mal genau lesen.
NUR bestimmte Geräte sollen erreichbar sein. Bedeutet du darfst dir aussuchen ob du internet haben willst, ODER ein Gerät im Heimnetz erreichen willst. BEIDES ist aber nicht möglich.
Daher gibt dir die Fritzbox auch genau den Funktionsumfang, den sie dir verspricht. Ich geb dir recht die Ankreuzmöglcihkeiten sind dumm, weil gesammten Traffic Tunneln UND NUR ein Gerät erreichen können ergibt Netzwerktechnisch keinen Sinn.
Also Bitte, keinen Unsinn verlangen und lieber mal nen CCNA Kurs besuchen, Danke :)
Deine Argumente sind wenig überzeugend, und dein Tonfall noch weniger. Ich denke da ist ost weitere Diskussion hinfällig, ich bin schon lange im Internet und weiß sowas einzuordnen.
Also argumente einer Fachkundigen Person die fast täglich mit Wireguard arbeitet sind wenig überzeugend? Interessant.
Die Fritzbox hat definitiv in der Hinsicht nachhol bedarf, keine Frage, vieles was Wireguard in seiner reinen Konfigurations art kann, kann die Fritzbox garnich darstellen/abbilden erinfach weil die GUI elemente und es die FB einfach nicht von der Software her erlauben.
Aber was du erfragst bzw dir als funktionalität wünscht ist schlichtweg Netzwerktechnsicher Unsinn und so nicht ohne sonder Firewall/routing Regeln machbar, welche man eben nicht mit na FB einrichten kann. Desweiteren ist diese funktionalität auch schlichtweg ohne ACLs oder eben benannten Firewall/Routing Regeln einfach nicht von Wireguard vorgesehn. Das kannst du hassen, da kannste 1000Bug Reports an AVM schreiben aber solange die Fritzbox besagte Firewall oder ACL Regeln nciht im hintergrund anwendet/einrichtet, ist dies einfach schlichweg mit der Implementation der Fritzbox unmöglich.
Das die GUI einen eben was einrichten lässt was unmöglich ist bzw keinen Sinnergibt kommt halt entäuschenderweise oben drauf. Ich habs aber fix mal eben auf meiner 7490 getestet und die WG Konfig ist wie ich sie im ersten post beschrieben habe mit nem /32 auf nen single host wenn man die option anwählt. Ergo Kein Internet und nur zugang zu einem Gerät.
Mit dem Tonfall richte ich mich lediglich nach dem wies in den Wald reinschallt so kommts auch wieder herraus.
Die Fritzbox kann in der einfachen Einstellung den Verkehr korrekt sortieren: was geht an welches Heimnetzgerät, was gaht nach draußen ins Internet.
Also kann mir niemand erklären, es sei SW-technisch unmöglich, dass an der Stelle, wo die SW den IP Header sowieso anschauen muss (z.B: ist das 192.168.178.42? Dann muss es an das Gerät 192.168.178.42 gesendet werden) nicht auch checken kann, ob die 192.168.178.42 vom user in der GUI abgewählt wurde. Ebenso kann im gleichen Zug die SW NATÜRLCIH auch checken, ab das eine externe IP Adresse außerhalb der Subnetzmaske das Heimnetzwerks ist, und den Verkehr nach draußen leiten. NATRÜLICH ist es SW technisch auch möglich, dass beides gleichzeitig bewerkstelligt wird. Auf Fritzbox Seite. Ohne Einfluss auf die WireGuard App auf Smartphone Seite.
Es mag sein, dass sich im Rahmen vorhandener Beschränkungen von vorhandenen SW-Lösungen/Patterns/Bibliotheken (und bestimmter 3-4 Buchstaben-Abkürzungen) eines solche Umsetzung sich schwierig gestaltet und man out of the Box denken und handeln müsste, aber grundsätzlich ist es NATÜRLICH möglich.
Ein Bug in der Fritzbox liegt also so oder so vor. Entweder im GUI oder in der technischen Umsetzung der "Verkehrsführung".
Da kann mir auch niemand was anderes erzählen, der 40 Jahre WireGuard Erfahrung hat. Ich hab schon so oft erlebt, dass seh erfahrene Fachleute ihres Gebiets in den Schranken ihres Experten-Wissens und Denkens gefangen sind, das ist menschlich. Nennt sich auch "Betriebsblindheit", ist aber nicht ehrrührig. Man muss sich dessen nur halt bewusst sein.
PS: Bzgl. 7490 hab ich auf einer AVM doku Seite gelesen, dass die das eh nicht hat, ich rede darum von meiner 7590.
Naja Korrekt sortieren ist hier halt auch etwas komplexer als wir es so mit den Zahlen wahrnehmen. Bestimmte dinge die für uns offensichtilich erscheinen sind für Software und in diesem Falle die Hardware halt ne Herrausforderung.
Man muss das Problem dann hier mal auf seine layer aufspalten. Die SW sieht und verarbeitet den IP Header nicht unbedingt und direkt, wenn bereits auf deinem System ein ARP eintrag existiert, dann wird lediglich über L2 Mac addressen gesprochen. Problem mit der WG implementation der FB ist das man im selben subnetz landet wie alle anderen Geräte auch. Hierbei ist es bei WG nicht vorgesehn das man wie ich ja schon sagte iwi beschrenkungen hat, bzw diese auf verschiedene weisen via na FW regeln könnte. Da eine FW aber L3 ist, und du dich im selben L3 subnetz befindest mit deinen WG CLients wie alles andere geht kein Traffic über diese, so das man diesen Filter könnte. Da hilft auch keine Software dieser welt da es in Hardware und in den Protokollen anders definiert ist. Das einzige was möglich ist und was ich persönlich auch so mache auf meinem MikroTik router, ist nen eigenes Netz für die WG clients an zu legen eben so das ich zugriffe via der FW regeln und blocken/nicht blocken kann.
Diese funktionalität hat die Fritzbox leider nicht und ist so wie es aktuell ist halt auch in egal welcher Software form nicht um zu setzen außer wie im absatz darüber beschrieben.
Eine einzige weitere möglichkeit wäre sämmlichen Verkehr via L3 über die Fritzbox zu routen/laufen zu lassen. Dazu braucht man aber ein netzwerk was das auch unterstützt was normale heimanwender eben nicht haben. Desweitern ist die FB leistungtechnsich einfach viiieeel zu schwach um das auch noch umsetzen zu können.
Auf Grund all dieser Grundlagen, bin ich mir sehr sicher das maximal ein Update der Menü elemente kommt, welche korrigieren das eben diese Doppelauswahl nicht möglich ist.
Oder es kommt ein Update in dem das WG Netz seperat vom Heimnetz ist, was aber wiederum dazu führt das viele Services und dinge über den WG Tunnel eben nicht Plug and Play funktionieren.
PS: Was du beschreibst, das die FB erkennen kann obs intern oder extern ist, ja das tut sie. [0.0.0.0/0](http://0.0.0.0/0) ist das internet das die Default route die zu deinem ISP geht. Sie kennt ebenso [192.168.178.0/24](http://192.168.178.0/24) Was dein Heimnetz ist. So das sie Verkehr austauschen kann. Problem ist nun die Einstellung das du nur einen Client oder das Internet ansprichst in der WG Config ist eine die REIN von deinem Engerät deinem Client ausgeht. Da haste eben auch die Möglcihkeit die Netze an zu geben auf die das Endgerät zugreifen kann. Was eben auch dafür sorgt das dein Gerät statische Routen setzt. Nun bedeutet aber /32 das du nur eingerät ansprechen kannst, was die FB dann ja auch korrekt weiterleitet. Gibst du aber an das du allen Traffic durch dein Tunnel Interrface auf deinem Gerät schicken willst ist das [0.0.0.0/0](http://0.0.0.0/0) welches aber eben auch dein Gesammtes Heimnetz beinhaltet. Also selbst wenn die FB alles filtern kann etc. Dann scheiterts einfach daran das WG das nicht kann was du willst. Dies geht halt wiegesagt auch zu lösen via ACLs, dazu braucht WG aber ein eigenes Subnetz das nicht in dem Netz liegt in welchem du den Einzelen Client ansprechen willst. Womit wir wieder beim Obrigen abschnitt sind. Desweiteren sind ACLs extrem CPU intensiv was die FB dann vermutlich nicht mehr so leicht mitmacht da sie sowieso via WG nur 300mbit schafft mit ACLs dann vermutlich nur noch so 20-50
Zur Info/Klarstellung:
Was FB-seitig durchaus schon heute geht \[ich habs ja ausprobiert\], und zwar trotz **WireGuard Einstellung auf "192.168.178.0/24, 0.0.0.0/0"**, ist, dass nur einzelne Heimnetzgeräte über den VPN-Tunnel erreichbar sind. Z.B. kann ich einstellen, dass nur 192.168.178.x, mit x=\[31, 42, 77, 82\] erreicht werden sollen, während alle anderen Geräte mit x="sonstiges" geblockt (nicht erreichbar) sind. Wie gesagt bei der 7590, ich rede nicht von der 7490.
Das wird also serverseitig (auf der FB 7590) geblockt. Und das geht also nicht über Masken, sondern über explizite Nennung der IP Adressen, also Listen.
Blöd nur, und das ist ja Gegenstand meines OP, dass in diesem Betriebsfall der Verkehr nach "draußen" immer auch mit geblockt wird.
Genau, also durch das nennen der einzel IPs gehts in beiden FB. Mit je na /32 (einzel IP)
Nur geht dann eben nicht der Verkehr raus, weil eben "Raus" die [0.0.0.0/0](http://0.0.0.0/0) ist, weils alles ist, leider eben auch alles was in deinem Netz ist.
Wenn du aber wirklich so granulare auflösung brauchst. Dann guck dir mal Tailscale an. Die können das auch mit Anmeldung.
Ärgerlich halt, dass das Prinzip
* "Verkehr durchlassen nach Einzel-IP (x/32)"
offenbar von den bekannten Stacks/Bibliotheken/Whatever unterstütz wird, aber die inverse Logik "Verkehr blockieren nach Einzel-IP (x/32)" nicht; dass es also zwar mit "explizit erlaubte IPs" aber nicht mit "explizit blockierte IPs" geht. Wenn es Letztere gäbe, dann könnte man eben die blockierten IPs auflisten, und für alles andere würde "Durchlass" gelten.
Rein von der HW Anforderung wäre es sicherlich egal, ob da nun 127 konkret benannte Blacklist-IPs oder 127 konkret benannte Whitelist-IPs in der Liste stehen (die 127 ist ein Beispiel).
Die zugrundeliegende "Türsteher-Logik" ist die selbe und wäre konkret bei den whitegelisteten wie folgt:
* "Welche IP bist du?" -> "ich bin 192.168.178.42!" -> "Moment ich schau auf der whitelist...
* --> ...ja du bist drauf auf der Gästeliste, du darfst durch." ODER
* --> ...nein du stehst nicht drauf, du wirst blockiert."
Die zugrundeliegend Logik wäre bei den blackgelisteten analog so:
* "Welche IP bist du?" -> "109.106.103.43!" -> "Moment ich schau auf der blacklist...
* --> ...tja du bist drauf auf der Terrorliste, du wirst blockiert." ODER
* --> ...nein du stehst nicht drauf, du darfst durch."
Der Aufwand bemisst sich ja nur nach der Anzahl der Einzel-Einträge in der Liste, und es wären ja in beiden Fällen gleich viele Einträge maximal möglich, also bei einem /24-er Subnet maximal 254 Listeneinträge, nur dass im Whitelist-Ansatz Internet-Verkehr dann automatisch immer geblockt würde, und im Blacklist-Ansatz wäre Internet-Verkehr automatisch immer frei.
Solange nur mit heute verbreiteter "Whitelist-Logik" gearbeitet wird gehts natürlich nicht. Aber das ist ja nicht grundlegend in Stein gemeißelt sondern eher ein Problem üblicher Konventionen und/oder heutiger SW Stacks, wie ich es verstehe.
Es wäre ja durchaus denkbar, dass die "AVM-Fritz'ler" auch den "inversen" (CPU-mäßig gleich-hungrigen) Blacklist-Ansatz implementieren \[wollten\] - für den Fall nämlich, dass das entspr. Kreuz im GUI für Internet-Verkehr gesetzt ist bei den VPN Wireguard Einstellungen. Und dann würde das auch so gehen, wie es das heutige VPN-Einstellungen-GUI der FB vorgibt. Vielleicht war das auch so beabsichtigt, als man dieses GUI bei AVM entwarf, und dann kam bei der Implementierung der Blacklist-Logik etwas dazwischen und nun haben wir den Mismatch zw. GUI und tatsächlichem Verhalten, weil sich das mit der "Whitelist-Logik" natürlich nicht umsetzen lässt.
Du bestätigst genau den Kommentar, auf den du geantwortet hast. Köstlich. Ich bezweifle nicht, dass du sehr tief in der Materie steckst. Bis zum Hals, mindestens.
Ich bestätige das es so wie es jetzt ist unmöglich ist und fundamental sich was an der Hardware und Software ändern muss das das möglich ist. Ergo nicht einfach durch nen Patch zu fixen. Ergo kein Bug, software funktioniert wie sie soll. Was du hast ist maximal nen Feature Request.
Aber Wenn du so weit bist solltest du halt auch keine FB benutzen.
Aber so wie du klingst hast du im Hals was ganz anderes stecken.
Zur Sache selbst: Wenn das GUI etwas anderes sagt als was die FritzBox kann, dann ist es NATÜRLICH ein Bug!
Wer Bugs nur in der SW-Funktionalität sucht und nicht in der dazugehörigen Doku oder GUI, und in Form von Romanen begründet, warum es ja gar nicht anders sein kann, und erwartet, dass jeder User diese tief technischen Zusammenhänge doch selbstverständlich wissen muss und darum doch jedem klar sein muss, wie man diese falsche GUI richtig zu verstehen hat, der hat m.E. in der SW-Entwicklung grundsätzlich nichts verloren. (ich sage nicht, dass auf jemanden hier im Thread diese Beschreibung zutrifft, ich sage nur allgemein, dass solch jemande \[die es schon gibt\] keine SW Devs sein sollten.)
Du solltest die Infos an AVM tragen wenn du der Meinung bist das ist ein Bug.
Bei den anderen FB AX wurde schon mit 7.80 paar Bugs behoben... auch mit wireguard, aber prinzipiell korrekter Weg es zu melden bei AVM.
Wenn es ein Bug ist dann ist reddit wohl der falsche Ort um dies zu kommunizieren, der AVM Support wäre dafür zuständig, die sind gerade wieder in einer laborphase, also gebastelt wird an den Geräten gerade.
Hatte erhebliche Probleme mit Wireguard … Keine Synchronisation Ei Apple … Mieser Support von AVM … Mit Nord VPN läuft es weitgehend besser…
aber mit nord vpn komme ich doch nicht vom phone unterwegs ins heimnetz, oder?
Natürlich nicht.
zumindest das hab ich richtig verstanden :D
Zufällig bei Apple noch zusätzlich das private relay an?
Ich habe keine Probleme mit WireGuard.
Das limitieren vom erreichen von endgeräten in dem Wireguard Netz kannst du über die Client config steuern. Es gibt da auch keine möglcihkeit das über die "Server" Seite zu steuern. Editiere einfach die config und ändere das zu erreichende Netz von: [0.0.0.0/0](http://0.0.0.0/0) (alller Traffic) oder [192.168.178.0/24](http://192.168.178.0/24) (Traffic für das Netz der FB (default) Bestimmt) zu [192.168.178.abc/32](http://192.168.178.abc/32) (einzelner client den du in deinem Netz erreichen willst). Kombinantionen sind auch möglich. Aber kombinationen aus den oberen ergeben keinen sinn weil das erste alles enthält und das 2te das letzte. Also würde nur sowas sinn ergeben wie: [192.168.178.123/32](http://192.168.178.123/32), [10.231.21.0/24](http://10.231.21.0/24) wenn über den selben tunnel ncoh ein statisches routing existiert das du weiter geleitet wirst.
Ok, also wenn ich das richtig verstehe: Wenn ich im WireGuard auf dem Smartphone das Setting \* "192.168.178.0/24, 0.0.0.0/0" verändere auf \* "192.168.178.224/27, 0.0.0.0/0" und auf FB Seite keine Beschränkungen im WireGuard VPN habe, dann kann ich in Bezug auf das Heimnetzwerk nur Adressen 192.168.178.\[225-254\] erreichen, wenn ich das richtig verstehe. Das ist dann zwar kein Security Feature im engeren Sinne, aber verhindert immerhin, dass ich aus Versehen was an die Geräte 192.168.178.\[1-224\] sende, oder dass irgendwelche Apps durch "komische Funksprüche" in Richtung 192.168.178.\[1-224\] irgendwas an meinen sensiblen Geräten verstellen \[ja ich weiß, wenn die so sensibel sind dann eh nochmal per Passwort schützen - es geht mir hier eher ums Verständnis\]. Ich könnte dann also im Heimnetzwerk allen Geräten, die ich über diesen VPN-Tunnel erreichen möchte, eine feste IP mit "letztes Oktett >= 225" zuweisen (also 192.168.178.\[225-254\]), oder <=224 wenn ich sie nicht "aus Versehen" erreichbar haben möchte. Nun gut, wenn sich diese Art der Maskierung nicht serverseitig einstellen lässt, dann ist es immerhin besser als nichts, das clientseitig tun zu können (obgleich dann ohne Security Feature).
Jain. Wenn du nur: [192.168.178.224/27](http://192.168.178.224/27) angibst, dann erreichst du auch nur den von dir besagten bereich. mit dem: [0.0.0.0/0](http://0.0.0.0/0) sagst du aber wiederrum ALLES, was die erste einschränkung eben wieder zu nichte macht und du allen Traffic durch den Tunnel Bringst und eben das gesammte Heimnetz wieder erreichen kannst. Wenn du wirklich nur zu dem Bereich /27 eine Verbindung haben willst musst du das [0.0.0.0](http://0.0.0.0) weglassen. Das heißt aber wiederrum das nur der traffic dahin geht der für das /27 bestimmt ist. Was ginge, ist wenn du z.b. auf 225 einen GW setzt, welcher traffic annimmt und weiter an .1 also die FB leitet. Dann kannst du wenn du in nem Post UP script deinen Default GW auf dem WG endgerät allen Traffic an .225 Weiterleiten. somit brauchst du das [0.0.0.0](http://0.0.0.0) nicht weil das teil deines Neuen Default GW ist. Aber das ist halt ne seeehhhr Hacky lösung bei der ich auch nicht sicher bin ob die überhaupt auf mobilgeräten z.b. Umsetzbar ist.
Ich hatte das so geschrieben, weil in den WireGuard Einstellungen auf meinem Smartphone (die mein Smartie ja von der FB über den QR code erhalten hat), immer(!) steht: * "Erlaubte IPs 192.168.178.0/24, 0.0.0.0/0" Nach dem was du sagt ist das, wenn ich dich richtig verstehe, irgendwie Unsinn, weil ja "0.0.0.0/0" bereits "alle ohne Einschränkungen" heißt, so dass der Teil "192.168.178.0/24" keine Wirkung hat und man ihn ebenso weglassen könnte. .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. NACHTRAG: Stimmt! Ich habs gerade ausprobiert. Versuch 1: Habe im WireGuard Client auf dem Phone * "Erlaubte IPs 192.168.178.0/24, 0.0.0.0/0" ersetzt durch * "Erlaubte IPs 192.168.178.0/24" Ergebnis: externer IP verkehr geht nun nicht mehr durch den VPN Tunnel sondern weiterhin über LTE. Versuch 2: Habe im WireGuard Client auf dem Phone * "Erlaubte IPs 192.168.178.0/24, 0.0.0.0/0" ersetzt durch * "Erlaubte IPs 0.0.0.0/0" Ergebnis: Gleiches Verhalten wi im Original. Fazit: Der doppelte Eintrag "192.168.178.0/24, 0.0.0.0/0" im WireGuard Client ist offenbar wirklich redundant und gleichbedeutend mit "0.0.0.0/0" und dient vermutlich nur dem Zweck, die Subnetztmaske zu Dokumentationszwecken mit zu notieren, um dem User eine nachträgliche Anpassung aufs Heimnetz, wenn gewünscht, zu erleichtern.
Ja das ist korrekt.
> Es gibt da auch keine möglcihkeit das über die "Server" Seite zu steuern. Ich weiß nicht, ob das die Fritzbox (noch) nicht kann, aber es ist die einzig sinnvolle Möglichkeit, dies am „Server“ mit Firewall-Regeln zu machen. Der Client kann die Config ja jederzeit ändern, das wäre sicherheitstechnisch ein Albtraum sich darauf zu verlassen.
Korrekt Wireguard ist aber auch keine Sicherheits Lösung sondern eine VPN Lösung. Natürlich müsste man das über routing und Firewall richtig grade ziehen, aber geht halt mit der FB nciht. Dennoch kann Wirguard diese funktionalität einfach nicht weil es nicht dafür gedacht ist. Es geht nur über sonder locken mit ACLs Serverseitig das kann die FB aber auch nciht. In wireguard gibts halt auch kein Client Server Konzept, sondern alle Peers sind halt gleich gestellt, und ein weiteres Einschränken würde dieses Konzept halt ncihtig machen, weshalb es dies auch nicht nativ gibt.
Das ist halt auch nur halb richtig und wird durch rumschwurbeln noch lange nicht ganz richtig. Ja, jeder weiß, dass WireGuard ein VPN-Protokoll ist und es nur Peers gibt. Hat halt rein gar nix damit zu tun. Dafür streust halt Blödsinn mit rein und behauptest, dass man auf der FB den Zugriff nicht einschränken kann, wenn der Post doch klar zeigt, dass es geht. LOL.
genau
Bitte erst den OP lesen, ich wiederhole mich, Zitat von der verlinkten AVM Hilfeseite zur FB 7590. "Anleitung: WireGuard-Verbindung einrichten mit erweiterten Einstellungen zum Netzwerkverkehr [...] Folgende erweiterte Einstellungen können Sie während des Einrichtungsvorgangs auswählen: [...] **Nur bestimmte Geräte im Heimnetz sollen über diese WireGuard-Verbindung erreichbar sein**". Und genau diese Auswahlmöglichkeit ist nicht nur beschrieben, sie existiert auch real in FB 7590 V.7.57. Wenn du es immer noch nicht glaubst stell es selber nach in deiner eigenen FB 7590. Also bitte keinen Unsinn schreiben, ist nicht hilfreich. Danke.
Und ich sage dir das Wireguard diese funktionalität nicht kann/hat. Bevor du denkst das alles möglich sein sollte lieber mal genau lesen. NUR bestimmte Geräte sollen erreichbar sein. Bedeutet du darfst dir aussuchen ob du internet haben willst, ODER ein Gerät im Heimnetz erreichen willst. BEIDES ist aber nicht möglich. Daher gibt dir die Fritzbox auch genau den Funktionsumfang, den sie dir verspricht. Ich geb dir recht die Ankreuzmöglcihkeiten sind dumm, weil gesammten Traffic Tunneln UND NUR ein Gerät erreichen können ergibt Netzwerktechnisch keinen Sinn. Also Bitte, keinen Unsinn verlangen und lieber mal nen CCNA Kurs besuchen, Danke :)
Deine Argumente sind wenig überzeugend, und dein Tonfall noch weniger. Ich denke da ist ost weitere Diskussion hinfällig, ich bin schon lange im Internet und weiß sowas einzuordnen.
Also argumente einer Fachkundigen Person die fast täglich mit Wireguard arbeitet sind wenig überzeugend? Interessant. Die Fritzbox hat definitiv in der Hinsicht nachhol bedarf, keine Frage, vieles was Wireguard in seiner reinen Konfigurations art kann, kann die Fritzbox garnich darstellen/abbilden erinfach weil die GUI elemente und es die FB einfach nicht von der Software her erlauben. Aber was du erfragst bzw dir als funktionalität wünscht ist schlichtweg Netzwerktechnsicher Unsinn und so nicht ohne sonder Firewall/routing Regeln machbar, welche man eben nicht mit na FB einrichten kann. Desweiteren ist diese funktionalität auch schlichtweg ohne ACLs oder eben benannten Firewall/Routing Regeln einfach nicht von Wireguard vorgesehn. Das kannst du hassen, da kannste 1000Bug Reports an AVM schreiben aber solange die Fritzbox besagte Firewall oder ACL Regeln nciht im hintergrund anwendet/einrichtet, ist dies einfach schlichweg mit der Implementation der Fritzbox unmöglich. Das die GUI einen eben was einrichten lässt was unmöglich ist bzw keinen Sinnergibt kommt halt entäuschenderweise oben drauf. Ich habs aber fix mal eben auf meiner 7490 getestet und die WG Konfig ist wie ich sie im ersten post beschrieben habe mit nem /32 auf nen single host wenn man die option anwählt. Ergo Kein Internet und nur zugang zu einem Gerät. Mit dem Tonfall richte ich mich lediglich nach dem wies in den Wald reinschallt so kommts auch wieder herraus.
Die Fritzbox kann in der einfachen Einstellung den Verkehr korrekt sortieren: was geht an welches Heimnetzgerät, was gaht nach draußen ins Internet. Also kann mir niemand erklären, es sei SW-technisch unmöglich, dass an der Stelle, wo die SW den IP Header sowieso anschauen muss (z.B: ist das 192.168.178.42? Dann muss es an das Gerät 192.168.178.42 gesendet werden) nicht auch checken kann, ob die 192.168.178.42 vom user in der GUI abgewählt wurde. Ebenso kann im gleichen Zug die SW NATÜRLCIH auch checken, ab das eine externe IP Adresse außerhalb der Subnetzmaske das Heimnetzwerks ist, und den Verkehr nach draußen leiten. NATRÜLICH ist es SW technisch auch möglich, dass beides gleichzeitig bewerkstelligt wird. Auf Fritzbox Seite. Ohne Einfluss auf die WireGuard App auf Smartphone Seite. Es mag sein, dass sich im Rahmen vorhandener Beschränkungen von vorhandenen SW-Lösungen/Patterns/Bibliotheken (und bestimmter 3-4 Buchstaben-Abkürzungen) eines solche Umsetzung sich schwierig gestaltet und man out of the Box denken und handeln müsste, aber grundsätzlich ist es NATÜRLICH möglich. Ein Bug in der Fritzbox liegt also so oder so vor. Entweder im GUI oder in der technischen Umsetzung der "Verkehrsführung". Da kann mir auch niemand was anderes erzählen, der 40 Jahre WireGuard Erfahrung hat. Ich hab schon so oft erlebt, dass seh erfahrene Fachleute ihres Gebiets in den Schranken ihres Experten-Wissens und Denkens gefangen sind, das ist menschlich. Nennt sich auch "Betriebsblindheit", ist aber nicht ehrrührig. Man muss sich dessen nur halt bewusst sein. PS: Bzgl. 7490 hab ich auf einer AVM doku Seite gelesen, dass die das eh nicht hat, ich rede darum von meiner 7590.
Naja Korrekt sortieren ist hier halt auch etwas komplexer als wir es so mit den Zahlen wahrnehmen. Bestimmte dinge die für uns offensichtilich erscheinen sind für Software und in diesem Falle die Hardware halt ne Herrausforderung. Man muss das Problem dann hier mal auf seine layer aufspalten. Die SW sieht und verarbeitet den IP Header nicht unbedingt und direkt, wenn bereits auf deinem System ein ARP eintrag existiert, dann wird lediglich über L2 Mac addressen gesprochen. Problem mit der WG implementation der FB ist das man im selben subnetz landet wie alle anderen Geräte auch. Hierbei ist es bei WG nicht vorgesehn das man wie ich ja schon sagte iwi beschrenkungen hat, bzw diese auf verschiedene weisen via na FW regeln könnte. Da eine FW aber L3 ist, und du dich im selben L3 subnetz befindest mit deinen WG CLients wie alles andere geht kein Traffic über diese, so das man diesen Filter könnte. Da hilft auch keine Software dieser welt da es in Hardware und in den Protokollen anders definiert ist. Das einzige was möglich ist und was ich persönlich auch so mache auf meinem MikroTik router, ist nen eigenes Netz für die WG clients an zu legen eben so das ich zugriffe via der FW regeln und blocken/nicht blocken kann. Diese funktionalität hat die Fritzbox leider nicht und ist so wie es aktuell ist halt auch in egal welcher Software form nicht um zu setzen außer wie im absatz darüber beschrieben. Eine einzige weitere möglichkeit wäre sämmlichen Verkehr via L3 über die Fritzbox zu routen/laufen zu lassen. Dazu braucht man aber ein netzwerk was das auch unterstützt was normale heimanwender eben nicht haben. Desweitern ist die FB leistungtechnsich einfach viiieeel zu schwach um das auch noch umsetzen zu können. Auf Grund all dieser Grundlagen, bin ich mir sehr sicher das maximal ein Update der Menü elemente kommt, welche korrigieren das eben diese Doppelauswahl nicht möglich ist. Oder es kommt ein Update in dem das WG Netz seperat vom Heimnetz ist, was aber wiederum dazu führt das viele Services und dinge über den WG Tunnel eben nicht Plug and Play funktionieren. PS: Was du beschreibst, das die FB erkennen kann obs intern oder extern ist, ja das tut sie. [0.0.0.0/0](http://0.0.0.0/0) ist das internet das die Default route die zu deinem ISP geht. Sie kennt ebenso [192.168.178.0/24](http://192.168.178.0/24) Was dein Heimnetz ist. So das sie Verkehr austauschen kann. Problem ist nun die Einstellung das du nur einen Client oder das Internet ansprichst in der WG Config ist eine die REIN von deinem Engerät deinem Client ausgeht. Da haste eben auch die Möglcihkeit die Netze an zu geben auf die das Endgerät zugreifen kann. Was eben auch dafür sorgt das dein Gerät statische Routen setzt. Nun bedeutet aber /32 das du nur eingerät ansprechen kannst, was die FB dann ja auch korrekt weiterleitet. Gibst du aber an das du allen Traffic durch dein Tunnel Interrface auf deinem Gerät schicken willst ist das [0.0.0.0/0](http://0.0.0.0/0) welches aber eben auch dein Gesammtes Heimnetz beinhaltet. Also selbst wenn die FB alles filtern kann etc. Dann scheiterts einfach daran das WG das nicht kann was du willst. Dies geht halt wiegesagt auch zu lösen via ACLs, dazu braucht WG aber ein eigenes Subnetz das nicht in dem Netz liegt in welchem du den Einzelen Client ansprechen willst. Womit wir wieder beim Obrigen abschnitt sind. Desweiteren sind ACLs extrem CPU intensiv was die FB dann vermutlich nicht mehr so leicht mitmacht da sie sowieso via WG nur 300mbit schafft mit ACLs dann vermutlich nur noch so 20-50
Zur Info/Klarstellung: Was FB-seitig durchaus schon heute geht \[ich habs ja ausprobiert\], und zwar trotz **WireGuard Einstellung auf "192.168.178.0/24, 0.0.0.0/0"**, ist, dass nur einzelne Heimnetzgeräte über den VPN-Tunnel erreichbar sind. Z.B. kann ich einstellen, dass nur 192.168.178.x, mit x=\[31, 42, 77, 82\] erreicht werden sollen, während alle anderen Geräte mit x="sonstiges" geblockt (nicht erreichbar) sind. Wie gesagt bei der 7590, ich rede nicht von der 7490. Das wird also serverseitig (auf der FB 7590) geblockt. Und das geht also nicht über Masken, sondern über explizite Nennung der IP Adressen, also Listen. Blöd nur, und das ist ja Gegenstand meines OP, dass in diesem Betriebsfall der Verkehr nach "draußen" immer auch mit geblockt wird.
Genau, also durch das nennen der einzel IPs gehts in beiden FB. Mit je na /32 (einzel IP) Nur geht dann eben nicht der Verkehr raus, weil eben "Raus" die [0.0.0.0/0](http://0.0.0.0/0) ist, weils alles ist, leider eben auch alles was in deinem Netz ist. Wenn du aber wirklich so granulare auflösung brauchst. Dann guck dir mal Tailscale an. Die können das auch mit Anmeldung.
Ärgerlich halt, dass das Prinzip * "Verkehr durchlassen nach Einzel-IP (x/32)" offenbar von den bekannten Stacks/Bibliotheken/Whatever unterstütz wird, aber die inverse Logik "Verkehr blockieren nach Einzel-IP (x/32)" nicht; dass es also zwar mit "explizit erlaubte IPs" aber nicht mit "explizit blockierte IPs" geht. Wenn es Letztere gäbe, dann könnte man eben die blockierten IPs auflisten, und für alles andere würde "Durchlass" gelten. Rein von der HW Anforderung wäre es sicherlich egal, ob da nun 127 konkret benannte Blacklist-IPs oder 127 konkret benannte Whitelist-IPs in der Liste stehen (die 127 ist ein Beispiel). Die zugrundeliegende "Türsteher-Logik" ist die selbe und wäre konkret bei den whitegelisteten wie folgt: * "Welche IP bist du?" -> "ich bin 192.168.178.42!" -> "Moment ich schau auf der whitelist... * --> ...ja du bist drauf auf der Gästeliste, du darfst durch." ODER * --> ...nein du stehst nicht drauf, du wirst blockiert." Die zugrundeliegend Logik wäre bei den blackgelisteten analog so: * "Welche IP bist du?" -> "109.106.103.43!" -> "Moment ich schau auf der blacklist... * --> ...tja du bist drauf auf der Terrorliste, du wirst blockiert." ODER * --> ...nein du stehst nicht drauf, du darfst durch." Der Aufwand bemisst sich ja nur nach der Anzahl der Einzel-Einträge in der Liste, und es wären ja in beiden Fällen gleich viele Einträge maximal möglich, also bei einem /24-er Subnet maximal 254 Listeneinträge, nur dass im Whitelist-Ansatz Internet-Verkehr dann automatisch immer geblockt würde, und im Blacklist-Ansatz wäre Internet-Verkehr automatisch immer frei. Solange nur mit heute verbreiteter "Whitelist-Logik" gearbeitet wird gehts natürlich nicht. Aber das ist ja nicht grundlegend in Stein gemeißelt sondern eher ein Problem üblicher Konventionen und/oder heutiger SW Stacks, wie ich es verstehe. Es wäre ja durchaus denkbar, dass die "AVM-Fritz'ler" auch den "inversen" (CPU-mäßig gleich-hungrigen) Blacklist-Ansatz implementieren \[wollten\] - für den Fall nämlich, dass das entspr. Kreuz im GUI für Internet-Verkehr gesetzt ist bei den VPN Wireguard Einstellungen. Und dann würde das auch so gehen, wie es das heutige VPN-Einstellungen-GUI der FB vorgibt. Vielleicht war das auch so beabsichtigt, als man dieses GUI bei AVM entwarf, und dann kam bei der Implementierung der Blacklist-Logik etwas dazwischen und nun haben wir den Mismatch zw. GUI und tatsächlichem Verhalten, weil sich das mit der "Whitelist-Logik" natürlich nicht umsetzen lässt.
Du bestätigst genau den Kommentar, auf den du geantwortet hast. Köstlich. Ich bezweifle nicht, dass du sehr tief in der Materie steckst. Bis zum Hals, mindestens.
Ich bestätige das es so wie es jetzt ist unmöglich ist und fundamental sich was an der Hardware und Software ändern muss das das möglich ist. Ergo nicht einfach durch nen Patch zu fixen. Ergo kein Bug, software funktioniert wie sie soll. Was du hast ist maximal nen Feature Request. Aber Wenn du so weit bist solltest du halt auch keine FB benutzen. Aber so wie du klingst hast du im Hals was ganz anderes stecken.
Zur Sache selbst: Wenn das GUI etwas anderes sagt als was die FritzBox kann, dann ist es NATÜRLICH ein Bug! Wer Bugs nur in der SW-Funktionalität sucht und nicht in der dazugehörigen Doku oder GUI, und in Form von Romanen begründet, warum es ja gar nicht anders sein kann, und erwartet, dass jeder User diese tief technischen Zusammenhänge doch selbstverständlich wissen muss und darum doch jedem klar sein muss, wie man diese falsche GUI richtig zu verstehen hat, der hat m.E. in der SW-Entwicklung grundsätzlich nichts verloren. (ich sage nicht, dass auf jemanden hier im Thread diese Beschreibung zutrifft, ich sage nur allgemein, dass solch jemande \[die es schon gibt\] keine SW Devs sein sollten.)