Mar 26, 2020

1910

Verrücktes Netzwerkproblem in einer alten SBS 2008 Domäne

Hallo zusammen,

ich bin hier leider sehr verzweifelt und ersuche deshalb in Eurer Community ein paar Ideen oder Ansätze zur Fehlerbehebung.
Hier läuft (noch) ein SBS2008 als DC, dazu rund 20 Stationen (zumeist WIN7PRO, jedoch auch einige Apple Endgeräte wie MacBooks, iPhones und iPads).
Firewall ist ebenfalls ein altes Schätzchen - eine Draytek 5510. Halt ohne UTM, aber dafür klassische Firewallfunktionen.
Netzwerkinfrastruktur ist ein Unifi-UBNT mit mehreren Switches und einigen AP.

Somit hier der Netzwerkaufbau:

Gateway (Zyxel-Kiste vom ISP - ohne Admin-Möglichkeit meinerseits)
\/
Firewall (Draytek VigorPro 5510)
\/
Unifi Switch 48
\/
Server, Stationen und weitere Switches

Es sind keine VLANs o.ä. eingerichtet.

Der Fehler zeigt sich wie folgt:
Manche Stationen bekommen keine Verbindung ins WAN.
Ping und NSLOOKUP funktionieren an den betroffenen Stationen jedoch fehlerfrei.

Interessant ist, dass ein NSLOOKUP mit der Angabe eines externen DNS-Servers (egal ob 1.1.1.1 oder 8.8.8.8 o.ä.) an den betroffenen Stationen zu DNS time outs (mal mehr, mal weniger) führt.
Da der DC aber ja eigentlich das Forwarding macht (und das auch offenbar zuverlässig funktioniert), ist das mit den externen DNS-Servern nebst Timeout-Fehler nur zufällig aufgefallen.

Ein andere interessante Sache ist ein Hyper-V Host im Netz. Auf diesem laufen drei Gastsysteme - somit in Summe vier Systeme (Host + 3 x Gast) über eine physikalische NIC.
Der Host und ein Gast zeigen den o.a. Fehler - die zwei anderen Gäste jedoch nicht!

Die Firewall ist nicht benutzerbezogen eingerichtet, macht also hier keinen Unterschied.

Habe auch mal den Host direkt an der Firewall angeschlossen (um die Unifi Geräte auszuschließen) - das Fehlerbild bleibt unverändert bestehen.

Somit kann doch eigentlich nur noch die Firewall oder der ISP als Ursache übrig bleiben?
Lt. ISP ist bei denen jedoch alles OK.

Da der Fehler bei 75% aller Netzwerkteilnehmer nicht auftritt, tue ich mich mit der Lokalisierung der Fehlerursache wahnsinnig schwer.

Vielleicht hatte ja jemand hier in den Community schon mal mit einem ähnlichen Fehler zu tun und kann mir einen Tipp geben?
Ich bin nämlich wirklich sehr verzweifelt

Danke Euch schon mal vorab!

Bis bald

Please also mark the comments that contributed to the solution of the article

Content-Key: 561055

Url: https://administrator.de/contentid/561055

Printed on: April 23, 2024 at 20:04 o'clock

36 Comments

Latest comment

Ach so: selbst ein kurzfristiges, testweises Deaktivieren der Firewall-Funktionen brachte keine Veränderung der Lage mit sich!

Zitat von @PA-Peter:

Hallo zusammen,

Hi,

Interessant ist, dass ein NSLOOKUP mit der Angabe eines externen DNS-Servers (egal ob 1.1.1.1 oder 8.8.8.8 o.ä.) an den betroffenen Stationen zu DNS time outs (mal mehr, mal weniger) führt.

Das ist komplett irrelevant, in einer Domäne muss DNS-technisch alles über die dortigen DNS-Server (idR sind das bei KMU auch die DCs) laufen. Alles andere ist belanglos.

Da der Fehler bei 75% aller Netzwerkteilnehmer nicht auftritt, tue ich mich mit der Lokalisierung der Fehlerursache wahnsinnig schwer.

Ins Blaue rein geraten besteht die DNS-Konfiguration bei euren Clients aus Kraut und Rüben.

Kurz: Wenn euer SBS2008 DC auch gleichzeitig DNS-Server ist, muss dieser Server bei all euren Clients als primärer DNS hinterlegt sein, kein Google doer sonstiger Mist und unabhängig ob über DHCP oder Static-IP. Prüf das mal durch.

Moin,

Zitat von @chgorges:
Kurz: Wenn euer SBS2008 DC auch gleichzeitig DNS-Server ist, muss dieser Server bei all euren Clients als primärer DNS hinterlegt sein, kein Google doer sonstiger Mist und unabhängig ob über DHCP oder Static-IP. Prüf das mal durch.

das war auch mein erster Gedanke. Kann aber eigentlich nicht sein, weil trotzdem das nslookup mit angegebenen DNS-Server funktionieren müsste. Also eher ein Gateway-Problem (Konfiguration prüfen) oder eben eine Firewall die quer schießt.
Was an Info fehlt ist, ob der TO das Netzwerk auf Fehler geprüft hat. Es kann ja durchaus ein Switch ne Macke haben - dann gäbe es im allgemeinen aber noch andere Probleme.

Zitat von @chgorges:

Kurz: Wenn euer SBS2008 DC auch gleichzeitig DNS-Server ist, muss dieser Server bei all euren Clients als primärer DNS hinterlegt sein, kein Google doer sonstiger Mist und unabhängig ob über DHCP oder Static-IP. Prüf das mal durch.

Das ist so - wird hier via DHCP so verteilt - bei allen Stationen steht der DC (192.168.100.1) als DNS-Server drin. Keine weitere Eintragungen.
Das habe ich auch schon mehrfach geprüft.
Wie gesagt: die Namensauflösung via NSLOOKUP/PING funktioniert an allen betroffenen Stationen einwandfrei.
Es wäre ja auch viel zu schön um wahr zu sein, wenn dieser Fehler so einfach zu lösen wäre

Klar, der DNS-Time-Out via externem DNS-Server ist eigentlich belanglos - jedoch tritt er eben *ausschließlich* an den Stationen auf, die den beschriebenen Fehler zeigen.

Zitat von @Kraemer:

Moin,

Was an Info fehlt ist, ob der TO das Netzwerk auf Fehler geprüft hat. Es kann ja durchaus ein Switch ne Macke haben - dann gäbe es im allgemeinen aber noch andere Probleme.

Was kann/sollte ich hier prüfen? Also wo setze ich am besten an?
Die Firewall hat vier LAN-Ports - ich habe mal den beschriebenen Hyper-V-Host vom Hauptswitch direkt auf die Firewall gesteckt und das Fehlerbild ist mit gewandert.

Im Grunde genommen verlangt die Logik, dass der Fehler an der Firewall liegt - aber da finde ich nun auch keinen weiteren Ansatz mehr

Zitat von @Kraemer:

Also eher ein Gateway-Problem (Konfiguration prüfen) oder eben eine Firewall die quer schießt.

Was das Gateway betrifft:
Das ist ne Zyxel-Kiste vom lokalen ISP - da kann ich nichts dran machen. Die Frage ist, was die Kiste zu dem Fehler beitragen könnte? Wie gesagt, die Fehler treten nachvollziehbar nur an vereinzelten Clients auf.

An deiner Stelle würde ich erst einmal mit einem tracert anfangen. Dann siehst du schon einmal wo es stocken könnte.
Bei Fehlern, die sporadisch auftreten, würde ich mir auch mal die MTU vornehmen.

Zitat von @Kraemer:

An deiner Stelle würde ich erst einmal mit einem tracert anfangen. Dann siehst du schon einmal wo es stocken könnte.

Ein Trace bringt an betroffenen und nicht betroffenen Stationen das gleiche Ergebnis. Auch das hatte ich schon vorab versucht.

Bei Fehlern, die sporadisch auftreten, würde ich mir auch mal die MTU vornehmen.

Habe ich angepasst. Hat aber leider auch nichts an der Sache verändert

Zitat von @PA-Peter:
Ein Trace bringt an betroffenen und nicht betroffenen Stationen das gleiche Ergebnis. Auch das hatte ich schon vorab versucht.

was ist denn jetzt das gleiche Ergebnis? Das es funktioniert oder das es nicht funktioniert?

Zitat von @Kraemer:

was ist denn jetzt das gleiche Ergebnis? Das es funktioniert oder das es nicht funktioniert?

Ja, es funktioniert offenbar (oder ich übersehe was Essentielles??):

Routenverfolgung zu haribo.com [87.230.97.234] über maximal 30 Abschnitte:

1 <1 ms <1 ms <1 ms 192.168.100.254
2 8 ms 9 ms 13 ms gw-rieckmedia.bn-online.net [217.76.104.145]
3 * * * Zeitüberschreitung der Anforderung.
4 27 ms 39 ms 26 ms dus1.blatzheim.com [217.76.104.248]
5 37 ms 39 ms 26 ms ve300.edge1-dus1.mesh.eu [194.146.118.2]
6 40 ms * 53 ms ae3.cr1.cgn3.plusserver.com [62.138.225.37]
7 35 ms 29 ms 32 ms n87-230-97-234.cnet.hosteurope.de [87.230.97.234]

Gleiches Bild an allen Stationen.

Moin,

Zitat von @PA-Peter:
Manche Stationen bekommen keine Verbindung ins WAN.
Ping und NSLOOKUP funktionieren an den betroffenen Stationen jedoch fehlerfrei.

Was denn nun? Wenn ping auf eine externe IP und ping auf einen externen Hostname gehen, dann bekommen die Stationen eine Verbindung ins WAN. Definiere bitte "Bekommen keine Verbindung ins WAN" näher. Was genau geht nicht und was geht?

Liebe Grüße

Erik

Zitat von @erikro:

Moin,

Was denn nun? Wenn ping auf eine externe IP und ping auf einen externen Hostname gehen, dann bekommen die Stationen eine Verbindung ins WAN. Definiere bitte "Bekommen keine Verbindung ins WAN" näher. Was genau geht nicht und was geht?

Liebe Grüße

Erik

OK, sorry für meine "flache" Ausdrucksweise :-o
An den betroffenen Stationen ist via Webbrowser kein Zugriff auf das WAN möglich.
Ebenso können z.B. Anwendungen keine Updates ziehen etc.

Der lokale Netzwerkbetrieb (Outlook, Datei- und Druckerfreigabe, Sharepoint etc) ist gegeben.

Moin,

ping externeIP geht? Dann ist die Verbindung vorhanden. nslookup externe.domain.tld geht? Dann ist es auch kein DNS-Problem. Was nicht geht ist externe.domain.tld in der Adresszeile des Browsers, obwohl nslookup die korrekte IP liefert und der Server anpingbar ist? Es geht auch kein anderer Dienst (email, ssh, ftp oder ...)? Was steht denn in der Statuszeile des Browsers? Was sagt die Ereignisanzeige?

Liebe Grüße

Erik

Zitat von @erikro:

ping externeIP geht? Dann ist die Verbindung vorhanden. nslookup externe.domain.tld geht?

Ja - so siehts aus!

Dann ist es auch kein DNS-Problem.

Habe ich ja auch nicht gesagt - es ist nur (m.M.n.) auffallend, dass der Unifi Controller sporadisch bei manchen Clients einen DNS Time Out gemeldet hat und das das o.b. Verhalten an den betroffenen Stationen immer nachvollziehbar ist!

Was nicht geht ist externe.domain.tld in der Adresszeile des Browsers, obwohl nslookup die korrekte IP liefert und der Server anpingbar ist? Es geht auch kein anderer Dienst (email, ssh, ftp oder ...)? Was steht denn in der Statuszeile des Browsers? Was sagt die Ereignisanzeige?

Ereignisanzeige zeigt leider nichts Entsprechendes. Es gab mal einen DNS Fehler - aber kein erkennbares System.
Und andere Dienste habe ich mal spaßeshalber mit Telnet getestet - an den betroffenen Stationen kommt auf den entsprechenden Ports keine Verbindung zustande.
Browser zeigt in der Statuszeile, dass er auf Antwort wartet und dann kommt "Die Seite kann nicht angezeigt werden"

Noch mal:
Wenn es sich um ein netzweites, einheitliches Problem handeln würde, wüsste ich durchaus, wo ich anzusetzen habe...
...aber so macht es mich einfach kirre, dass ich das nicht weiter einkreisen kann

Ich danke Euch trotzdem für Eure Gedanken - im schlimmsten Fall ist es doch etwas Banales, an das ich nicht denke?!

Moin,

Zitat von @PA-Peter:

Zitat von @erikro:

ping externeIP geht? Dann ist die Verbindung vorhanden. nslookup externe.domain.tld geht?

Ja - so siehts aus!

Dann ist es auch kein DNS-Problem.

Das war auch eher ein Kommentar zu den bisherigen Lösungsansätzen der Kollegen.

Firewall. Irgenwo unterwegs schließt irgendwas die Ports. Ich ahne mal, dass der Grund, den der Browser angibt, ein Timeout ist. Welcher Browser ist es denn?

Wenn er sagt, dass er auf Antwort wartet, dann hat er die Adresse richtig aufgelöst und versucht nun eine Verbindung herzustellen. Er hat also ein entsprechendes Paket an den Server gesendet. Das kommt entweder nicht raus oder die Antwort kommt nicht rein. Da ja der interne Verkehr störungsfrei verläuft, dürften die Leitungen, Switches etc. in Ordnung sein. Sonst hättest Du auch beim lokalen Verkehr Probleme.

Da das nicht das ganze Netz betrifft, würde ich erstmal nach Gemeinsamkeiten der betroffenen Geräte suchen (gleiche OU, gleicher Switch, gleiches BS mit gleichem Updatestand, gleiche Softwareausstattung etc.). Anhand dieser Gemeinsamkeiten würde ich nach einem Gerät oder einer Software suchen, die die Ports nach außen blockiert. <edit>Wireshark ist Dein Freund.</edit>

Ging es denn jemals mit den betroffenen Geräten?

hth

Erik

Übrigens zeigt Windows unten rechts bei der Verbindung an, dass keine Internetverbindung bestehen würde...

Zitat von @erikro:

Firewall. Irgenwo unterwegs schließt irgendwas die Ports. Ich ahne mal, dass der Grund, den der Browser angibt, ein Timeout ist. Welcher Browser ist es denn?

Ich habe sowie den IE als auch Firefox getestet...

Wenn er sagt, dass er auf Antwort wartet, dann hat er die Adresse richtig aufgelöst und versucht nun eine Verbindung herzustellen. Er hat also ein entsprechendes Paket an den Server gesendet. Das kommt entweder nicht raus oder die Antwort kommt nicht rein. Da ja der interne Verkehr störungsfrei verläuft, dürften die Leitungen, Switches etc. in Ordnung sein. Sonst hättest Du auch beim lokalen Verkehr Probleme.

Ja, korrekt - die Adresse wird sichtbar in der Statuszeile aufgelöst - aber es kommt halt nix zurück.

Da das nicht das ganze Netz betrifft, würde ich erstmal nach Gemeinsamkeiten der betroffenen Geräte suchen (gleiche OU, gleicher Switch, gleiches BS mit gleichem Updatestand, gleiche Softwareausstattung etc.). Anhand dieser Gemeinsamkeiten würde ich nach einem Gerät oder einer Software suchen, die die Ports nach außen blockiert. <edit>Wireshark ist Dein Freund.</edit>

Tja, alleine das Problem an dem HyperV-Host mit seinen 3 Gästen zeigt, dass das Problem diffiziler als gedacht ist:
-> hier gehen 4 Systeme (Host plus drei Gäste) über die gleiche physikalische Verbindung ins Netz...
...ein WIN7PRO Gast zeigt den Fehler und der Host ebenso. Der S2008R2 sowie der WIN7ENT Gast zeigen keinen Fehler.
Arg!

Ging es denn jemals mit den betroffenen Geräten?

Ja, bis Freitag letzte Woche - seit dem suche ich

Am Freitag hat der ISP unsere Leitung auf 100.000/20.000 "upgegradet". Der Ball, dass es vielleicht bei denen liegen würde, wurde aber gleich zu mir zurück gespielt

Zitat von @PA-Peter:

Übrigens zeigt Windows unten rechts bei der Verbindung an, dass keine Internetverbindung bestehen würde...

Kein Wunder. Windows prüft da die Erreichbarkeit irgend eines MS-Servers. Wenn der nicht erreichbar ist, dann ist das gelbe Ausrufezeichen da. Darauf gebe ich schon lange nichts mehr.

Ach so:
Freitag habe ich den Port 8013 für das VPN meiner Frau (sie muss halt Homeoffice machen) geöffnet...
...das ist jedoch die einzige Änderung, die ich vorgenommen habe.
Die VPN-Kiste ihres Arbeitgebers fährt über diesen Port irgendwie die Lizenzierung des Clients. Der eigentliche Betrieb geht über Port 443.

Ich kann aber keinen Zusammenhang mit dem 8013er und diesem Problem sehen - oder übersehe ich da was?

Zitat von @PA-Peter:

Zitat von @erikro:

Firewall. Irgenwo unterwegs schließt irgendwas die Ports. Ich ahne mal, dass der Grund, den der Browser angibt, ein Timeout ist. Welcher Browser ist es denn?

Ich habe sowie den IE als auch Firefox getestet...

Beim IE steht immer ganz unten auf der Fehlerseite das wahre Problem. Bei Firefox eigentlich in der Überschrift. Deshalb die Rückfrage.

Die physische Verbindung ist irrelevant. Die funktioniert. Es sind aber logisch vier verschiedene Rechner. Sind die alle im gleichen Netz oder verschiedene VLANs? Aber diese Situation verschafft Dir einen Vorteil. Du kannst mit dem Wireshark auf der physischen Karte auf dem Host sniffen. Da solltest Du dann alle Pakete und alle Verbindungen sehen können. Dann siehst Du, warum die eine geht und die andere nicht.

Ja, bis Freitag letzte Woche - seit dem suche ich

Am Freitag hat der ISP unsere Leitung auf 100.000/20.000 "upgegradet". Der Ball, dass es vielleicht bei denen liegen würde, wurde aber gleich zu mir zurück gespielt

Aha. Und warum erfahren wir das jetzt erst?

Was hat sich denn alles am Netz dadurch geändert? Externe IP? Neue Hardware? Neuer Router? ...

Liebe Grüße

Erik

Zitat von @PA-Peter:

Ach so:
Freitag habe ich den Port 8013 für das VPN meiner Frau (sie muss halt Homeoffice machen) geöffnet...
...das ist jedoch die einzige Änderung, die ich vorgenommen habe.
Die VPN-Kiste ihres Arbeitgebers fährt über diesen Port irgendwie die Lizenzierung des Clients. Der eigentliche Betrieb geht über Port 443.

Ich kann aber keinen Zusammenhang mit dem 8013er und diesem Problem sehen - oder übersehe ich da was?

Mach die Änderung doch einfach mal rückgängig, wenn Deine Frau Feierabend hat. Dann wirst Du ja sehen, ob das die Ursache ist oder nicht. Wenn ja, dann überlegen wir weiter, warum.

Hallo,

IP doppelt vergeben?

Gruß,
Jörg

Zitat von @erikro:

Aha. Und warum erfahren wir das jetzt erst?

Was hat sich denn alles am Netz dadurch geändert? Externe IP? Neue Hardware? Neuer Router? ...

Weil es lt ISP nichts verändert hat.
Gleiche Hardware, gleiche IP-Adressen etc.
Lediglich größere Bandbreite.

Zitat von @erikro:
Mach die Änderung doch einfach mal rückgängig, wenn Deine Frau Feierabend hat. Dann wirst Du ja sehen, ob das die Ursache ist oder nicht. Wenn ja, dann überlegen wir weiter, warum.

Mehrfach versucht. Das Laptop meiner Frau (WIN10) ist aber auch betroffen - sie kann über unser Netz hier z.Zt. nicht arbeiten.
Kein VPN, kein Outlook, kein INet.

Zitat von @117471:

Hallo,

IP doppelt vergeben?

Gruß,
Jörg

Habe ich auch schon vermutet - finde aber nichts in den Protokollen der Stationen.

Gibt es irgendwo eine Art HowTo was Wireshark betrifft - also ein Vorschlag zur gezielten Herangehensweise?

Zitat von @PA-Peter:
Weil es lt ISP nichts verändert hat.
Gleiche Hardware, gleiche IP-Adressen etc.
Lediglich größere Bandbreite.

Also auch keine neue Hardware und keine Veränderungen in den Einstellungen des Routers/Modems?

Zitat von @PA-Peter:

Mehrfach versucht.

Das hatte ich schon befürchtet.

Wäre aber auch zu einfach gewesen.

Das Laptop meiner Frau (WIN10) ist aber auch betroffen - sie kann über unser Netz hier z.Zt. nicht arbeiten.
Kein VPN, kein Outlook, kein INet.

Das ist ganz schlecht in diesen Zeiten. Wie macht sie VPN? Die Protokolle des Verbindungsaufbaus sind recht geschwätzig. Vielleicht findet man da was hilfreiches.

Ich hätte noch eine Idee: IPv6. Ist das auf allen Maschinen aktiviert?

Moin,

Zitat von @117471:

Hallo,

IP doppelt vergeben?

Den Gedanken hatte ich auch, als ich VPN las. Zwei Netze mit der gleichen Adresse. Aber es geht ja auch nicht, wenn VPN aus ist.

Liebe Grüße

Erik

Zitat von @erikro:
Das ist ganz schlecht in diesen Zeiten. Wie macht sie VPN? Die Protokolle des Verbindungsaufbaus sind recht geschwätzig. Vielleicht findet man da was hilfreiches.

Da läuft die Software Forticlient auf ihrem Rechner - das lief mit deren Demoversion wohl fast ne Woche stressfrei. Für den regulären Betrieb musste der Port 8013 frei gemacht werden. Zeitlich steht das ein wenig mit den Problemen im Zusammenhang...
...aber m.M.n. nur zeitlich.
Aktivieren und Deaktivieren der zusätzlichen Firewallregel ändert nichts an der Situation.

Ich hätte noch eine Idee: IPv6. Ist das auf allen Maschinen aktiviert?

Ja, aber nicht einrichtet - die stehen alle auf "dynamisch", der DHCP verteilt aber keine v6 Adressen, lediglich v4.

Guten morgen,

ich muss gestehen, ich habe gerade alles nur überflogen.

So ein Problem hatte ich mal an einem Rechner, bei dem 2 AV Lösungen installiert waren, Ping ging aber kein Aufruf einer Seite.
Was passiert denn, wenn du "Google" testweise versuchst über die IP Adresse zu öffnen, anstatt über "Google.de"?

Gruß

Moin,

habe gestern das hier gelesen https://www.borncity.com/blog/2020/03/26/windows-10-bug-verhindert-inter ... und musste gleich an den Thread denken.

Den Gedanken hatte ich auch, als ich VPN las. Zwei Netze mit der gleichen Adresse. Aber es geht ja auch nicht, wenn VPN aus ist.

Das muss ja nichts heißen, das Tunnelinterface und ggf. irgendwelche Filter-/Tunneltreiber sind weiterhin aktiv. Evtl. mal mit Deinstallation des VPN-Clients weitermachen?

Tach,

um die lokale Faktoren/Einstellungen auszuschließen würde ich an einem der "Problem-Computer" ein Livesystem (Win/Lin) ausprobieren.

Wenn es dann klappt dürfte die Netzwerkstruktur an sich OK sein und die Nadel liegt im Windows-Heuhaufen...
und wie der Vorredner sagt, irgend ein Netzwerkfilter einer FW oder eines AV könnte dazwischen funken.

Viel Erfolg

Zitat von @chgorges:

Das muss ja nichts heißen, das Tunnelinterface und ggf. irgendwelche Filter-/Tunneltreiber sind weiterhin aktiv. Evtl. mal mit Deinstallation des VPN-Clients weitermachen?

Da komme ich ja leider nicht ran - ist Hardware der Firma meiner Frau (kein kleiner Laden) und entsprechend abgesichert...

Zitat von @chgorges:

Moin,

habe gestern das hier gelesen https://www.borncity.com/blog/2020/03/26/windows-10-bug-verhindert-inter ... und musste gleich an den Thread denken.

Die Schwierigkeit hier ist, dass ja auch ein WIN7PRO sowie ein S2008R2 die gleiche Problematik zeigt.

Gerade eben haben habe ich -weils eh erforderlich war- einen WIN10 client aufgesetzt. Dieser spielt einwandfrei.
Ein betroffener Client ist ja auch ein iPhone.

Ich denke immer mehr, dass es vielleicht doch von der Firewall kommen muss - auch wenn die keine Auffälligkeiten im Log und in der Einrichtung zeigt.

Moin,

Zitat von @PA-Peter:

Zitat von @chgorges:

Das muss ja nichts heißen, das Tunnelinterface und ggf. irgendwelche Filter-/Tunneltreiber sind weiterhin aktiv. Evtl. mal mit Deinstallation des VPN-Clients weitermachen?

Da komme ich ja leider nicht ran - ist Hardware der Firma meiner Frau (kein kleiner Laden) und entsprechend abgesichert...

Aber der VPN-Client spielt spätestens dann keine Rolle mehr, wenn das Notebook Deiner Frau aus ist. Wenn der Fehler dann immer noch auftritt, ist sie unschuldig.

Liebe Grüße

Erik

Ja. Sie bzw ihr Rechner ist def nicht schuld an dem Problem.
Wireshark meldet an dem einen betroffenen HyperV Client sporadisch einen nicht erreichbaren Port. Ich habe leider zu wenig Erfahrung mit der Auswertung der Daten um das bewerten zu können 😔

German Question Network Management Networks

Hotly discussed

Check of ZFW Firewallgleixnerd - 5 Comments

Wireguard VPN on UDM Pro behind Fritzbox - Handshake did not completejstricker - 3 Comments

How to set up and configure a Linux GRE tunnelAlexWisha - 3 Comments