1 Server kann nicht mit Clients kommunizieren

Guten Morgen, ihr Götter aller Netzwerke!
Ich stehe mittlerweile ein bisschen seeeeehr auf der Leitung & bräuchte bitte eure Hilfe!
Folgendes Szenario:
Ich habe 2 VLANS - wir nennen diese jetzt mal ServerLAN und ClientLAN.
Im ServerLAN werden an jeden Server die gleichen Policies verteilt und im ClientLAN werden an jeden Client die gleichen Policies verteilt.
Ich habe nun im ServerLAN einen virtuellen Server(hier:Server1) - der seit gestern (letzte Woche lief noch alles gut) mit keinem Client mehr aus dem ClientLAN kommunizieren kann.
Und umgekehrt genauso, sprich kein Client kann mit diesem einen Server kommunizieren.
Jeder andere Server kann mit dem ClientLAN kommunizieren und jeder Client kann einen anderen Server im ServerLAN erreichen.
Server1 ist online - aus dem ServerLAN ohne Probleme zu erreichen, aus dem VPN Netz zu erreichen und sogar von extern (via Website mit öffentlicher IP).
Firewall Rule: Erlaubt alle sources auf die interne und öffentliche Adresse mit Port 80&443. ICMP erlaubt.
Wenn ich eine Wireshark Abfrage mache von einem Client der Server1 erreichen will. Sehe ich dass beim Ping keine Antwort zurück kommt und beim Aufruf der Website, dass die SYN Anfrage losgeschickt wird - aber keine ACK zurückkommt. Sprich TCP-Handshake nicht vorhanden.
In den Logs vom Server sehe ich allerdings dass keine Anfragen von dem Client Netz zum Server kommen.

Ich suche gerade eine Nadel im Heuhaufen und bin maßlos überfordert mit diesem Problem.
Vielleicht kann mir einer von euch helfen oder einen guten Denkanstoß liefern?

Liebe Grüße,
ITGhost

Content-Key: 1258121848

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

Ausgedruckt am: 25.09.2021 um 14:09 Uhr

Mitglied: em-pie
em-pie 14.09.2021 um 09:18:12 Uhr
Goto Top
Moin,

also als erstes würde ich mal auf der Firewall bzw. dem Gerät schauen, welches das Routing für die VLANs übernimmt.

Stimmen die Standardgateways?
Wurden Routing-Einträge "irgendwo" kürzlich verändert?

Gruß
em-pie
Mitglied: ITghost
ITghost 14.09.2021 um 09:23:17 Uhr
Goto Top
Zitat von @em-pie:

Moin,

also als erstes würde ich mal auf der Firewall bzw. dem Gerät schauen, welches das Routing für die VLANs übernimmt.

Stimmen die Standardgateways?
Wurden Routing-Einträge "irgendwo" kürzlich verändert?

Gruß
em-pie

Hey,
Standardgateways stimmen, sind erreichbar und up. Und das Routing für die VLANS habe ich auch überprüft. Da es bei anderen virtuellen Maschinen, die am gleichen Host angelegt sind funktioniert kann man das ausschließen oder?
Weder ich noch mein Kollege haben irgendetwas verändert. Der System-Stand ist der gleiche wie von letzter Woche wo es noch funktioniert hat.

LG,
Mitglied: Lochkartenstanzer
Lochkartenstanzer 14.09.2021 aktualisiert um 09:30:44 Uhr
Goto Top
Zitat von @ITghost:

Wenn ich eine Wireshark Abfrage mache von einem Client der Server1 erreichen will. Sehe ich dass beim Ping keine Antwort zurück kommt und beim Aufruf der Website, dass die SYN Anfrage losgeschickt wird - aber keine ACK zurückkommt. Sprich TCP-Handshake nicht vorhanden.
In den Logs vom Server sehe ich allerdings dass keine Anfragen von dem Client Netz zum Server kommen.

Mach sowohl auf dem Server als auch auf dem Hypervisor einen Wireshark-Mitschnitt, ob die SYN- oder ICMP-Pakete bis dahin kommen. Dann weißt Du, ob Du beim Gateway, der Firewall, im Hypervisor oder der VM suchen mußt.


Weder ich noch mein Kollege haben irgendetwas verändert.

Das sagen sie alle. :-) face-smile

Der System-Stand ist der gleiche wie von letzter Woche wo es noch funktioniert hat.

Offensichtlich nicht, denn sonst würde es ja funktioniren. Euer Gesamtsystem hat sich anscheinend so verändert, daß es eben jetzt nicht mehr geht. Mag sein, daß die VM vielleicht noch die gleiche Config hat, aber ohne den Hypervisor, die Firewall und die Router, ggf. sogar noch die switche, zu prüfen, kannst Du nicht behaupten, es hätte sich nichts geändert. :-) face-smile


lks
Mitglied: Drohnald
Drohnald 14.09.2021 um 09:29:04 Uhr
Goto Top
Spontan hätte ich auch gesagt:
Gateway oder Subnetzmaske in der Server-VM falsch (warum auch immer). Auf jeden Fall prüfen.
Dann sollte es aber auch aus dem VPN nicht klappen, davon ausgehend, dass das ein eigenes Netz ist.
Mitglied: em-pie
em-pie 14.09.2021 um 09:34:34 Uhr
Goto Top
Zitat von @ITghost:

Zitat von @em-pie:

Moin,

also als erstes würde ich mal auf der Firewall bzw. dem Gerät schauen, welches das Routing für die VLANs übernimmt.

Stimmen die Standardgateways?
Wurden Routing-Einträge "irgendwo" kürzlich verändert?

Gruß
em-pie

Hey,
Standardgateways stimmen, sind erreichbar und up. Und das Routing für die VLANS habe ich auch überprüft. Da es bei anderen virtuellen Maschinen, die am gleichen Host angelegt sind funktioniert kann man das ausschließen oder?
Weder ich noch mein Kollege haben irgendetwas verändert. Der System-Stand ist der gleiche wie von letzter Woche wo es noch funktioniert hat.

LG,

Dann erzähle mal ein wenig etwas zum besagten Server selbst, und auch, wer nun das Routing übernimmt. ein L3-Switch oder eine Firewall/ UTM?

Bzgl. des Servers ist mir eines nicht ganz klar:
Hängt der mit dem "nackten Ar***" im WWW, weil ihr eine Portweiterleitung auf 80 & 443 aktiv habt oder ist da noch ein ReverseProxy vorgesschaltet?
Im ersten Fall: ich würde mal sämtliche Logs verifizieren. Nicht, dass eure Kiste gekapert wurde.
auch mal ein route Print laufen lassen und prüfen, ob da nicht irgendwelche Einträge verbogen sind.
Mitglied: ITghost
ITghost 14.09.2021 um 09:47:27 Uhr
Goto Top
Zitat von @Lochkartenstanzer:

Zitat von @ITghost:

Wenn ich eine Wireshark Abfrage mache von einem Client der Server1 erreichen will. Sehe ich dass beim Ping keine Antwort zurück kommt und beim Aufruf der Website, dass die SYN Anfrage losgeschickt wird - aber keine ACK zurückkommt. Sprich TCP-Handshake nicht vorhanden.
In den Logs vom Server sehe ich allerdings dass keine Anfragen von dem Client Netz zum Server kommen.

Mach sowohl auf dem Server als auch auf dem Hypervisor einen Wireshark-Mitschnitt, ob die SYN- oder ICMP-Pakete bis dahin kommen. Dann weißt Du, ob Du beim Gateway, der Firewall, im Hypervisor oder der VM suchen mußt.

Was mich wundert - wenn ich ein tracert mache vom Client auf Server1 - ist der first hop die FW ( bis dahin ja noch gut) aber es kommt kein Second hop.
Da, dass ganze aber eigentlich eine interne Abwicklung ist, sollte er auf die FW gehen und dann auf die interne IP von dem Server. Denn so funktionierts im VPN Netz - ich weiß leider ob er beim ClientLAN nach der FW den Server versucht zu kontaktieren oder ob er da noch nen zwischen hop machen würde zu was/wem auch immer..


Weder ich noch mein Kollege haben irgendetwas verändert.

Das sagen sie alle. :-) face-smile

Ich weiß leider :( face-sad haha

Der System-Stand ist der gleiche wie von letzter Woche wo es noch funktioniert hat.

Offensichtlich nicht, denn sonst würde es ja funktioniren. Euer Gesamtsystem hat sich anscheinend so verändert, daß es eben jetzt nicht mehr geht. Mag sein, daß die VM vielleicht noch die gleiche Config hat, aber ohne den Hypervisor, die Firewall und die Router, ggf. sogar noch die switche, zu prüfen, kannst Du nicht behaupten, es hätte sich nichts geändert. :-) face-smile

Wo du recht hast, hast du wohl recht :o
Mitglied: ITghost
ITghost 14.09.2021 um 09:54:10 Uhr
Goto Top
Dann erzähle mal ein wenig etwas zum besagten Server selbst, und auch, wer nun das Routing übernimmt. ein L3-Switch oder eine Firewall/ UTM?
Der besagte Server ist einfach ein virtueller Windows Server 2016 - auf dem eine FileMaker Datenbank rennt (die von einem externen Dienstleister betreut und verwaltet wird). Wir stellen hier nur den Server und das Netzwerk zur Verfügung. Das Routing übernimmt eine "wunderschöne" Checkpoint Firewall.

Bzgl. des Servers ist mir eines nicht ganz klar:
Hängt der mit dem "nackten Ar***" im WWW, weil ihr eine Portweiterleitung auf 80 & 443 aktiv habt oder ist da noch ein ReverseProxy vorgesschaltet?
Das hat mein Kollege eingerichtet, der momentan im Ausland auf Urlaub ist und nicht erreichbar yey :D ich habs zwar bis jetzt noch nicht überprüft. Aber so wie ich ihn kenne bin ich mir sehr sicher, dass da ein ReverseProxy davor ist. Sonst sollte er besser nicht aus dem Urlaub zurückkommen :) face-smile.
Im ersten Fall: ich würde mal sämtliche Logs verifizieren. Nicht, dass eure Kiste gekapert wurde.
auch mal ein route Print laufen lassen und prüfen, ob da nicht irgendwelche Einträge verbogen sind.

Die Logs habe ich gestern vom externen Anbieter überprüfen lassen, in denen wir dann eben auch gesehen haben, dass Anfragen vom ServerLAN, von Extern und vom VPN Netz reinkommen aber keine Anfragen aus dem ClientLAN.
Ich selbst habe leider keinen Zugriff auf die Datenbank Logs, aber servertechnisch alles rein und es wirkt "fehlerfrei" auf ersten, zweiten und dritten Blick :) face-smile
LG,
Mitglied: em-pie
em-pie 14.09.2021 um 09:57:52 Uhr
Goto Top
Dann nimm dir die Checkpoint vor.

Kenne die Kiste selbst nicht, aber die hat doch bestimmt auch einen LiveMonitor oder so etwas.
Mitglied: NordicMike
NordicMike 14.09.2021 um 10:00:42 Uhr
Goto Top
Mach mal einen TCPDUMP auf der Firewall selbst bzw dem Gerät, das das Routing zwischen den zwei VLANs übernimmt. Rein kommen müsste das ICMP Paket noch, geht es auch auf der richtigen Schnittstelle raus? Wenn nicht, weisst du, dass Client und Server nicht schuld sind.
Mitglied: aqui
aqui 14.09.2021 aktualisiert um 10:07:25 Uhr
Goto Top
die am gleichen Host angelegt sind funktioniert kann man das ausschließen oder?
Ja, kann man dann wohl sicher ausschliessen.
Hilfreich wäre auch mal ein Ping vom Server direkt auf sein VLAN IP Gateway und die VLAN IP Gateway IP des Client Netzes ob das überhaupt erreichbar ist.
Sofern es keine ACLs auf dem Layer 3 VLAN Switch gibt und die IP Adressierung des Servers wasserdicht geprüft wurde kann es nur noch an den Firewall Regeln selber liegen.
Das betrifft dann sowohl die externe Firewall zwischen den IP VLAN Segmenten als auch die interne Server Firewall sofern aktiviert.
Da solltest du also einmal anfangen zu suchen...
Du kannst die externe Firewall ganz einfach mal checken indem du die inbound Regeln des Server VLAN Segments testweise einmal deaktivierst bzw. any any erlaubst. Klappt dann alles, hast du den bösen Buhmann gefunden. ;-) face-wink
Ohne also dein FW Regelwerk ganz genau zu kennen ist das hier alles Shooting in the dark und somit sinnfreie Raterei mit Blick in die Kristallkugel !! Das weisst du auch selber....
Mitglied: C.Caveman
C.Caveman 14.09.2021 um 10:04:05 Uhr
Goto Top
Man könnte, ja einfach auf der Firewall prüfen, was für Daten über die Leitung gehen.
Mitglied: ChriBo
ChriBo 14.09.2021 aktualisiert um 10:05:22 Uhr
Goto Top
Hi,
hast du mal die Firewall Einstellungen auf dem Server selber geprüft ?
Vielleicht ist die Zone geändert worden.

CH
Mitglied: ITghost
Lösung ITghost 14.09.2021 um 13:16:47 Uhr
Goto Top
Vielen Dank für eure zahlreichen Antworten!
Ich bin jetzt nochmal jede Instanz durchgegangen und es war ein definitives Routing Problem auf dem Switch der nach der FW kam. Dies wurde jetzt von einem externen Dienstleister behoben. Daher habe ich da leider keine näheren Lösungsinfos die ich euch mitteilen könnte..

Trotzdem danke für die Hilfe Leute!
LG,
Mitglied: Lochkartenstanzer
Lochkartenstanzer 14.09.2021 um 13:21:33 Uhr
Goto Top
Zitat von @ITghost:

Vielen Dank für eure zahlreichen Antworten!
Ich bin jetzt nochmal jede Instanz durchgegangen und es war ein definitives Routing Problem auf dem Switch der nach der FW kam.

Wie ich schon oben sagte: Der Teufel hätt ein jedem Teil auf dem Weg vom Client zum Server stecken können. Das Problem ist in solchen Fällen oft, wenn für die untertschiedlichen Komponenten unterschiedliche Leute zuständig sind, die sich dann koordinieren müssen, um zu debuggen.

lks
Heiß diskutierte Beiträge
general
DSL-Modems am F-Buchse statt N-Buchse - warum?Windows10GegnerVor 22 StundenAllgemeinDSL, VDSL19 Kommentare

Hallo zusammen, es sind jetzt hier die Fernmeldetechniker gefragt. Normalerweise wird ja ein DSL-Modem mit der F-Buchse einer TAE-NFN-Dose verbunden. Was ist der genau Grund ...

general
Autodesk im Jahre 2021-2022dertowaVor 1 TagAllgemeinOff Topic4 Kommentare

Hallo zusammen, mal eine kleine Anekdote, u.a. da heute Freitag ist. Vor einigen Jahren hatte ich mit Autodesk AutoCAD LT zu tun, in der damaligen ...

general
Außergewöhnliche hohe Spamaktivitäten und Angriffe per E-Mail gelöst beidermachtvongreyscullVor 1 TagAllgemeinE-Mail5 Kommentare

Tach Kollegen, liegt das an den bevorstehenden Wahlen? Ich beobachte seit Tagen auf unserer Firewall, dass wir massiven Spamwellen ausgesetzt sind. Bisher kommt zum Glück ...

question
Einrichtung Unify Security Gateway gelöst markaurelVor 18 StundenFrageLAN, WAN, Wireless9 Kommentare

Hallo zusammen und bitte um eure Hilfe! Wie der Titel schon sagt Folgende Situation: Ich hab ein Netzwerk in folgenden IP-Bereich: 192.168.10.x. Als Gateway dient ...

question
Backup-Server, welcher sich selber sichertludakuVor 1 TagFrageBackup6 Kommentare

Moin Zusammen Stellen wir uns kurz folgendes Konstrukt vor: 1x Hypervisor mit 3 VMs: - DC & Fileserver - Webserver - Acronis Backup-Server Ist es ...

question
Sysprep nachträglich virtualisierenalf008Vor 1 TagFrageVmware6 Kommentare

Hallo, ich habe diverse physikalische Server virtualisiert und später sollten diese in eine neue Domäne aufgenommen werden. Leider habe ich beim Virtualisieren erst später (zu ...

question
Wlanprobleme nach Providerwechsel gelöst amsti70Vor 1 TagFrageRouter & Routing8 Kommentare

Hallo alle zusammen! Ich bin neu auf dieser Seite und komme gleich mit einem Problem. Habe jetzt von A1 auf Drei Festnetz gewechselt. Mein System ...

question
Exchange Autodiscover ExternredhorseVor 1 TagFrageExchange Server5 Kommentare

Guten Morgen, bei Heise wird aktuell über eine Problematik berichtet, bei der es bei einem nicht nach Microsoft-Vorgaben konfiguriertem Autodiscover zu einem Sicherheitsproblem kommt: Konkret ...