Hat jemand eine Idee, wie man den Wert von "dont_filter_netbios" direkt in der Box ändern kann? Eine Änderung der gesicherten Konfiguration ist nicht möglich. Beim Versuch die geänderte Datei wieder zu laden bricht mit der Meldung ab, dass diese Datei kurrupt sei.
[Problem] Wireguard-VPN Zugriff SMB nicht erfolgreich
- Ersteller gantim
- Erstellt am
Mit Hilfe von Tools, die die richtige Checksum in die Datei schreiben, sollte es möglich sein, die geänderte Konfiguration einzuspielen. Diese Tools gibt es, habe es aber noch nicht getestet.
In dem Labor-Update für die 7530AX, das gerade kam, wurde das Problem nicht behoben. Die Verbindung funktioniert auch nach Löschen und neu Anlegen nicht für SMB und enthält weiterhin den Netbios-Filter.
Ich dachte, Default für diesen Wert ändern, einchecken, in ein neues Build integrieren könnte bei einer nicht betriebskritischen Änderung auch mal schnell gehen. Sollte auch keine Kritik sein (so gerne ich mittlerweile AVM auch bashe, weil mir die diversen Unzulänglichkeiten der Fritzboxen auf den Geist gehen), sondern nur feststellen, dass in diesem Build nichts anders ist.
Du dachtest, testen braucht man nicht, das passiert sowieso immer erst beim Kunden?
Wer sagt, dass das ungetestet ist?Du dachtest, testen braucht man nicht, das passiert sowieso immer erst beim Kunden?
Wenn man automatisierte Tests hat, die nach einem Build laufen, dann ist eine vollständige Funktionsprüfung sicher im Rahmen des Builds in weniger als einer Stunde erledigt. Wenn der Build da ist, ist er (für Labor ausreichend) getestet, bevor er als Binary auf einen entsprechenden internen Server für binäre Releases bereitgestellt wird. Ob AVM sowas hat/macht, weiß ich natürlich nicht.
Edit: Ich verstehe nicht, wieso meine kurze, an sich kritiklose gemeinte Botschaft "Ich habe getestet: Es hat sich an der Stelle nichts geändert." gleich prinzipielle Diskussionen auslösen muss, ob man das testen/erwähnen braucht und wie AVM testet oder auch nicht, und ob derjenige, der Bugs einführt/behebt unbedingt der gleiche ist, der den Bug entgegennimmt, ob nicht gemeldete Bugs bereits behoben sein könnten (habe es extra nicht erwähnt) etc. und finde, die Diskussion führt einfach zu weit. Es war keine Erwartungshaltung, ich wollte nur wissen, was Sache ist.
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,619
- Punkte für Reaktionen
- 1,947
- Punkte
- 113
Vielleicht geht man auch noch mal einen Schritt zurück und überlegt, ob das überhaupt ein Bug ist? Der Wunsch, auch vom Smartphone aus per VPN auf SMB-Freigaben zugreifen zu wollen, dürfte nicht so weit verbreitet sein (von ein paar Spezialfällen mal abgesehen). Ich bin mir nicht mal sicher (das habe ich tatsächlich schon länger nicht mehr geprüft, weil ich es nicht mehr brauche), ob das nicht bei IPSec-Verbindungen mit Proxy-ARP (wo also der Client eine IP-Adresse aus dem Subnet der Box kriegt) ebenso ist und damit am Ende durchaus Absicht. Es gäbe jedenfalls auch (durchaus plausible) Gründe dafür, das im Normalfall auszufiltern … selbst wenn es bisher nicht geschehen sein mag bei WireGuard®-Verbindungen.
Erforderlich
Aktives Mitglied
- Mitglied seit
- 7 Jan 2024
- Beiträge
- 2,063
- Punkte für Reaktionen
- 550
- Punkte
- 113
@PeterPawn
Zugriff per Samba ist meine wichtigste Anwendung des VPN! Ich bin beim Arzt, bei einer Behörde und benötige ein Dokument, das zuhause auf dem NAS liegt und das ich eigentlich hätte mitnehmen wollen. Manchmal fehlt halt was. Das kopiere ich mir mittels Total Commander, habe es auf dem Handy und zeige es.
Tatsächlich war diese Änderung für mich etwas peinlich, weil ich genau in dieser Situation war. Und dann hat das VPN nicht wie gewohnt funktioniert! Ja, ich hatte ein anderes Handy und dafür einen neuen Wireguard-Tunnel. Ich hatte den nach der Einrichtung getestet, halt nur im Browser ("Tunnel geht"). Aber dass der auf einmal nicht wie bisher für Samba funktioniert, hat mir Schwierigkeiten bereitet. Ich bin dann per Shell auf einen Rechner zuhause, habe es per Kommandozeile auf einen Webserver kopiert und über einen Browser heruntergeladen und hatte das Dokument da, aber mein übliches "Moment, ich kopiere es gerade kurz her" hat mich dort erst mal ins Fluchen gebracht.
Man kann sowas ändern. Aber nicht ohne fettes Changelog ("Samba für Wireguard-Einzelgeräte wird nicht mehr unterstützt"). Und dann kann ich mir überlegen, ob ich weiterhin eine Fritzbox benutzen möchte, wenn sie an allen Ecken und Enden die Funktionalität beschnitten bekommt. (Nein, es ist nicht der Fall, bei Labor kommt sowas vor, das ist völlig ok, es gibt Möglichkeiten drumherum - du argumentierst aber, diese Änderung gut zu finden und unverändert ins Release zu nehmen)
Also meine ich: Keine Schritte zurückgehen. Jedenfalls nicht solche.
Zugriff per Samba ist meine wichtigste Anwendung des VPN! Ich bin beim Arzt, bei einer Behörde und benötige ein Dokument, das zuhause auf dem NAS liegt und das ich eigentlich hätte mitnehmen wollen. Manchmal fehlt halt was. Das kopiere ich mir mittels Total Commander, habe es auf dem Handy und zeige es.
Tatsächlich war diese Änderung für mich etwas peinlich, weil ich genau in dieser Situation war. Und dann hat das VPN nicht wie gewohnt funktioniert! Ja, ich hatte ein anderes Handy und dafür einen neuen Wireguard-Tunnel. Ich hatte den nach der Einrichtung getestet, halt nur im Browser ("Tunnel geht"). Aber dass der auf einmal nicht wie bisher für Samba funktioniert, hat mir Schwierigkeiten bereitet. Ich bin dann per Shell auf einen Rechner zuhause, habe es per Kommandozeile auf einen Webserver kopiert und über einen Browser heruntergeladen und hatte das Dokument da, aber mein übliches "Moment, ich kopiere es gerade kurz her" hat mich dort erst mal ins Fluchen gebracht.
Man kann sowas ändern. Aber nicht ohne fettes Changelog ("Samba für Wireguard-Einzelgeräte wird nicht mehr unterstützt"). Und dann kann ich mir überlegen, ob ich weiterhin eine Fritzbox benutzen möchte, wenn sie an allen Ecken und Enden die Funktionalität beschnitten bekommt. (Nein, es ist nicht der Fall, bei Labor kommt sowas vor, das ist völlig ok, es gibt Möglichkeiten drumherum - du argumentierst aber, diese Änderung gut zu finden und unverändert ins Release zu nehmen)
Also meine ich: Keine Schritte zurückgehen. Jedenfalls nicht solche.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,619
- Punkte für Reaktionen
- 1,947
- Punkte
- 113
@gantim:
Das mag ja Dein primärer Anwendungsfall sein - aber der Zugriff über ein zusätzliches Tool (und m.W. können die wenigsten Android-Geräte "natives SMB") ist und bleibt nun mal ein Spezialfall und da SMB-basierte Netze auch recht anfällig für Attacken sind (und diese Funktionen im Netzwerk bei den SMB sprechenden Geräte meistens eben NICHT explizit aktiviert werden müssen/können, wie bei anderen "Diensten" üblich - welcher normale Windows-Benutzer versteht den Unterschied zwischen "privaten" und "öffentlichen" Netzwerken?), wird eben SMB (früher aus gutem Grund, mittlerweile ist die Sicherheit etwas(!) besser, wenn SMB1 nicht einfach wieder reaktiviert wird, weil irgendwelche uralten Clients sonst nicht mitspielen dürfen) schon immer spezieller behandelt.
AVM ist auch nicht der einzige Router-Hersteller, der SMB-Filterung im Router implementiert - auch da wird (bei Geräten ohne erweiterte Möglichkeiten zur Firewall-Konfiguration) nur eine einfache Ja-/Nein-Entscheidung getroffen, wenn diese überhaupt angeboten wird. Auf der WAN-Seite ist eine solche Filterung jedenfalls gang und gäbe (selbst die KNB setz(t)en entsprechende Portfilter in der Konfiguration des CM) und wenn AVM das auf VPN-Verbindungen ausdehnen will (was auch Sinn machen KANN und sicherlich ändert sich so eine "Standardeinstellung" auch nicht von alleine), dann kann das ebenso eine (bewußte) Design-Entscheidung sein.
Oder hast Du irgendwo bei den VPN-Verbindungen (egal ob IPSec oder WireGuard®) die Möglichkeit des Ausfilterns von FTP- oder HTTP-Verkehr (Liste beliebig fortsetzen) gesehen? Es geht nun mal bei diesen Geräten und ihrer Firmware um das, was der überwiegende Teil der Kunden damit macht (bzw. machen soll/will) und wenn das jemandem nicht paßt, kann er ja problemlos auch sein NAS als VPN-Zugangspunkt verwenden, da gibt es diese Beschränkung nicht.
Außerdem bleibt ja immer noch die Option, seine VPN-Konfiguration auch im FRITZ!OS entsprechend anzupassen - wenn man nicht gleich ein anderes Transport-Protokoll für den Zugriff auf abgelegte Dateien verwendet.
Apropos "Einstellung" - wenn ich mich richtig erinnere, hat @christo weiter vorne in diesem Thread mal die Fragegestellt aufgeworfen, ob es mit einer ausführlicheren Konfiguration für die WireGuard®-Verbindungen nicht doch möglich wäre, auch eine Einzelplatzverbindung OHNE SMB-Filterung zu konfigurieren. Wenn AVM da etwas ändern bzw. an eine andere Stelle verschieben(!) will, wird das sicherlich irgendwann (und nicht sofort, jedenfalls war das bisher nicht so) auch in der Online-Hilfe bzw. Knowledge-Base entsprechend beschrieben.
Und wenn ich dann meinerseits hingehe und (allerdings nicht in einer der neuen Labor- oder Inhouse-Versionen, sondern irgendwo in einer früheren 08.xx, die da gerade installiert ist) eine "spezielle" WireGuard®-Verbindung konfigurieren will (und nicht die Karo-Einfach-Option nehme), dann wird mir wenig später das angezeigt:
Ist das bei den Labor-Versionen jetzt als Einstellmöglichkeit verschwunden (iirc hatte ja mind. ein anderer hier noch eine 6690) oder wie muß ich das verstehen? Gesetzt den Fall, das wäre immer noch möglich, würdest Du dann ggf. zugeben (und auch @Erforderlich), daß es sich ebenso um eine bewußte Entscheidung handeln KÖNNTE und man nicht automatisch von einem Bug ausgehen MUSS?
Das mag ja Dein primärer Anwendungsfall sein - aber der Zugriff über ein zusätzliches Tool (und m.W. können die wenigsten Android-Geräte "natives SMB") ist und bleibt nun mal ein Spezialfall und da SMB-basierte Netze auch recht anfällig für Attacken sind (und diese Funktionen im Netzwerk bei den SMB sprechenden Geräte meistens eben NICHT explizit aktiviert werden müssen/können, wie bei anderen "Diensten" üblich - welcher normale Windows-Benutzer versteht den Unterschied zwischen "privaten" und "öffentlichen" Netzwerken?), wird eben SMB (früher aus gutem Grund, mittlerweile ist die Sicherheit etwas(!) besser, wenn SMB1 nicht einfach wieder reaktiviert wird, weil irgendwelche uralten Clients sonst nicht mitspielen dürfen) schon immer spezieller behandelt.
AVM ist auch nicht der einzige Router-Hersteller, der SMB-Filterung im Router implementiert - auch da wird (bei Geräten ohne erweiterte Möglichkeiten zur Firewall-Konfiguration) nur eine einfache Ja-/Nein-Entscheidung getroffen, wenn diese überhaupt angeboten wird. Auf der WAN-Seite ist eine solche Filterung jedenfalls gang und gäbe (selbst die KNB setz(t)en entsprechende Portfilter in der Konfiguration des CM) und wenn AVM das auf VPN-Verbindungen ausdehnen will (was auch Sinn machen KANN und sicherlich ändert sich so eine "Standardeinstellung" auch nicht von alleine), dann kann das ebenso eine (bewußte) Design-Entscheidung sein.
Oder hast Du irgendwo bei den VPN-Verbindungen (egal ob IPSec oder WireGuard®) die Möglichkeit des Ausfilterns von FTP- oder HTTP-Verkehr (Liste beliebig fortsetzen) gesehen? Es geht nun mal bei diesen Geräten und ihrer Firmware um das, was der überwiegende Teil der Kunden damit macht (bzw. machen soll/will) und wenn das jemandem nicht paßt, kann er ja problemlos auch sein NAS als VPN-Zugangspunkt verwenden, da gibt es diese Beschränkung nicht.
Außerdem bleibt ja immer noch die Option, seine VPN-Konfiguration auch im FRITZ!OS entsprechend anzupassen - wenn man nicht gleich ein anderes Transport-Protokoll für den Zugriff auf abgelegte Dateien verwendet.
Apropos "Einstellung" - wenn ich mich richtig erinnere, hat @christo weiter vorne in diesem Thread mal die Frage
Und wenn ich dann meinerseits hingehe und (allerdings nicht in einer der neuen Labor- oder Inhouse-Versionen, sondern irgendwo in einer früheren 08.xx, die da gerade installiert ist) eine "spezielle" WireGuard®-Verbindung konfigurieren will (und nicht die Karo-Einfach-Option nehme), dann wird mir wenig später das angezeigt:
Ist das bei den Labor-Versionen jetzt als Einstellmöglichkeit verschwunden (iirc hatte ja mind. ein anderer hier noch eine 6690) oder wie muß ich das verstehen? Gesetzt den Fall, das wäre immer noch möglich, würdest Du dann ggf. zugeben (und auch @Erforderlich), daß es sich ebenso um eine bewußte Entscheidung handeln KÖNNTE und man nicht automatisch von einem Bug ausgehen MUSS?
Zuletzt bearbeitet:
@PeterPawn
Wie gesagt, eine deutlich angekündigte, begründete, eventuell konfigurierbare Änderung ist was anderes als eine stillschweigende Änderung eines Defaults, und auf einmal steht man in der Behörde erst mal dumm da.
Die Einstellmöglichkeit (das wurde bereits diskutiert) besteht nicht bei Verbindungen für Einzelgeräte, sie ist nur bei Site2Site vorhanden (wobei erwähnt wurde, dass das bei Wireguard ggf austauschbar wäre). Hier wurde stillschweigend der Default beim Anlegen geändert, ohne dass man Einfluss auf den Wert hätte oder eine Information angezeigt würde.
Wie gesagt, eine deutlich angekündigte, begründete, eventuell konfigurierbare Änderung ist was anderes als eine stillschweigende Änderung eines Defaults, und auf einmal steht man in der Behörde erst mal dumm da.
Die Einstellmöglichkeit (das wurde bereits diskutiert) besteht nicht bei Verbindungen für Einzelgeräte, sie ist nur bei Site2Site vorhanden (wobei erwähnt wurde, dass das bei Wireguard ggf austauschbar wäre). Hier wurde stillschweigend der Default beim Anlegen geändert, ohne dass man Einfluss auf den Wert hätte oder eine Information angezeigt würde.
Also ich hab mal meine ganzen Einzelgeräts-Verbindung durchgeschaut und auch die Support-Daten mal gezogen. Überall ist auch SMB möglich und "dont_filter_netbios" auf "yes" gesetzt, auch bei irgendwelchen neuen.
Meine Fritte ist eine 7690 mit 8.02 Final.
Meine Fritte ist eine 7690 mit 8.02 Final.
Erforderlich
Aktives Mitglied
- Mitglied seit
- 7 Jan 2024
- Beiträge
- 2,063
- Punkte für Reaktionen
- 550
- Punkte
- 113
Das ist ja offensichtlich die "Netzwerke koppeln oder spezielle Verbindungen herstellen", wo ich schon immer (?) "NetBIOS über diese Verbindung zulassen" ändern konnte.
Wo ich gerade mal alle meine Sicherungen auf
dont_filter_netbios kontrolliert habe: Wie ist das eigentlich mit reject_not_encrypted = no;, steht das immer noch so drin bei IPsec und Wireguard? Klingt das nicht etwas nach offenem Scheunentor und sollte das nicht allen deutlich mehr Bauchschmerzen machen?Fazit: Es wird wohl in der nächsten Zeit keine Labor oder 8verkorkst20 den Weg auf einen meiner Router+Mesh-Master finden.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,619
- Punkte für Reaktionen
- 1,947
- Punkte
- 113
@gantim:
Unabhängig davon, ob man das angekündigt hat oder nicht - wer mit Beta-Firmware irgendwann und irgendwo dumm dasteht, der sollte entweder VORHER alles das testen, was er verwendet/braucht oder gleich ganz auf den Einsatz von Labor-Firmware verzichten, wenn er auf Funktionen ANGEWIESEN ist.
Da jetzt einen SKANDAL drin zu sehen, daß AVM da überhaupt Änderungen vorgenommen hat, ohne sich zuvor die Zustimmung einzelner Benutzer einzuholen (und nein, Du hast das nicht (direkt) selbst skandalisiert, sondern nur in den Status eines Bugs erhoben und erwartest offenbar (immer noch), daß man es wieder rückgängig macht - andere haben sich da deutlicher zu AVM und der "Software-Qualität" eingelassen), verkennt in meinen Augen die Realitäten.
Alleine von Deiner 7530AX wurden (lt. router-faq.de: https://www.router-faq.de/?id=fbinf...outer-faq.de/?id=fbinfo&hwf=fb7530ax#fb7530ax) mehr als 2,5 Mio. Stück produziert und nun überlege mal, welchen Anteil daran (und wir reden von EINEM einzelnen Modell; über alle von der Änderung betroffenen Modelle sind das noch mal deutlich mehr) diejenigen haben, die eben NICHT hier aufschlagen, weil sie die Änderung gar nicht bemerken.
Und mir persönlich ist es tatsächlich vollkommen egal, ob AVM bei der (vermutlich getroffenen) Entscheidung bleibt oder nicht - ich plädiere nur dafür, daß nicht jede (nicht ausführlichst kommunizierte) Änderung, die für den einen ein Problem darstellt (bei seinem EIGENEN Szenario, in dem er das Gerät einsetzt), auch für alle anderen FRITZ!OS-Benutzer als solches anzusehen ist und es eben kein Bug sein MUSS. Es ist ja (für mich jedenfalls) sogar sehr unwahrscheinlich, daß so eine Änderung "versehentlich" erfolgt.
Auch die Feststellung, daß AVM die Firmware in ihren Funktionen immer mehr beschneiden würde, mag nach Deiner Ansicht ja richtig sein - ich sehe da dennoch bei fast allen Änderungen seitens AVM deutliche Vorteile für die Mehrzahl der Nutzer (und mir wird hoffentlich niemand ernsthaft unterstellen wollen, ich wäre "Fan-Boy" und/oder stünde AVM generell unkritisch gegenüber) und das sind diejenigen, die wirklich zählen und die AVM im Auge haben sollte.
Wenn da jemandem, der sich ja offenbar am Ende zu helfen wußte, die Verwendung von (von ihm nicht ausreichend getesteter) Labor-Firmware auf die Füße fällt - so what? DAS Risiko bist Du ja (hoffentlich) bewußt eingegangen und es gibt garantiert auch noch weitere (bisher nicht dokumentierte oder überhaupt nur bemerkte) Änderungen, die eben für Dich nicht zu einem - so ausgeprägten - Problem wurden.
Die Ursache Deines Problems ist doch mittlerweile klar erkannt - soll die Frage "Bug oder nicht?" jetzt tatsächlich in diesem Thread (der sich ja nicht mal explizit von Beginn an auf die Labor-Reihe bezog, es mußte ja erst mal im Verlauf herausgearbeitet werden, daß es sich um ein Labor-Problem handelt) entschieden werden?
Wenn das mit einer eingehenderen Konfiguration weiterhin zu lösen ist, dann BRINGT diese Änderung denjenigen, die nur eine simple VPN-Verbindung herstellen wollen - um mal mit dem Zaunfeld "Home Assistant" zu winken - eben durchaus Vorteile … Zugriffe auf SMB-Protokolle sind erst einmal unterbunden, solange der Benutzer die Verbindung nicht explizit so konfiguriert, daß das nicht der Fall ist. Wer sich die (WireGuard®-)Konfiguration im FRITZ!OS genau ansieht, wird feststellen, daß da eben nicht nur zwischen Einzelplatz und Site-to-site unterschieden wird, wie das bei IPSec war bzw. ist (und auch das stimmt ja eigentlich nicht mal) - in meinen Augen ist so eine VPN-Verbindung, die auch SMB transportieren soll, durchaus "speziell".
Und es gibt bei SMB und allem anderen, was darauf aufbaut, genug Angriffsmöglichkeiten … nicht umsonst basieren die meisten Windows-(Netzwerk-)Lücken, die sich remote ausnutzen lassen, auf SMB (und RDP), denn auch (Windows-)RPC basiert zu einem größeren Teil auf SMB, das sind die (üblicherweise versteckten) IPC$-Freigaben. Wenn da mal wieder eine größere Lücke bekannt wird, ist es aber zu spät, um erst mal alle AVM-VPN-Benutzer ihre Konfigurationen ändern zu lassen. Ein Security-Prinzip ist es auch, mit so wenig Angriffsfläche wie möglich zu operieren und da gehört das Blockieren von Diensten, die nicht benötigt werden, dazu - im Profi-Bereich dann eben mit einer "richtigen" Firewall.
Und zu
Unabhängig davon, ob man das angekündigt hat oder nicht - wer mit Beta-Firmware irgendwann und irgendwo dumm dasteht, der sollte entweder VORHER alles das testen, was er verwendet/braucht oder gleich ganz auf den Einsatz von Labor-Firmware verzichten, wenn er auf Funktionen ANGEWIESEN ist.
Da jetzt einen SKANDAL drin zu sehen, daß AVM da überhaupt Änderungen vorgenommen hat, ohne sich zuvor die Zustimmung einzelner Benutzer einzuholen (und nein, Du hast das nicht (direkt) selbst skandalisiert, sondern nur in den Status eines Bugs erhoben und erwartest offenbar (immer noch), daß man es wieder rückgängig macht - andere haben sich da deutlicher zu AVM und der "Software-Qualität" eingelassen), verkennt in meinen Augen die Realitäten.
Alleine von Deiner 7530AX wurden (lt. router-faq.de: https://www.router-faq.de/?id=fbinf...outer-faq.de/?id=fbinfo&hwf=fb7530ax#fb7530ax) mehr als 2,5 Mio. Stück produziert und nun überlege mal, welchen Anteil daran (und wir reden von EINEM einzelnen Modell; über alle von der Änderung betroffenen Modelle sind das noch mal deutlich mehr) diejenigen haben, die eben NICHT hier aufschlagen, weil sie die Änderung gar nicht bemerken.
Und mir persönlich ist es tatsächlich vollkommen egal, ob AVM bei der (vermutlich getroffenen) Entscheidung bleibt oder nicht - ich plädiere nur dafür, daß nicht jede (nicht ausführlichst kommunizierte) Änderung, die für den einen ein Problem darstellt (bei seinem EIGENEN Szenario, in dem er das Gerät einsetzt), auch für alle anderen FRITZ!OS-Benutzer als solches anzusehen ist und es eben kein Bug sein MUSS. Es ist ja (für mich jedenfalls) sogar sehr unwahrscheinlich, daß so eine Änderung "versehentlich" erfolgt.
Auch die Feststellung, daß AVM die Firmware in ihren Funktionen immer mehr beschneiden würde, mag nach Deiner Ansicht ja richtig sein - ich sehe da dennoch bei fast allen Änderungen seitens AVM deutliche Vorteile für die Mehrzahl der Nutzer (und mir wird hoffentlich niemand ernsthaft unterstellen wollen, ich wäre "Fan-Boy" und/oder stünde AVM generell unkritisch gegenüber) und das sind diejenigen, die wirklich zählen und die AVM im Auge haben sollte.
Wenn da jemandem, der sich ja offenbar am Ende zu helfen wußte, die Verwendung von (von ihm nicht ausreichend getesteter) Labor-Firmware auf die Füße fällt - so what? DAS Risiko bist Du ja (hoffentlich) bewußt eingegangen und es gibt garantiert auch noch weitere (bisher nicht dokumentierte oder überhaupt nur bemerkte) Änderungen, die eben für Dich nicht zu einem - so ausgeprägten - Problem wurden.
Die Ursache Deines Problems ist doch mittlerweile klar erkannt - soll die Frage "Bug oder nicht?" jetzt tatsächlich in diesem Thread (der sich ja nicht mal explizit von Beginn an auf die Labor-Reihe bezog, es mußte ja erst mal im Verlauf herausgearbeitet werden, daß es sich um ein Labor-Problem handelt) entschieden werden?
Wenn das mit einer eingehenderen Konfiguration weiterhin zu lösen ist, dann BRINGT diese Änderung denjenigen, die nur eine simple VPN-Verbindung herstellen wollen - um mal mit dem Zaunfeld "Home Assistant" zu winken - eben durchaus Vorteile … Zugriffe auf SMB-Protokolle sind erst einmal unterbunden, solange der Benutzer die Verbindung nicht explizit so konfiguriert, daß das nicht der Fall ist. Wer sich die (WireGuard®-)Konfiguration im FRITZ!OS genau ansieht, wird feststellen, daß da eben nicht nur zwischen Einzelplatz und Site-to-site unterschieden wird, wie das bei IPSec war bzw. ist (und auch das stimmt ja eigentlich nicht mal) - in meinen Augen ist so eine VPN-Verbindung, die auch SMB transportieren soll, durchaus "speziell".
Und es gibt bei SMB und allem anderen, was darauf aufbaut, genug Angriffsmöglichkeiten … nicht umsonst basieren die meisten Windows-(Netzwerk-)Lücken, die sich remote ausnutzen lassen, auf SMB (und RDP), denn auch (Windows-)RPC basiert zu einem größeren Teil auf SMB, das sind die (üblicherweise versteckten) IPC$-Freigaben. Wenn da mal wieder eine größere Lücke bekannt wird, ist es aber zu spät, um erst mal alle AVM-VPN-Benutzer ihre Konfigurationen ändern zu lassen. Ein Security-Prinzip ist es auch, mit so wenig Angriffsfläche wie möglich zu operieren und da gehört das Blockieren von Diensten, die nicht benötigt werden, dazu - im Profi-Bereich dann eben mit einer "richtigen" Firewall.
Und zu
reject_not_encrypted - AFAIK stammt dieser Parameter noch aus der Zeit des "AVM-MPR" und "KEN!" und hat schon lange keine Funktion mehr in der VPN-Implementierung im FRITZ!OS (Zertifikate gehen m.W. auch nicht mehr, selbst wenn es Parameter dafür gibt). Mir ist es jedenfalls nie gelungen, damit IRGENDEINE Box nach 06.xx zum Transport von unverschlüsseltem Traffic über ein externes Interface zu überreden - dazu mußte man bei IPSec ein unverschlüsseltes Proposal-Set auswählen.@PeterPawn
Wenn du nicht darauf rumgehackt hättest, hätte ich gar nichts gesagt. Den Skandal machst du, indem du dementieren möchtest, dass es ein Fehler ist und die Reaktion von AVM, die noch nicht erfolgt ist, in einem für mich negativen Sinne antizipierst und so eine Begründung/Reaktion meinerseits hervorrufst. Ich möchte diese Diskussion jetzt (zumindest derzeit) nicht mehr führen. Lass uns einfach die Reaktion abwarten. Vielleicht wird es in der nächsten Laborversion auch für Einzelgeräte konfigurierbar und dann kann jeder einstellen, was er will.
Wenn du nicht darauf rumgehackt hättest, hätte ich gar nichts gesagt. Den Skandal machst du, indem du dementieren möchtest, dass es ein Fehler ist und die Reaktion von AVM, die noch nicht erfolgt ist, in einem für mich negativen Sinne antizipierst und so eine Begründung/Reaktion meinerseits hervorrufst. Ich möchte diese Diskussion jetzt (zumindest derzeit) nicht mehr führen. Lass uns einfach die Reaktion abwarten. Vielleicht wird es in der nächsten Laborversion auch für Einzelgeräte konfigurierbar und dann kann jeder einstellen, was er will.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,619
- Punkte für Reaktionen
- 1,947
- Punkte
- 113
Seriously?
Hast Du Dir mal alles(!) das durchgelesen (ab #13), was da vor meiner Überlegung(!), daß es sich ja auch um eine GEWOLLTE Änderung handeln könnte, geschrieben wurde (von dir und anderen)? Oder Deine Antwort auf meinen Einwurf (#29) in #31 hier im Thread (speziell den dritten Absatz)?
Wie genau habe ich denn (unter Berücksichtigung des oben (in diesem Beitrag) Geschriebenen) darauf herumgehackt? Wie konnte ich das überhaupt angesichts all dessen, was du schon VOR #29 dazu geschrieben hast?
Also jetzt bitte keinen Versuch einer "Schuldumkehr" - und ich habe auch nicht nur Dich angesprochen (selbst wenn Du am Beginn des Beitrags referenziert sein magst), sondern durchaus auch @Erforderlich einbezogen; schon #13 (von Dir mit "Däumchen" versehen, was gemeinhin als zustimmende Reaktion angesehen wird) war für meine Begriffe nicht mehr wirklich fair und die Replik in #30 (zweiter Satz) ebensowenig. Nur geht er offenbar stillschweigend(!) darüber hinweg (das darf er auch) und versucht nicht seinerseits weiterhin, nur bis zum eigenen Tellerrand zu sehen und verteidigt seine These (nennen wir es mal so) so verbissen, ohne für Argumente zugänglich zu sein oder darauf einzugehen.
Hallo zusammen,
bei der aktuellen Inhouse für die 6690 hat AVM den Wert von "dont_filter_netbios" wieder auf "yes" geändert (für alle Wireguard-Verbindungen).
bei der aktuellen Inhouse für die 6690 hat AVM den Wert von "dont_filter_netbios" wieder auf "yes" geändert (für alle Wireguard-Verbindungen).
Bei der 7530ax auch, alle SMB Zugriffe per Wireguard VPN (Einzelgeräte) sind mit der aktuellen Laborversion wieder möglich. Ohne eine Verbindung neu anlegen zu müssen.
Neueste Beiträge
-
[Info] Fritz auf der IFA 2026
- Letzte: Sebastian1985
-
JFritz holt keine Anrufe mehr ab
- Letzte: ladesdo
-
Fritz!Box 7590 Inhaus/Labor - MyFRITZOS P1 - ( 8.4x )
- Letzte: chaosenergy
-
Welcher Fehler...- Letzte: Zwanzigeinundzwanzig
-
[Sammlung] Aktuelle Konditionen für DSL-Vertragsverlängerung
- Letzte: ChrK2000