127132
19.07.2019
5189
11
0
LANCOM und Teamviewer
Morgen zusammen!
Ich steh' auf dem Schlauch.
Auf einem W2k12R2 läuft die Warenwirtschaft auf die die User zugreifen und steht hinter einem Lancom 1781VA.
Zusätzlich ist da auch noch der Teamviewer Host installiert, um den Entwickler der Warenwirtschaft Zugriff drauf zu geben.
Sobald sich jemand per Teamviewer auf den Server verbinden will, kacken sämtliche Verbindungen ab, die über den Lancom reinkommen.
Eben auch alle Verbindungen der User, die per Terminal auf die Warenwirtschaft zugreifen wollen. Ebenso auch eine aufgebaute RDP-Verbindung.
Um die Verbindungen wieder zu ermöglichen muss ich im Lancom die IDS der Firewall ändern und abspeichern. Sprich: kurz die IDS auf verwerfen stellen udn die Konfig übertragen. Quasi 3 Sekunden Arbeit.
Grundsätzlich steht das auf "übertragen", damit da eben alle Pakete übertragen werden.
Und auch das Log sieht ein UDP-Paket vom Rechner, der sich per Teamviewer auf den Server verbinden will. Ebenso wird das Paket auch übertragen.
Wurde das gemacht (z.B. die IDS von "übertragen" auf "verwerfen" umgestellt und die neue Konfig hochgeladen, dann baut sich die Teamviewer-Verbindung auf und auch die restlichen Verbindungen der User werden wieder aufgebaut.
An dem Lancom hängt noch ein zweiter Server dran. Ebenfalls ein W2k12R2 mit der gleichen Warenwirtschaft drauf und auch mit einem Teamviewer-Host.
Beide sind in verschiedenen Netzen (192.168.0.0 und 192.168.100.0).
Die Verbindung zwischen den beiden Netzen ist per Lancom Firewall-Regel offen.
Auf dem zweiten Server klappt die Verbindung mittels Teamviewer einwandfrei.
Was ich bereits gemacht habe:
Teamviewer deinstalliert und die neue 14er draufgespielt.
Server neu gestartet.
Es bleibt beim Verbindungsabbruch
Testweise habe ich dann den RealVNC Server installiert.
Mit dem gibts keine Probleme.
Ich bin momentan völlig überfragt, wo es da beim Lancom hakt. Denn der Fehler muss ja irgendwo auf dem sein. Das ändern der IDS und das übertragen einer Konfig behebt ja den Fehler.
Es ist aktuell noch nicht die neueste Firmware auf dem Lancom, das muss ich noch am Wochenende nachholen. Ich bezweifle es aber fast, dass es das sein wird, da es ja auf dem anderen Server einwandfrei funktioniert.
Hilfe!
h.
Ich steh' auf dem Schlauch.
Auf einem W2k12R2 läuft die Warenwirtschaft auf die die User zugreifen und steht hinter einem Lancom 1781VA.
Zusätzlich ist da auch noch der Teamviewer Host installiert, um den Entwickler der Warenwirtschaft Zugriff drauf zu geben.
Sobald sich jemand per Teamviewer auf den Server verbinden will, kacken sämtliche Verbindungen ab, die über den Lancom reinkommen.
Eben auch alle Verbindungen der User, die per Terminal auf die Warenwirtschaft zugreifen wollen. Ebenso auch eine aufgebaute RDP-Verbindung.
Um die Verbindungen wieder zu ermöglichen muss ich im Lancom die IDS der Firewall ändern und abspeichern. Sprich: kurz die IDS auf verwerfen stellen udn die Konfig übertragen. Quasi 3 Sekunden Arbeit.
Grundsätzlich steht das auf "übertragen", damit da eben alle Pakete übertragen werden.
Und auch das Log sieht ein UDP-Paket vom Rechner, der sich per Teamviewer auf den Server verbinden will. Ebenso wird das Paket auch übertragen.
Wurde das gemacht (z.B. die IDS von "übertragen" auf "verwerfen" umgestellt und die neue Konfig hochgeladen, dann baut sich die Teamviewer-Verbindung auf und auch die restlichen Verbindungen der User werden wieder aufgebaut.
An dem Lancom hängt noch ein zweiter Server dran. Ebenfalls ein W2k12R2 mit der gleichen Warenwirtschaft drauf und auch mit einem Teamviewer-Host.
Beide sind in verschiedenen Netzen (192.168.0.0 und 192.168.100.0).
Die Verbindung zwischen den beiden Netzen ist per Lancom Firewall-Regel offen.
Auf dem zweiten Server klappt die Verbindung mittels Teamviewer einwandfrei.
Was ich bereits gemacht habe:
Teamviewer deinstalliert und die neue 14er draufgespielt.
Server neu gestartet.
Es bleibt beim Verbindungsabbruch
Testweise habe ich dann den RealVNC Server installiert.
Mit dem gibts keine Probleme.
Ich bin momentan völlig überfragt, wo es da beim Lancom hakt. Denn der Fehler muss ja irgendwo auf dem sein. Das ändern der IDS und das übertragen einer Konfig behebt ja den Fehler.
Es ist aktuell noch nicht die neueste Firmware auf dem Lancom, das muss ich noch am Wochenende nachholen. Ich bezweifle es aber fast, dass es das sein wird, da es ja auf dem anderen Server einwandfrei funktioniert.
Hilfe!
h.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 475206
Url: https://administrator.de/forum/lancom-und-teamviewer-475206.html
Ausgedruckt am: 19.04.2025 um 04:04 Uhr
11 Kommentare
Neuester Kommentar
Moin,
du hast das Problem ja schon erkannt.
Wie sehen denn IDS Regeln aus? Anscheinend wird ja der ganze Host geblockt.
Gruß
Spirit
du hast das Problem ja schon erkannt.
Wie sehen denn IDS Regeln aus? Anscheinend wird ja der ganze Host geblockt.
Gruß
Spirit
Moin,
vielleicht hat Dein Regelwerk einen Schlag weg oder die Firewall, ich hatte so einen ähnlichen Effekt (mit einem anderen Hersteller).
Das Regelwerk hat nur einen halben Tag lang funktioniert, danach war alles "zu".
Durchpatchen auf die aktuellste Version war damals die Lösung.
Also zieh die FW mal durchgehend auf einen aktuellen Stand und teste weiter.
Nebenbei:
Ich halte nichts vom Teamviewer Host auf einem Server (oder PC), was spricht dagegen, dem Support einen eigenen VPN Zugang zu ermöglichen?
Gruss
vielleicht hat Dein Regelwerk einen Schlag weg oder die Firewall, ich hatte so einen ähnlichen Effekt (mit einem anderen Hersteller).
Das Regelwerk hat nur einen halben Tag lang funktioniert, danach war alles "zu".
Durchpatchen auf die aktuellste Version war damals die Lösung.
Also zieh die FW mal durchgehend auf einen aktuellen Stand und teste weiter.
Nebenbei:
Ich halte nichts vom Teamviewer Host auf einem Server (oder PC), was spricht dagegen, dem Support einen eigenen VPN Zugang zu ermöglichen?
Gruss
Zitat von @Spirit-of-Eli:
Wie sehen denn IDS Regeln aus? Anscheinend wird ja der ganze Host geblockt.
Wie sehen denn IDS Regeln aus? Anscheinend wird ja der ganze Host geblockt.
Genauso wie für den anderen Server, bei dem's funktioniert.
Zitat von @sabines:
Moin,
vielleicht hat Dein Regelwerk einen Schlag weg oder die Firewall, ich hatte so einen ähnlichen Effekt (mit einem anderen Hersteller).
Moin,
vielleicht hat Dein Regelwerk einen Schlag weg oder die Firewall, ich hatte so einen ähnlichen Effekt (mit einem anderen Hersteller).
Kenn ich. Regelwerk ist relativ einfach und zigmal überprüft.
Nebenbei:
Ich halte nichts vom Teamviewer Host auf einem Server (oder PC), was spricht dagegen, dem Support einen eigenen VPN Zugang zu ermöglichen?
Werde da aber natürlich nachhaken, wieso und warum und dann lieber auf direkt VPN setzen.
FW-Update werd ich am Wochenende mal durchziehen. Ein 1783VAW müsste auch noch irgendwo rumliegen. Zur Not tausch ich die mal aus.
Und wenn nicht, dann möchte ich gerne mal auf andere Router setzen.
Die Lancom sind ja an und für sich nicht schlecht, aber alles andere als intuitiv und manchmal auch ziemlich merkwürdig.
h.
Sowas heute noch ohne VPN zu lösen ist ja eh fahrlässig. Mal ganz davon abgesehen Teamviewer zu verwenden, was durch den Vermittlungsrechner als Schnüffelelement dazwischen ja eher als unsicher gilt. In einem Firmenumfeld ist sowas bei vielen Unternehmen ein Kündigungsgrund da Verstoß gegen die Sicherheits Policies...aber egal..andere Baustelle.
Sinnvoll ist hier natürlich VPN zu verwenden und dann direkt mit dem RDP Client zu arbeiten. Gerade auch wenn man schon den Luxus eines VPN Routers hat wie der TO was den Thread dann irgendwie auch etwas sinnfrei macht. Das dann zu ignorieren ist eigentlich schlicht dumm.
Zumal man mit dem Shrew Client auch noch einen kostenlosen Client hat.
Aber egal....
Sinnvoll ist hier natürlich VPN zu verwenden und dann direkt mit dem RDP Client zu arbeiten. Gerade auch wenn man schon den Luxus eines VPN Routers hat wie der TO was den Thread dann irgendwie auch etwas sinnfrei macht. Das dann zu ignorieren ist eigentlich schlicht dumm.
Zumal man mit dem Shrew Client auch noch einen kostenlosen Client hat.
Aber egal....
Zitat von @aqui:
Sowas heute noch ohne VPN zu lösen ist ja eh fahrlässig. Mal ganz davon abgesehen Teamviewer zu verwenden, was durch den Vermittlungsrechner als Schnüffelelement dazwischen ja eher als unsicher gilt. In einem Firmenumfeld ist sowas bei vielen Unternehmen ein Kündigungsgrund da Verstoß gegen die Sicherheits Policies...aber egal..andere Baustelle.
Sinnvoll ist hier natürlich VPN zu verwenden und dann direkt mit dem RDP Client zu arbeiten. Gerade auch wenn man schon den Luxus eines VPN Routers hat wie der TO was den Thread dann irgendwie auch etwas sinnfrei macht. Das dann zu ignorieren ist eigentlich schlicht dumm.
Zumal man mit dem Shrew Client auch noch einen kostenlosen Client hat.
Alles richtig @aqui, aber was macht man in solchen Fällen:Sowas heute noch ohne VPN zu lösen ist ja eh fahrlässig. Mal ganz davon abgesehen Teamviewer zu verwenden, was durch den Vermittlungsrechner als Schnüffelelement dazwischen ja eher als unsicher gilt. In einem Firmenumfeld ist sowas bei vielen Unternehmen ein Kündigungsgrund da Verstoß gegen die Sicherheits Policies...aber egal..andere Baustelle.
Sinnvoll ist hier natürlich VPN zu verwenden und dann direkt mit dem RDP Client zu arbeiten. Gerade auch wenn man schon den Luxus eines VPN Routers hat wie der TO was den Thread dann irgendwie auch etwas sinnfrei macht. Das dann zu ignorieren ist eigentlich schlicht dumm.
Zumal man mit dem Shrew Client auch noch einen kostenlosen Client hat.
- Kunde hat Lancom Router und eingerichtete VPNs.
- Kunde bekommt neue Wawi auf einen Server, die von einer Fremdfirma betreut wird.
- Ich richte der Fremdfirma einen Client-VPN-Zugang zu diesem Server ein
- Fremdfirma weigert sich das VPN zu nutzen und verlangt einen Teamviewer-Zugang mit der Begründung, dass man eine einheitliche Verwaltung der Zugänge zu den Kundeninstallationen möchte und nicht mit dutzenden unterschiedlichen VPN-Lösungen arbeiten will
BTT:
Natürlich hatte ich genau bei diesem Kunden auch das Problem, dass der Mitarbeiter der WAWI-Firma nach einer bestimmten Zeit keine Verbindung mit dem TV mehr hatte (er konnte noch Eingaben machen, sah diese aber nicht mehr).
Bei Teamviewer habe ich dazu ein Ticket geöffnet - blieb ergebnislos.
Das Problem scheint aber behoben zu sein. Muss wohl ein Update gewesen sein, weiß jetzt nicht mehr ob Teamviewer oder Windows (Server 2016).
Insgesamt habe ich mehr als 6h Arbeit in ein Problem gesteckt, was ohne den Teamviewer nicht vorhanden gewesen wäre.
Mein Vorschlag:
Aktualisiere die Firmware des Lancom Routers.
Überprüfe die TV-Konfiguration und aktualisiere diesen nochmals.
Servus,
der Fremdfirma würde ich genau sagen:
Mein Netz = mein Recht, die Zugangsart zu bestimmen.
Wenn du nen Lancom-Router nutzt, dann nimmst den Lancom-VPN-Client oder den Client von NCP (baugleich). Dann lässt den Lancom-Router ein Konfigfile erstellen und schickst das der Fremdfirma. Firewall-Regel schreiben, das die Fremdfirma nur auf den WAWI-Server kommt. Fertig ist der Lack. Wenn die Firma das nicht will, dann anderen Partner suchen.
Jeder schreit immer nach TV, weil es so schön bequem ist und man zu Beginn sich ein paar Minuten Arbeit auf Kosten der Sicherheit spart.
Gruss NV
der Fremdfirma würde ich genau sagen:
Mein Netz = mein Recht, die Zugangsart zu bestimmen.
Wenn du nen Lancom-Router nutzt, dann nimmst den Lancom-VPN-Client oder den Client von NCP (baugleich). Dann lässt den Lancom-Router ein Konfigfile erstellen und schickst das der Fremdfirma. Firewall-Regel schreiben, das die Fremdfirma nur auf den WAWI-Server kommt. Fertig ist der Lack. Wenn die Firma das nicht will, dann anderen Partner suchen.
Jeder schreit immer nach TV, weil es so schön bequem ist und man zu Beginn sich ein paar Minuten Arbeit auf Kosten der Sicherheit spart.
Gruss NV
Hast du auf meinen Beitrag geantwortet?
Das der unbeaufsichtigte TV-Zugang zu einem Server unsicherer ist, als der unbeaufsichtigte VPN-Zugang zu diesem Server, ist erst einmal nur eine Behauptung von dir.
Mein Netz = mein Recht, die Zugangsart zu bestimmen.
Nein, das ist nicht mein Netz, sondern das einer Firma, die von mir betreut wird.Jeder schreit immer nach TV, weil es so schön bequem ist und man zu Beginn sich ein paar Minuten Arbeit auf Kosten der Sicherheit spart.
Unabhängig davon, ob man den Teamviewer jetzt mag oder ablehnt.Das der unbeaufsichtigte TV-Zugang zu einem Server unsicherer ist, als der unbeaufsichtigte VPN-Zugang zu diesem Server, ist erst einmal nur eine Behauptung von dir.
ist erst einmal nur eine Behauptung von dir.
Zitat von @aqui:
ist erst einmal nur eine Behauptung von dir.
..und schon eine ziemlich Schräge die allem widerspricht. Aber der TO wirds schon wissen....?!@aqui: Wieso war meine bescheidene Anfänger-Behauptung falsch, das VPN besser ist als TV? Ich dachte immer, ein kontrollierte Zugang per VPN ist sicherer, als wenn ich noch einen Dritten wie z.B. TV in der Verbindung habe? Oder hab ich jetzt nur etwas falsch verstanden?
Sorry, ich hatte den Wortlaut des Kollegen @goscho missverstanden. Die vielen "un's" vor den Adjektiven hatt mich etwas aus der Spur gebracht... Ich nehme alles zurück und behaupte das Gegenteil ! 
Fakt ist das TV alles mithört und in Profilen speichert was über deren Vermittlungsserver läuft. Für die Fernwartung ist das ein NoGo sofern man Wert auf Sicherheit legt. In den meisten Firmen ist das deshalb ein NoGo für TV was ja auch hinreichend bekannt ist.
Zumal der Besitzer von TV ein US Finanzinvestor ist für die keine EU Datenschutzgesetze gelten.
Fakt ist das TV alles mithört und in Profilen speichert was über deren Vermittlungsserver läuft. Für die Fernwartung ist das ein NoGo sofern man Wert auf Sicherheit legt. In den meisten Firmen ist das deshalb ein NoGo für TV was ja auch hinreichend bekannt ist.
Zumal der Besitzer von TV ein US Finanzinvestor ist für die keine EU Datenschutzgesetze gelten.
Kurzes Feedback.
Krankheitsbedingt gab's noch kein Firmwareupdate.
Werde das demnächst mal nachholen.
h.
Krankheitsbedingt gab's noch kein Firmwareupdate.
Werde das demnächst mal nachholen.
h.
