13
Kein Zugriff auf GDATA-Port über IP-Adresse
Gegeben ist folgende Konstellation:
Windows Server 2012 Foundation
GDATA Antivirus Business G13 (keine GDATA-Firewall installiert)
Netzwerkkarte: Intel(R) I210 Gigabit Network Connection
Der GDATA-Administrator (gdmms.exe ) hört auf Port 7161 – das funktioniert bei anderen Installationen fehlerfrei.
Bei der hier beschriebenen Installation hört GDATA auf diesen Port, er ist aber nur über localhost und nicht über die IP-Adresse erreichbar. Das führt dazu, dass die Clients nicht mit GDATA auf dem Server kommunizieren können. U. a, ist eine zentrale Verwaltung dadurch nicht möglich.
Wir haben alle Firewall-Kombinationen durchgetestet:
1.
Sowohl auf dem Server wie auch auf den Arbeitsstationen sind die richtigen Regeln gesetzt – die in Frage kommenden Ports und Protokolle sind freigeschaltet. Trotzdem ist es nicht möglich, Kontakt mit dem Server aufzunehmen. telnet auf dem Server (192.168.10.200 und Port 7161) sollte eine Verbindung laut GDATA aufbauen können. Diese wird aber nicht aufgebaut. Versucht man das auf anderen von Serverdiensten benutzten Ports, sind diese Verbindungsversuche erfolgreich. Z. B. ein Versuch auf 192.168.10.200:2155 (SQLBase von Gupta) funktioniert tadellos.
2.
Auf dem Server selbst ist der Versuch über telnet über localhost:7161 erfolgreich – GDATA fühlt sich angesprochen.
telnet localhost 7161 -> ok
3.
Der gleiche Versuch auf dem Server, aber diesmal über die IP-Adresse 192.168.10.200:7161 schlägt jedoch fehl.
telnet 192.168.10.200 7161 -> keine Verbindung
4.
Netstat –ano –p TCP listet gdmms.exe als Prozess, der auf 7161 hört – was Punkt 2 bestätigt.
Zuvor war BitDefender Client Security (nur Antivirus, keine Bitdefender-Firewall) installiert. Auch da war die windowseigene Firewall aktiv.
Wir haben viele Versuche und Untersuchungen unternommen, alle leider Erfolglos. Auch ohne eingeschaltete Windows-Firewall funktioniert das nicht.
Wir haben auch keine IP-Sicherheitsrichtlinien gefunden, die das erklären könnten.
Der Support von GDATA antwortet trotz mehrmaliger Kontaktaufnahmen nur mit Standardbausteinen: „Firewalls abschalten“, „Port in Firewalls freigeben“ usw. – alles schon erfolglos gemacht.
Kennt jemand das Problem und besser, eine Lösung dafür? Bin für jede Hilfe dankbar.
temuco
Windows Server 2012 Foundation
GDATA Antivirus Business G13 (keine GDATA-Firewall installiert)
Netzwerkkarte: Intel(R) I210 Gigabit Network Connection
Der GDATA-Administrator (gdmms.exe ) hört auf Port 7161 – das funktioniert bei anderen Installationen fehlerfrei.
Bei der hier beschriebenen Installation hört GDATA auf diesen Port, er ist aber nur über localhost und nicht über die IP-Adresse erreichbar. Das führt dazu, dass die Clients nicht mit GDATA auf dem Server kommunizieren können. U. a, ist eine zentrale Verwaltung dadurch nicht möglich.
Wir haben alle Firewall-Kombinationen durchgetestet:
1.
Sowohl auf dem Server wie auch auf den Arbeitsstationen sind die richtigen Regeln gesetzt – die in Frage kommenden Ports und Protokolle sind freigeschaltet. Trotzdem ist es nicht möglich, Kontakt mit dem Server aufzunehmen. telnet auf dem Server (192.168.10.200 und Port 7161) sollte eine Verbindung laut GDATA aufbauen können. Diese wird aber nicht aufgebaut. Versucht man das auf anderen von Serverdiensten benutzten Ports, sind diese Verbindungsversuche erfolgreich. Z. B. ein Versuch auf 192.168.10.200:2155 (SQLBase von Gupta) funktioniert tadellos.
2.
Auf dem Server selbst ist der Versuch über telnet über localhost:7161 erfolgreich – GDATA fühlt sich angesprochen.
telnet localhost 7161 -> ok
3.
Der gleiche Versuch auf dem Server, aber diesmal über die IP-Adresse 192.168.10.200:7161 schlägt jedoch fehl.
telnet 192.168.10.200 7161 -> keine Verbindung
4.
Netstat –ano –p TCP listet gdmms.exe als Prozess, der auf 7161 hört – was Punkt 2 bestätigt.
Zuvor war BitDefender Client Security (nur Antivirus, keine Bitdefender-Firewall) installiert. Auch da war die windowseigene Firewall aktiv.
Wir haben viele Versuche und Untersuchungen unternommen, alle leider Erfolglos. Auch ohne eingeschaltete Windows-Firewall funktioniert das nicht.
Wir haben auch keine IP-Sicherheitsrichtlinien gefunden, die das erklären könnten.
Der Support von GDATA antwortet trotz mehrmaliger Kontaktaufnahmen nur mit Standardbausteinen: „Firewalls abschalten“, „Port in Firewalls freigeben“ usw. – alles schon erfolglos gemacht.
Kennt jemand das Problem und besser, eine Lösung dafür? Bin für jede Hilfe dankbar.
temuco
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 265929
Url: https://administrator.de/forum/kein-zugriff-auf-gdata-port-ueber-ip-adresse-265929.html
Ausgedruckt am: 26.12.2024 um 01:12 Uhr
13 Kommentare
Neuester Kommentar
Hallo,
WOW. Alle Kombinationen getestet. WOW
TCPIP Stack zurückgesetzt?
Anderes Benutzerprofil?
BHO und sonstige unerwünschte sind nicht vorhanden bzw. entfernt?
Gruß,
Peter
WOW. Alle Kombinationen getestet. WOW
Auf dem Server selbst ist der Versuch über telnet über localhost:7161 erfolgreich
Das sagt aber nichts über Zugriff per TCPIP aus.telnet 192.168.10.200 7161 -> keine Verbindung
Was sagt ein Wireshark? Kommt die Anfrage überhaupt an?Netstat –ano –p TCP listet gdmms.exe als Prozess, der auf 7161 hört – was Punkt 2 bestätigt.
Nicht wirklich bestätigt. Localhost muss nicht TCPIP sprechen.Kennt jemand das Problem und besser, eine Lösung dafür? Bin für jede Hilfe dankbar.
Andere Ports gehen? Andere Programme antworten wenn angefragt werden über TCPIP? Wireshark sieht die Anfragen?TCPIP Stack zurückgesetzt?
Anderes Benutzerprofil?
BHO und sonstige unerwünschte sind nicht vorhanden bzw. entfernt?
Gruß,
Peter
Es ist schon klar, was mit allen Kombinationen gemeint ist. Hinter dem Doppelpunkt ist eine Auflistung, die das beschreibt.
Andere Ports und Programme gehen - steht auch in der Beschreibung.
Danke und Grüße
temuco
Andere Ports und Programme gehen - steht auch in der Beschreibung.
Danke und Grüße
temuco
Hallo,
ist bei den anderen Installationen die Firewall mitinstalliert worden?
Wenn ja schau einfach mal nach was dort alles für Ports und
Protokolle geöffnet und erlaubt wurden.
Das mit dem WireShark bzw. TCPDUMP würde ich aber auch
einmal in Betracht ziehen.
Gruß
Dobby
ist bei den anderen Installationen die Firewall mitinstalliert worden?
Wenn ja schau einfach mal nach was dort alles für Ports und
Protokolle geöffnet und erlaubt wurden.
Das mit dem WireShark bzw. TCPDUMP würde ich aber auch
einmal in Betracht ziehen.
Gruß
Dobby
Hallo,
Wenn also netstat sowie localhost dort raus genommen wird, bleiben 2 Kombinationen übrig Egal....
Mal dem gedöhns einen anderen Port gegeben?
War das schon immer so das dort dein GData nicht hören will?
Und es spricht für GData wenn die dich mit Höflichkeitsfloskeln abspeisen wollen oder tun ....
Gruß,
Peter
Wenn also netstat sowie localhost dort raus genommen wird, bleiben 2 Kombinationen übrig
Egal....Mal dem gedöhns einen anderen Port gegeben?
War das schon immer so das dort dein GData nicht hören will?
Und es spricht für GData wenn die dich mit Höflichkeitsfloskeln abspeisen wollen oder tun ....
Gruß,
Peter
Das "Gedöhns" arbeitet nur mit diesem Port, soweit ich informiert bin. Eine Frage diesbezüglich bei GDATA wurde mit einer Antwort zu einer nicht gestellten Frage beantwortet...
War das schon immer so das dort dein GData nicht hören will?
Direkt nach der Installation.
Und es spricht für GData wenn die dich mit Höflichkeitsfloskeln abspeisen wollen oder tun ....
Es scheint eine "Eigenschaft" der Branche zu sein. Wir haben in den letzten 20 Jahren Symantec und Bitdefender durch - sie waren nicht wirklich besser, was der Support angeht. Nun dachten wir, GDATA, Bochum, Deutschland...
Habe genau das gleiche Problem. Einzig der Port 7161 auf dem der GDATA-Administrator hört, antwortet nur lokal am Server. Im Netzwerk reagiert er nicht. Deshalb können die GDATA-Clients nicht einmal ihre Lizenz abfragen. Tolles Sicherheitsprogramm. Für jede Hilfe dankbar.
Danke Chacay! Geteiltes Leid...
Leider komme ich nicht weiter. Der Support hilft nicht weiter und hat auf stumm geschaltet. Ich werde morgen mich bei der Geschäftsführung beschweren, denn es kann nicht sein, dass man mit Standardfloskeln und Antworten zu nicht gestellten Fragen abgefertigt wird.
Meine Hoffnung bleibt bestehend, dass jemand, der dieses Phänomen kennt, mir helfen kann.
temuco
Leider komme ich nicht weiter. Der Support hilft nicht weiter und hat auf stumm geschaltet. Ich werde morgen mich bei der Geschäftsführung beschweren, denn es kann nicht sein, dass man mit Standardfloskeln und Antworten zu nicht gestellten Fragen abgefertigt wird.
Meine Hoffnung bleibt bestehend, dass jemand, der dieses Phänomen kennt, mir helfen kann.
temuco
Nach einem Test mit einer anderen Software, die auf diesen Port hört, zeigte sich das gleiche Verhalten: Die Software beantwortet Anfragen, wenn diese lokal über localhost gehen. Die Anfragen, die über die IP-Adresse kommen, erreichen den Server nicht.
Es scheint so, als ob der Port nicht über die IP-Adresse erreichbar wäre, wir können jedoch bisher die Ursache nicht finden.
Es scheint so, als ob der Port nicht über die IP-Adresse erreichbar wäre, wir können jedoch bisher die Ursache nicht finden.
Hallo,
Ein Wireshark zeigt dir ganz klar ob die Anfragen überhaupt am Rechner ankommen. Kommen die dort an?
Gruß,
Peter
Ein Wireshark zeigt dir ganz klar ob die Anfragen überhaupt am Rechner ankommen. Kommen die dort an?
Gruß,
Peter
Kann ich erst machen, wenn ich wieder vor Ort bin. Wir haben die Serversoftware auf einer Arbeitsstation installiert, damit es überhaupt weiter geht.
Hallo Temuco,
habe weitere Erkenntnisse gewonnen. Bei uns ist nicht nur der GDATA-Port 7161 blockiert - damit ist es nur aufgefallen - sondern ein immens großer Bereich zwischen 6001 und 47000. In diesem kompletten Bereich (vielleicht gibt es dazwischen doch ein paar Lücken) reagiert kein Server auf einen Verbindungsversuch auf einen dieser Ports.
Ja wie können denn solch große Bereiche einfach blockiert werden? An der Windows-Firewall jedoch liegt es nicht. Egal ob aktiviert, deaktiviert, ein- oder ausgeschaltet, je eine Regel für ein- und ausgehende Verbindungen, welche jeglichen Datenverkehr erlaubt, erstellt, etc. nichts ändert etwas an diesem Blockieren. Ich denke aber, das sollte dann doch in einen neuen Thread laufen, oder?
habe weitere Erkenntnisse gewonnen. Bei uns ist nicht nur der GDATA-Port 7161 blockiert - damit ist es nur aufgefallen - sondern ein immens großer Bereich zwischen 6001 und 47000. In diesem kompletten Bereich (vielleicht gibt es dazwischen doch ein paar Lücken
) reagiert kein Server auf einen Verbindungsversuch auf einen dieser Ports.Ja wie können denn solch große Bereiche einfach blockiert werden? An der Windows-Firewall jedoch liegt es nicht. Egal ob aktiviert, deaktiviert, ein- oder ausgeschaltet, je eine Regel für ein- und ausgehende Verbindungen, welche jeglichen Datenverkehr erlaubt, erstellt, etc. nichts ändert etwas an diesem Blockieren. Ich denke aber, das sollte dann doch in einen neuen Thread laufen, oder?
Das würde mich auch sehr und brennend interessieren. Bei uns ist die Situation ähnlich, um nicht zu sagen gleich!
Hallo,
Normal ist es nicht das ein Server OS mal eben von sich aus alles oder nur Bereiche dicht macht.
GPO
Firewall
Drittherstellersoftware
Gruß,
Peter
Zitat von @temuco:
Das würde mich auch sehr und brennend interessieren. Bei uns ist die Situation ähnlich, um nicht zu sagen gleich!
Was ist denn wenn ihr mal euer Server OS nehmt und auf einer neuen Maschine pappt und schaut was es dort mit den Ports auf sich hat. Danach dann kontinuierlich einzeln eure Softwarepakete drauf bringen und schauen wann die Ports plötzlich dicht machen. Das kann ja auch in ein komplett anderes IP Netz und Domäne sein. Und bei allen Sachen immer wieder die Ports prüfen, auch ein Wireshark kann helfen um zu sehen wann keine Antwort vom Server mehr kommt.Das würde mich auch sehr und brennend interessieren. Bei uns ist die Situation ähnlich, um nicht zu sagen gleich!
Normal ist es nicht das ein Server OS mal eben von sich aus alles oder nur Bereiche dicht macht.
GPO
Firewall
Drittherstellersoftware
Gruß,
Peter
