Einem Bekannten habe ich eine VPN-Verbindung zwischen seinem Laptop (Win10) und der Fritzbox im Büro eingerichtet. Dazu habe ich auf dem Laptop die neueste Version des Shrew Soft VPN Client im Standard-Mode genommen, in der Fritzbox ist ein entsprechender User eingerichtet (mit den von der Fritz-GUI gegebenen Optionen). Gestern hat Alles nach 5 Minuten Teamviewer-Sitzung funktioniert und alle waren happy. Heute morgen geht plötzlich nix mehr: Der Client bleibt in der Statusanzeige bei "establishing tunnel" (o.ä.) hängen und wirft nach ca. 30s ein Timeout. Alle anderen Internet-Verbindungen (Surfen, Mail, Netflix, Skype ... alles funktioniert). Es spielt auch keine Rolle, ob er per WAN oder LAN an seine Fritzbox geht. Folgendes wurde heute geprüft bzw. gemacht: - Fritzboxen zuhause und im Büro haben verschiedene Subnets - Erreichbarkeit von myfritz.net (dyndns) zum Büro gecheckt, ist ok - Shrew Client neu installiert - Ich habe die gleiche Verbindung von mir aus gecheckt, geht sowohl vom Macbook mit Bordmitteln als auch aus einer VM mit Win10 und Shrew - leider wohnt er in einer Gegend, wo Handy als testweise Internetzugang nicht funktionert, also immer nur 1und1 DSL Was kann man noch tun?
:
Bearbeitet durch User
Frank E. schrieb: > Was kann man noch tun? Erst mal die einfachen Sachen wie -FB 1x stromlos versucht? -Bei dynamischer IP würde ich jetzt nochmals die IP prüfen die seine FB hat und die er aktuell nun eingestellt hat? -Es könnte natürlich auch administrative Richtlinien geben, die Büro-Usern den Spaß verderben (Sicherheit)?
Frank E. schrieb: > Was kann man noch tun? Natürlich: Schauen, ob die Pakete überhaupt ankommen. Siehe https://hardez.de/tcpdump-mit-der-fritzbox/ für die Fritzbox und natürlich Wireshark für den Büro-PC. Aber: Wenn's plötzlich nicht mehr geht und an der Konfiguration nichts geändert wurde, ist sehr wahrscheinlich, dass administrative Massnahmen irgendwo auf der Strecke der Pakete dafür sorgen, dass sie eben nicht mehr ankommen. Im konkreten Fall vermutlich: der Admin deiner Firma hat Port 500 und/oder Port 4500 UDP ausgehend dicht gemacht, womit IPSEC/NAT-T aus dem Büro nicht mehr funktionieren kann. Wenn das so ist, dann wünscht die Firma offensichtlich nicht, dass VPN-Verbindungen nach aussen aufgebaut werden. Du solltest dich diesem Wunsch fügen, wenn dir an deinem Job was liegt...
Danke, dass ihr euch die Mühe gemacht habt, zu antworten. Aber die Basis für die Vorschläge sind alle bereits im Eingangspost ausgeräumt worden: - ich komme dort per VPN rein, nur der Chef nicht (von Zuhause aus) - es hat einen Tag zuvor funktioniert - es gibt keinen Admin, der irgendwas verstellen könnte und ich war es nicht Mir ist schon klar, dass es eine Ursache geben muss, Wunder gibt es in dem Bereich kaum. Heute wird Chef es mal von einem anderen Standort aus versuchen, um erstmal herauszufinden, ob das Problem in seinem heimischen Netz liegt oder auf seinem Laptop ...
:
Bearbeitet durch User
Da würde mir zuerst eine Firewall Einstellung auf dem Win10 Laptop einfallen.
Frank E. schrieb: > > > Was kann man noch tun? Fritzbox und Shrewsoft sind leider nicht besonders auskunftsfreudig, was Fehlermeldungen angeht. Auf dem betreffenden Notebook kann man mit Wireshark den Verbindungsaufbau überprüfen. Oder, etwas aufwendiger, vor der Einwahl-Fritzbox mit einem Ethernet-TAP oder Switch mit Monitor-Port den eingehenden Verbindungsaufbau überprüfen. Viel Erfolg Grüße M.
Michael W. schrieb: > Fritzbox und Shrewsoft sind leider nicht besonders auskunftsfreudig, was > Fehlermeldungen angeht. Naja, zumindest das VPN Trace Utility von Shrew hilft schon ein wenig.
Neuester Stand: Ausserhalb des heimischen LAN/DSL funtioniert der Zugang ins Büro (wieder). Also steckt das Problem in der heimischen/ausgehenden Fritzbox oder bei 1und1/DSL. Nach wie vor mysteriös: Einen Tag zuvor hat es auch von Zuhause aus funktionert. Und es war definitiv niemand (soweit bekannt) an der heimischen Fritzbox.
Michael W. schrieb: > Frank E. schrieb: >> > >> Was kann man noch tun? > Fritzbox und Shrewsoft sind leider nicht besonders auskunftsfreudig, was > Fehlermeldungen angeht. > Auf dem betreffenden Notebook kann man mit Wireshark den > Verbindungsaufbau überprüfen. > Oder, etwas aufwendiger, vor der Einwahl-Fritzbox mit einem Ethernet-TAP > oder Switch mit Monitor-Port den eingehenden Verbindungsaufbau > überprüfen. > > Viel Erfolg > > Grüße > M. Sicher Alles richtig und logisch, bin aber nicht vor Ort ... nur Teamviewer.
oszi40 schrieb: > Frank E. schrieb: >> Alles richtig und logisch > > Fritzbox-IP UND WLAN-IP könnten beide dynamisch sein? Ja. Die IP-Adresse spielt aber in den VPN-Einstellungen keine Rolle als Erkennungsmerkmal. Bin beim Setup des Shrew Clienten genau nach der AVM-Anleitung vorgegangen ... hab ich inzwischen so oft gemacht (auch bei anderen), kann ich quasi im Schalf.
Hallo. Ist zufälligerweise MyFritz im Spiel? Wenn ja muss dessen DNS Name genutzt werden - auch wenn zusätzlich "dyndns" verwendet wird. Martin
Ich wüsste da eine Organisation (wie etwa Digitalcourage e.v.), die sich sicherlich über eine kleine Spende freuen würde. Immerhin nutzt du das Forum quasi permanent als unbezahlten Mitarbeiter. ;-)
:
Bearbeitet durch User
Martin schrieb: > Hallo. > > Ist zufälligerweise MyFritz im Spiel? Wenn ja muss dessen DNS Name > genutzt werden - auch wenn zusätzlich "dyndns" verwendet wird. > > Martin Es wird myfritz.net genutzt und das funktioniert auch, denn sonst würde der Zugriff von anderen Orten aus nicht möglich sein. Die Benutzung des Begriffes "dyndns" im Startpost meint, dass myfritz.net in dieser Funktion verwendet wird, das "original"-DynDns wird nicht benutzt.
A. K. schrieb: > Ich wüsste da eine Organisation (wie etwa Digitalcourage e.v.), > die sich > sicherlich über eine kleine Spende freuen würde. Immerhin nutzt du das > Forum quasi permanent als unbezahlten Mitarbeiter. ;-) Hmm ... ich dachte, solche Dinskussionen sind im allgemeinen Interesse und helfen anderen, Wissen zu erlangen oder die gleichen Fehler nicht nochmal zu machen? Allerdings hat dieser Thread leider noch Nichts in dieser Richtung bewirkt, keine der Antworten hat mich bisher der Lösung wesentlich näher gebracht. Obwohl ich im Prinzip für jeden Versuch der Hilfe dankbar bin, gibt es auch einige Posts, die man sich beim gründlichen Lesen des Startbeitrages hätte sparen können ... fehlt manchmal bloß och die Frage, ob der Laptop auch eingeschaltet war und der Netzwerkstecker richtigrum drin :-)
Frank E. schrieb: > Hmm ... ich dachte, solche Dinskussionen sind im allgemeinen Interesse > und helfen anderen, Wissen zu erlangen oder die gleichen Fehler nicht > nochmal zu machen? Normalerweise schon. Nur läßt du hier regelmäßig andere deine Arbeit machen, für die du vermutlich fürstliche Honorare kassierst. > Allerdings hat dieser Thread leider noch Nichts in dieser Richtung > bewirkt, keine der Antworten hat mich bisher der Lösung wesentlich näher > gebracht. Es ist auch nicht die Aufgabe der Forumsteilnehmer, für dich Lösungen zu erarbeiten. Wenn man mit Technik sein Geld verdient, muß man eben etwas Zeit investieren und sich gründlich einarbeiten, anstatt immer nur oberflächliche, schnelle "Lösungen" hinzurotzen. Oder auch mal selber googeln und systematisch Fehler suchen. Wenn du dazu keine Lust hast, dann überlass die Arbeit denen, die wirklich was davon verstehen. > Obwohl ich im Prinzip für jeden Versuch der Hilfe dankbar bin, gibt es > auch einige Posts, die man sich beim gründlichen Lesen des > Startbeitrages hätte sparen können Und dann auch noch arrogant kommen, tsss...
Hallo. Log vom Client anschauen wenn es nicht geht und im Connector Paketmitschnitt aktivieren - dann sollte sich schnell feststellen lassen wo es harkt. Gerade doppeltes NAT etc mag IPsec nicht. Daher setzen ja auch viele Firmen auf SSL VPN - nicht weil es so performant ist ;-) Martin
Frank E. schrieb: > Nach wie vor mysteriös: Einen Tag zuvor hat es auch von Zuhause aus > funktionert. Und es war definitiv niemand (soweit bekannt) an der > heimischen Fritzbox. FB mal aus der Wand und Steckdose gezogen? Das wirkt manchmal Wunder. Habe nämlich auch FB und 1u1.
Beitrag #5465718 wurde von einem Moderator gelöscht.
Martin schrieb: > Gerade doppeltes NAT etc mag IPsec nicht. Ach watt, kompletter Unsinn. Wenn NAT-T (und die zugehörigen Hilfsprotokolle) korrekt umgesetzt ist, ist es IPSEC komplett Rille, ob da ein, zwei oder hundert NAT-Router auf dem Weg der Pakete lauern. Die müssen nur UDP Port 500 und 4500 ausgehend durchlassen und den Antwortkanal für eine gewisse Zeit erlauben, mehr ist nicht nötig. Ähem, klar: zumindest in einer Richtung muss sich ein Port-Forward auf das VPN-Gateway konfigurieren lassen. Letzteres ist oft der Knackpunkt, das ist aber bei SSL-VPN kein bissel anders. Auch dort braucht man zumindest auf einer Seite die Möglichkeit, ein Forward auf das VPN-Gateway konfigurieren zu können.
Icke ®. schrieb: > Es ist auch nicht die Aufgabe der Forumsteilnehmer, für dich Lösungen zu > erarbeiten. Wenn man mit Technik sein Geld verdient, muß man eben etwas > Zeit investieren und sich gründlich einarbeiten, anstatt immer nur > oberflächliche, schnelle "Lösungen" hinzurotzen. Oder auch mal selber > googeln und systematisch Fehler suchen. Wenn du dazu keine Lust hast, > dann überlass die Arbeit denen, die wirklich was davon verstehen. Da haben doch mal zwei den Nagel richtig auf den Kopf getroffen. Ist mir auch schon mehrfach aufgefallen, schön das es mal jemand angesprochen hat. Ich würde mir meinen Kunden gegeüber bissel komisch vorkommen, wenn ich hier ständig nach Hilfe schreie, professionell geht anders; die Kunden können auch googeln. Und das nächste Problem ist, das sich die Helfer, wegen solcher Leute immer mehr zurückhalten, da sie es nicht einsehen das Du mit Ihrem KnowHow Geld verdienst.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.