09.09.2022

16959

Kein SMB Zugriff über Fritzbox Wireguard

Hallo zusammen,

ich habe darüber schon viel gelesen, leider nirgends eine Lösung gefunden.
Ich habe eine FB6690 am Vodafone Kabelanschluss mit aktueller Laborfirmware.
Dort habe ich eine Wireguard VPN-Verbindung eingerichtet.
Wenn ich nun von einem entferneten Rechner per Wireguard eine VPN-Verbindung aufbaue,
funktioniert das auch. ich kann über die lokale IP die FB erreichen und auch sonst alle Geräte mit
einem Webinterface (z.b. meinen Drucker). Was aber nicht funktioniert ist der Zugriff auf eine Dateifreigabe.

z.b. \\192.168.200.5\daten

im häuslichen Lan ist diese Freigabe ohne Probleme zu erreichen.

Welche Einstellung ist dafür noch vorzunehmen ??

Danke und Grüße
Tobias

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 3884234988

Url: https://administrator.de/forum/kein-smb-zugriff-ueber-fritzbox-wireguard-3884234988.html

Ausgedruckt am: 22.12.2024 um 16:12 Uhr

45 Kommentare

Neuester Kommentar

Moin,

windows-firewall
IP-Netzkonflikte, weil gleiches RFC1918-Subnetz im remote-Netz

Was sagt ipconfig/All und ein treceroute?

lks

Dual-Stack lite?
Was sagt https://www.wieistmeineip.de/ipv6-test/ ?
Uups....überlesen...Zugriff klappt ja generell.

Da SMB:
Evtl. noch SMB 1.0 auf dem Client aktivieren.

Moin,

ich tippe wie der Kollege @Lochkartenstanzer auf die Windows-Firewall der Freigabe. Hier ist der Zugriff vermutlich auf das lokale Netz beschränkt.

Gruß

Looser

- öffentliche ipv4 Adresse
- Ping auf die 192.168.200.5 antwortet
- Die MS-Firewall ist auf beiden Seiten deaktiviert
- SMB 1.0 ist aktiviert

Zitat von @Looser27:

Moin,

ich tippe wie der Kollege @Lochkartenstanzer auf die Windows-Firewall der Freigabe. Hier ist der Zugriff vermutlich auf das lokale Netz beschränkt.

+1

Wie ist die IP des VPN-CLients?

Gruß
em-pie

172.20.2.1

Klasse B-Netz

172.20.2.1/16 Client

192.168.200.0/24 Server (Fritzbox)

172.20.2.1/16 Client

du hast aber viel vor: willst du echt 65.534 Clients ans VPN anbinden? Dann ist dein Fritte aber echt unterdimensioniert.

Dann prüfe bitte mal die Firewall a deinem Rechner 192.168.200.5 - die wird nämlich das 172.20.0.0/16 Netz blockieren

Verstehen wir uns hier nicht falsch...?
Das 172.20.2.1/16 ist die IP des Rechners von wo aus ich die VPN-Verbindung aufbaue.
Zuhause (dort wo die FB steht) habe ich ein "normales" C-Netz.

Wie gesagt, die Verbindung ist auch nicht das Problem. Das Netz kann auch nicht geblockt werden,
denn dann würde ich nicht auf das Web-Interfaces des Druckers etc. kommen.

Es scheint einfach so, dass SMB bzw. der Port dahinter gesperrt wird.

Zitat von @tobias3355:

- öffentliche ipv4 Adresse

Was ist die Lan-Ip im remote Netz?

- Ping auf die 192.168.200.5 antwortet

Ist es auch der richtige? Traveroute nehmen, nicht Ping!

- Die MS-Firewall ist auf beiden Seiten deaktiviert
- SMB 1.0 ist aktiviert

Was sagt Wireshark?

Ist in der Dritte eingestellt, das smb/cifs durch die dritte durch darf?

lks

Hallo,

z.b. \\192.168.200.5\daten

Die Benutzereinstellungen in der AVM FB und dort dann bitte den Zugriff auf das NAS oder den

Speicher gestatten, VPN Benutzer Rechte!

Windows Firewall am VPN Gerät (PC oder Laptop) mal überprüfen!

im häuslichen Lan ist diese Freigabe ohne Probleme zu erreichen.

Das ist dann nicht via AVM FB und somit auch kein Problem.

Dobby

Zitat von @tobias3355:

Verstehen wir uns hier nicht falsch...?
Das 172.20.2.1/16 ist die IP des Rechners von wo aus ich die VPN-Verbindung aufbaue.

dann finde ich 65.534 mögliche CLients in dem Netz dennoch ganz schön viel - aber egal. anderes Thema

Zuhause (dort wo die FB steht) habe ich ein "normales" C-Netz.

Klasse A- E Netze gibt es eigentlich schon lange in der Form nicht mehr.
Richte dich nach RFC1918

Wie gesagt, die Verbindung ist auch nicht das Problem. Das Netz kann auch nicht geblockt werden,
denn dann würde ich nicht auf das Web-Interfaces des Druckers etc. kommen.

Ich rede auch nicht von der Verbindung selbst, sondern von der Firewall, die in WIndows integriert ist.
Dein Drucker hat keine Firewall integriert und lässt daher die Fremdnetze (in deinem Fall 172.20.0.0/16) zu.
Windows selbst hat indes eine Firewall integriert, die erst einmal nur die Sender aus dem eigenen LAN zulässt.

Es scheint einfach so, dass SMB bzw. der Port dahinter gesperrt wird.

Ja genau, und zwar für alles, was NICHT aus dem Netz 192.168.200.0/24 kommt.

Klasse A- E Netze gibt es eigentlich schon lange in der Form nicht mehr.

Stammt noch aus dem Netzwerk Neandertal...
https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing

Zum Thread Thema schreibt AVM in seiner Knowledgebase Punkt 4
https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-7490/344_Uber-VPN- ...
bzw.
https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-7490/48_Uber-VPN-a ...
Der TO hat also per se alles richtig gemacht in Bezug auf SMB. Liegt also wie oben schon vermutet an falscher Adressierung oder falschen Subnetzmasken im internen WG Netz.
Die richtige Subnetzmasken Konfiguration sind für das WG Cryptorouting essentiell wichtig! Siehe dazu auch Wireguard Tutorial. 16er Prefixe sind bei einem Heimnetz da natürlich zwar nicht per se falsch aber unsinnig.

[Interface]
PrivateKey = KLBrH29ydUy/1jIA6nXK97EKXlXLa4ATrVni9mbZoVc=
Address = 192.168.200.128/24
DNS = 192.168.200.1
DNS = fritz.box

[Peer]
PublicKey = hckPbU3g3ftpNCxKgwRTP8lFov+1+bFcRZLr1kYeA08=
PresharedKey = BLAkRReo2shzB0HEjs1QC9H/PBzndwGwMstcv1eic+A=
AllowedIPs = 192.168.200.0/24,0.0.0.0/0
Endpoint = theo.nofixip.de:59344
PersistentKeepalive = 25

Anbei der WG Config file, welcher die FB erzeugt hat.

Komisch ist aber auch, dass das mal funktioniert hat ohne das ich etwas anders gemacht habe. Ich habe höchstens die FW der FB Upgedatetet.

PS. Die MS-Firewall ist komplett deaktiviert.

Zitat von @tobias3355:

Komisch ist aber auch, dass das mal funktioniert hat ohne das ich etwas anders gemacht habe. Ich habe höchstens die FW der FB Upgedatetet.

Könnte aber auch schlicht und einfach an der Laborfirmware liegen. Hast Du mal AVM gefragt?

Hast Du mal mit wireshark die smb-Kommunikation angeschaut?

lks

danke für den tip.
hier die antwort von avm...

Problem:

SMB-Freigaben, Datei- und Druckerfreigaben unter Microsoft Windows und sonstige NetBIOS basierte Anwendungen funktionieren nicht über WireGuard-VPN-Verbindungen.

Lösung:

SMB-Freigaben, Datei- und Druckerfreigaben unter Microsoft Windows und sonstige NetBIOS basierte Anwendungen sind über Wireguard-VPN-Verbindungen aktuell nicht nutzbar. Es wird an einer Lösung gearbeitet. Nutzen Sie bitte bis zur Lösung eine IPSec-VPN-Verbindung.

Zitat von @tobias3355:

danke für den tip.
hier die antwort von avm...

Problem:

SMB-Freigaben, Datei- und Druckerfreigaben unter Microsoft Windows und sonstige NetBIOS basierte Anwendungen funktionieren nicht über WireGuard-VPN-Verbindungen.

Lösung:

SMB-Freigaben, Datei- und Druckerfreigaben unter Microsoft Windows und sonstige NetBIOS basierte Anwendungen sind über Wireguard-VPN-Verbindungen aktuell nicht nutzbar. Es wird an einer Lösung gearbeitet. Nutzen Sie bitte bis zur Lösung eine IPSec-VPN-Verbindung.

Hi Tobias,

woher hast du diese Info? Ich suche auch schon seit drei Tagen nach einer Lösung.

VG

Zitat von @AM1587:

Hi Tobias,

woher hast du diese Info? Ich suche auch schon seit drei Tagen nach einer Lösung.

Er hat AVm gefragt, so wie ich es ihm empfohlen habe.

lks

avm

Fazit:
IPsec nutzen. Fragt sich warum du das nicht gleich gemacht hast, denn das ist wenigstens bewährt, sicher und hat keinen Beta Bastelstatus.

Tja da kann man bei AVM nur mal wieder den Kopf schütteln. Wie die Wireguard in der Fritte implementieren/verschandeln ist gelinde gesagt unterste Schublade. Hier läuft SMB über Wireguard nämlich problemlos über RouterOS oder ne pfSense, liegt also definitiv an AVM und deren selbstgebackenen Müll und nicht an Wireguard ansich denn dem ist der Protokoll Layer ja völlig wumpe!!

Kein Wunder ist das bei denen eben noch Labor/Betastatus, bei AVM eher noch unflexibler Alpha-Status.
Wenn die das so rausbringen wird das ne echte Lachnummer...

Cheers
certguy

Zitat von @3803037559:

Tja da kann man bei AVM nur mal wieder den Kopf schütteln. Wie die Wireguard in der Fritte implementieren/verschandeln ist gelinde gesagt unterste Schublade. Hier läuft SMB über Wireguard nämlich problemlos über RouterOS oder ne pfSense, liegt also definitiv an AVM und deren selbstgebackenen Müll und nicht an Wireguard ansich denn dem ist der Protokoll Layer ja völlig wumpe!!

Kein Wunder ist das bei denen eben noch Labor/Betastatus, bei AVM eher noch unflexibler Alpha-Status.
Wenn die das so rausbringen wird das ne echte Lachnummer...

Im Gegensatz zu RouterOS oder pfsense sind die Ressourcen einer Fritte deutlich begrenzter und die Laborfirmware ist eindeutig zum "ausprobieren" gedacht. Dabei werden verschiedene Funktionen zugunsten anderer rausgeworfen. Du kannst nicht erwarten, daß alph/beta-Software so funktiiert wie Releases. Wenn AVM das als reguläre Firmware rausgebracht hätte könnte man das denen schon vorwerfen, aber eine Firmware die explizit nicht zum produktiven Einsatz gedacht ist, danach zu bewerten, ob sie dafür taugt, ist schon ein wenig Anspruchsdenken.

Also laßt die Jungs mal machen und wenn die das beim neuen Release verkacken, dürft Ihr Euch dann darüber aufregen. Bis dahin sollte jeder der Wireguard braucht oder will sich die alternativen Lösungen vornehmen, z.B. die "schlüsselfertige" Turnkey-Version von Wireguard. Das ist sinnvoller als sich mit alpha und beta-releases herumzuschlagen.

lks

PS. Die turnkey-Version ist in nicht einmal 10 Minuten als VM aufgesetzt, wenn man weiß, was man macht.

Hallo,

und deren selbstgebackenen Müll und nicht an Wireguard

WireGuard isr bei vielen Firmen und Distributionen immer noch als "im Entwicklungsstatus" gekennzeichnet,
und von daher ist es auch wenig verwunderlich dass jeder sein eigenes Paket dazu entwickelt. Klar oder?
Die Anwender wollen einfach immer alles, bei pfSense ist das auch so, nur kann man eben nicht OpenVPN,
WireGuard und IPSec nebeneinander installieren und/oder nutzen! Damit das möglich ist (wird) entwickeln
viele Leute Ihre eigenen Pakete so dass man dann als Nutzer eben diese Pakete nebeneinander installieren
und auch benutzen kann. Und AVM benutzt ARM CPUs und das ist dann eben auch nicht immer so einfach
zu installieren, wenn es sich um Code für x86(_64) Hardware handelt und AVM eben die besagten ARM CPUs
benutzt! Noch dazu kommt dass ARM eben nicht gleich ARM ist! Als wenn etwas auf eine ARM v8/9 läuft,
kann man das nicht so einfach nur mal eben durch den "Compiler jagen" und es läuft dann auch auf dem
(als Beispiel) TurrisOmnia mit einer Marvell Armada XP CPU. Also sind da so oder so immer Leute die
"Hand anlegen müssen".

Dobby

nur kann man eben nicht OpenVPN, WireGuard und IPSec nebeneinander installieren und/oder nutzen!

Ein Raspberry Pi, Mikrotik oder pfSense/OPNsense usw. könnte das rein technisch gesehen problemlos. Ob das dann aber netztechnisch auch Sinn macht steht auf einem ganz anderen Blatt Papier!

Zitat von @108012:
WireGuard isr bei vielen Firmen und Distributionen immer noch als "im Entwicklungsstatus" gekennzeichnet,
und von daher ist es auch wenig verwunderlich dass jeder sein eigenes Paket dazu entwickelt. Klar oder?

Quatsch das hat nichts mit Entwicklungsstatus von Wireguard ansich zu tun. Einigermaßen aktuelle Linux-Kernel würden wohl kaum etwas enthalten das noch Beta-Status hat. Das Kernel-Modul für WG ist ja auch schon seit einiger Zeit stable mit an Bord.
Das Problem was AVM sich hier übrigens selbst produziert ist das sie das üblicherweise getrennte Transfernetz von WG Netz auf das FB-Heimnetz mappen, sonst wäre das alles Standard-Ware die auch funktioniert wie sie soll und auch Millionenfach tut.

Die Anwender wollen einfach immer alles, bei pfSense ist das auch so, nur kann man eben nicht OpenVPN,
WireGuard und IPSec nebeneinander installieren und/oder nutzen!

Sicher geht das, wieso sollte man das nicht können??? Die haben alle keine gegenseitigen Abhängigkeiten uns sind sogar auch parallel nutzbar! Wireguard mit beliebig wählbarem UDP Port, OpenVPN dito, IPSec 4500/500 UDP und ESP(50), stören sich also alle gegenseitig nicht.

Damit das möglich ist (wird) entwickeln
viele Leute Ihre eigenen Pakete so dass man dann als Nutzer eben diese Pakete nebeneinander installieren
und auch benutzen kann. Und AVM benutzt ARM CPUs und das ist dann eben auch nicht immer so einfach
zu installieren, wenn es sich um Code für x86(_64) Hardware handelt und AVM eben die besagten ARM CPUs benutzt! Noch dazu kommt dass ARM eben nicht gleich ARM ist! Als wenn etwas auf eine ARM v8/9 läuft,
kann man das nicht so einfach nur mal eben durch den "Compiler jagen" und es läuft dann auch auf dem
(als Beispiel) TurrisOmnia mit einer Marvell Armada XP CPU. Also sind da so oder so immer Leute die
"Hand anlegen müssen".

Kompilieren klar, aber das läuft ja schon längst. Das hat nichts mit den Protokollen zu tun die auf anderen OSI-Layern über den eigentlichen Tunnel laufen. Denke das wird bei AVM wohl an der implementierten Firewall liegen, das sie sich da wohl noch ein Eigentor geschossen haben.

Nun denn, sind ja eh nur die Jungs die ihre Fritten früher als nötig frisieren und dann wundern. 🖖

So denne, "eine Runde Wochenend-Bit für Alle schmeiß 🍺"

Cheers
certguy

Zitat von @aqui:

Fazit:
IPsec nutzen. Fragt sich warum du das nicht gleich gemacht hast, denn das ist wenigstens bewährt, sicher und hat keinen Beta Bastelstatus.

Es gibt schon n Grund warum man auf WireGuard umsteigt, die IPsec-Umsetzung von AVM ist noch schlechter als die aktuelle WG Umsetzung. Das funktioniert einfach zuverlässig nicht.
Auch ist die Software die man von AVM für das IPsec-VPN bekommt, der letzte Rotz. Gefühlt 2007 letztes Update bekommen.

Also ich muss sagen so sehr ich die Fritz!Boxen mag, die WireGuard-Geschichte läuft echt nicht gut für AVM.

die IPsec-Umsetzung von AVM ist noch schlechter als die aktuelle WG Umsetzung. Das funktioniert einfach zuverlässig nicht.

Dann machst du irgendwas falsch.
Übrigens, mit der neuen Version, so denn sie denn mal fertig ist funktioniert nun auch IPSec Einwahl über IKEv2, somit sind nun auch keine zusätzlichen VPN Clients mehr nötig und es lassen sich die bordeigenen OS Clients nutzen. Hey wer hätte das gedacht das die das auch mal irgendwann schaffen😂
Kommt Zeit kommt rat, für die Friiten-Homies da draussen ...

Zitat von @3803037559:
Dann machst du irgendwas falsch.

Joa, VPN-Lösungen von AVM benutzen

Zitat von @Joystick:

Es gibt schon n Grund warum man auf WireGuard umsteigt, die IPsec-Umsetzung von AVM ist noch schlechter als die aktuelle WG Umsetzung. Das funktioniert einfach zuverlässig nicht.
Auch ist die Software die man von AVM für das IPsec-VPN bekommt, der letzte Rotz. Gefühlt 2007 letztes Update bekommen.

Es sollte eigentlich bekannt sein, daß wenn man zuverlässiges VPN will, nicht das von der Fritzbox nimmt. Das IPSEC kann man als Notbehelf für gelegentliche Verbindungen nehmen, aber nicht für den Produktivbetrieb und wireguard ist sowieo noch nicht offiziell verfügbar für die Fritten.

Wenn man zuverlässiges VPN braucht, tauscht man die Fritte halt gegen was anderes oder hängt einen VPN-Server hinter die Fritte (z.B. openVPN, Wireguard, IPSEC, etc ).

lks

Hallo,

Es gibt schon n Grund warum man auf WireGuard umsteigt, die IPsec-Umsetzung von AVM
ist noch schlechter als die aktuelle WG Umsetzung. Das funktioniert einfach zuverlässig nicht.

Also man sollte auch immer unterscheiden, ob das nun für eine Firma oder den Privatgebrauch ist.
IPSec kann, AVM, pfSense, SoftEtherVPN und fast alle am Markt befindlichen Router oder Firewalls
von Haus aus und die Android und iOS Geräte unterstützen das auch. Also ich finde eher das man
es auch so herum sehen kann.

Auch ist die Software die man von AVM für das IPsec-VPN bekommt, der letzte Rotz. Gefühlt 2007
letztes Update bekommen.

Mit meinem iPhone 11 in 15 Minuten angelegt und funktioniert out-of-the-box.

Also ich muss sagen so sehr ich die Fritz!Boxen mag, die WireGuard-Geschichte läuft echt nicht
gut für AVM.

IPSec ist lange am Markt und gut überprüft
OpenVPN ist der defacto Standard
Und WireGuard der neue Hoffnungsschimmer am Horizont

Es gibt immer Vor- und Nachteile zu jedem Verfahren, nur wenn ich möglichst kompatibel sein möchte
ist eben IPSec das Mittel der Wahl, und wenn es einfach sein soll denn OpenVPN und wenn der Durchsatz
eine größere Rolle Spielt dann ist WireGuard sicherlich eine Überlegung wert. Und selbst Stunnel und Tinc
haben Netz (LAN) intern Ihre Berechtigung und Ihren Nutzen in größeren Netzwerken.

Dobby

Joa, VPN-Lösungen von AVM benutzen

Solange es für den Heimbereich ist und auch bleibt, ist das ja durchaus ok.

In Firmennetzen ein NoGo!!
Kollege @3803037559 hat hier aber Recht das IPsec absolut performancegleich zu WG ist auf dem jeweils gleichen AVM Modell. Der TO macht da dann wirklich etwas falsch...

Weiß ich nicht: Eine VPN-Lösung muss halt funktionieren, egal ob privat oder in der Firma.
Und dass IPsec und WG performancegleich sind auf einer FB ist Quatsch:
https://www.netzwelt.de/news/197094-avm-zuendet-vpn-turbo-wireguard-bald ...

Na ja... popelige 6 Mbit Unterschied. Merken Anwender niemals und ist lächerlich. Entspricht übrigens auch den offiziellen Tests.

Im Vergleich zu professionellen Routern bleibt das mickrig weil es eben per se am schwachbrüstigen SoC eines einfachen Consumer Routers scheitert. Genau der Grund warum AVM in Firmennetzen nichts zu suchen hat.
Gut...Ausnahme bei Meister Röhricht aber da gibts nur 2 Mitarbeiter mit Werner und Ekkehard. Da tuts dann sicher auch ein AVM. 🤣

Der NetBiOS Zugriff funktioniert mit der aktuellen Beta bei Wireguard wieder. Auch das Tunneln des gesamten remoten Traffics. (Gateway Redirect mit "Allowed IPs 0.0.0.0/0")
https://www.heise.de/news/FritzOS-7-50-am-Horizont-Neues-Labor-Update-fu ...

Hallo zusammen,

mit der heute erschienene Labor Version (für die 7590 und 7590ax) funktioniert der SMB Zugriff über WG wieder.
Was ich aber nicht hinbekomme ist eine IPSec Verbindung mit Windows Boardmitteln herzustellen. In der aktuellen Labor Version soll nun ja eigentlich das Protokoll IKEv2 unterstützt werden.

Hat da noch jemand einen Rat für mich?

Grüße

Unter Windows muss man für IKEv2 die Proposals für Phase 1 und 2 mit der PowerShell an die von AVM supporten anpassen.

Davon habe ich gelesen. Kennst du den passenden PS Befehl ??

Zitat von @tobias3355:

Davon habe ich gelesen. Kennst du den passenden PS Befehl ??

Ja, bitte
Set-VPNConnectionIPSecConfiguration

Leider finde ich irgends die zu AVM passenden Parameter. Wie lauten diese?
bzw. noch besser wäre es, wenn jemand den fertigen PS Befehl für mich hat?

Grüße

Zitat von @tobias3355:

Leider finde ich irgends die zu AVM passenden Parameter. Wie lauten diese?
bzw. noch besser wäre es, wenn jemand den fertigen PS Befehl für mich hat?

Grüße

Servus Tobias,
da muss ich dich leider enttäuschen, aber der in Windows integrierte IKEv2 Client unterstützt kein IKEv2 mittels PresharedKey, was die Fritzbox aber voraussetzt. Ein Anpassen der Proposals bringt also rein gar nichts weil die entsprechende Auth Methode Windows schlicht fehlt. Windows 10/11 unterstützt bei Wahl von IKEv2 nur EAP-MSCHAPv2, (P)EAP-TLS, EAP-TTLS, EAP-SIM, EAP-AKA, alles Methoden welche die Fritzbox aber nicht spricht.

Die Anmerkung im Beta-Changelog das nun auch IKEv2 unterstützt wird galt hauptsächlich für das in Android 12 unterstützte Verfahren von IKEv2 mittels PresharedKey, damit man unter Android den bordeigenen Client nutzen kann. Leider mal wieder nur halbgar umgesetzt das ganze, denn IKEv2 mittels PSK bringt ehrlich gesagt keinen Vorteil zu IKEv1 mit PSK. Wenn man schon IKEv2 Support an Bord hat warum nicht gleich ordentlich umsetzen... Würde man mal ein halbwegs aktuelle Version von Strongswan/charon daemon auf dem Router einsetzen wären all diese Umwege Geschichte, denn damit würden alle möglichen IPSec Verfahren supported die es so auf dem Markt gibt. Aber nun ja, es ist und bleibt ein Router für das Consumer-Segment und für den Großteil der User ist dann Wireguard eh die einfachere Wahl.

Grüße Uwe

der in Windows integrierte IKEv2 Client unterstützt kein IKEv2 mittels PresharedKey

Siehe dazu auch hier wo dies mit den bordeigenen Windows IKEv2 Clients beschreiben ist.

Zitat von @aqui:

der in Windows integrierte IKEv2 Client unterstützt kein IKEv2 mittels PresharedKey

Siehe dazu auch hier wo dies mit den bordeigenen Windows IKEv2 Clients beschreiben ist.

Ändert nur leider nichts daran das die Fritze in der Beta bei Nutzung von IKEv2 nur den ehrlich gesagt selten genutzten PresharedKey unterstützt, Windows aber nicht @aqui.

Da hast du natürlich Recht. Es sollte auch nur nochmal unterstreichen das es auch besser geht wenn man es richtig implementiert! 😉

Zitat von @aqui:

Da hast du natürlich Recht. Es sollte auch nur nochmal unterstreichen das es auch besser geht wenn man es richtig implementiert! 😉

Na dann 👍 , schönes Wochenende.

Guten morgen,

seit gestern wurde im aktuellen Fritz Labor auch für meine Fritzbox 6690 der "SMB Fehler" bei einer WG Verbindung behoben. Was aber noch besser ist, dass der Durchsatz durch "Hardwarebeschleunigung" deutlich gesteigert wurde. Ich habe eine 1000/50 Mbit/s Leitung. Wenn ich aus der Ferne auf mein Netzwerk zugreife, kann ich theoretisch rund 6-7 MB/s erreichen. Es waren aber immer nur 1-2 MB/s. Nun sind es rund 5-6 MB/s !! So lässt sich auch das VPN der Fritzbox gut nutzen.

Grüße

gelöst Frage Netzwerke LAN, WAN, Wireless

Mehr von tobias3355

Chkdsk Neustart ohne Rückfragetobias3355 - 15 Kommentare

Bitmap-Bild (.bmp) aus dem Kontextmenü "Neu" entfernen - W11tobias3355 - 5 Kommentare

Explorer Ansicht unter Windows 11 24H2 änderntobias3355 - 8 Kommentare

Lokale GPO zum Server 2022 hinzufügentobias3355 - 11 Kommentare

Heiß diskutiert