terminatorthree
Goto Top

WSUS Server in anderem (gerouteten) Subnet nicht erreichbar

Hallo zusammen,

ich bin mir nicht sicher, ob das so eine Freitag-Nachmittag-Frage ist und ich den Wald vor lauter Bäumen nicht sehe aber ich komm einfach nicht drauf.

Ausgangssituation:
2x Subnets (10.13.9.0/24 und 10.13.11.0/24), die untereinander von einer Sophos UTM geroutet werden. Das funktioniert meiner Meinung nach auch problemlos. Es gibt auch keine ACLs.
Auf der 10.13.9.253 ist WSUS auf einem Windows Server 2012R2 installiert. Dieser soll von allen Clients verwendet werden. Die Clients im selben Subnets funktionieren auch problemlos.

Jetzt kommt aber das Merkwürdige. Die Clients im anderen Subnet können den WSUS Server über die üblichen Protokolle erreichen (icmp geht, RDP geht, http auf Port 80 geht), jedoch nicht auf dem WSUS Port 8530. Hier kommt keine Verbindung zu Stande.

Muss ich dem WSUS noch irgendwie sagen, dass Verbindungen aus anderen Netzen akzeptiert werden sollen? Ich finde keine entsprechende Option.

Ich danke euch für jeden Denkanstoß, da ich im Moment keine Idee mehr habe.

Viele Grüße und einen schönen Start ins Wochenende
Terminatorthree

Content-ID: 298203

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

Ausgedruckt am: 22.11.2024 um 13:11 Uhr

emeriks
Lösung emeriks 04.03.2016 aktualisiert um 16:48:11 Uhr
Goto Top
Hi,
geht vom Client zum Server
  • ein Portping auf TCP 8530 und 8531
  • telnet 10.13.9.253 8530 bzw. 8531
?

Edit: Schon mal testweise die lokale Windows Firewall des Servers deaktiviert?
Terminatorthree
Terminatorthree 04.03.2016 um 16:54:22 Uhr
Goto Top
Hi,

leider baut auch Telnet keine Verbindung auf. Ein SSL Handshake auf Port 8531 kommt übrigens auch nicht zu Stande.
Muss ich in der Windows Firewall für diese Ports noch andere Subnet o.Ä. zulassen oder im IIS Manager?

Zusätzlich merke ich gerade, dass eine RDP Verbindung auch nicht mehr möglich ist, weil der Lizenzserver nicht erreicht werden kann (der auch im Subnet des WSUS steht). Dann muss doch was beim Routing oder den ACLs kaputt sein oder?

Danke für die Ideen, weitere sind gerne willkommen.
emeriks
emeriks 04.03.2016 um 17:08:00 Uhr
Goto Top
Muss ich in der Windows Firewall für diese Ports noch andere Subnet o.Ä. zulassen ...
Das kannst Du ja testen, indem Du mal kurz die Firewall deaktivierst.
Terminatorthree
Terminatorthree 04.03.2016 um 17:18:55 Uhr
Goto Top
Das habe ich soeben getan, leider auch ohne Erfolg.

Ich schließe daraus, dass es ein Problem im Netzwerk gibt, das erstmal gefunden werden muss, bevor ich mir den Anwendungslayer angucke.
areanod
Lösung areanod 04.03.2016 um 17:52:46 Uhr
Goto Top
Was ich jetzt tun würde:

1.) Sind alle Routen bzw. Route-Tables auf allen Komponenten (Server, Clients, Router) korrekt?

2.) Kommt bei abgeschaltener FW überhaupt irgendwas an aus dem anderen Netzwerk? Wireshark auf WSUS Server installieren und Filter setzen auf die Test-IP Adresse des anderen Subnetzes. Wenn die IP vom Tester aus dem anderen Subnet z.B. 10.13.11.100 ist dann würdest du folgenden Filter setzen:

Wenn hier etwas ankommt (ICMP z.B.) aber keine Reaktion (Rückpaket auf Anfrage) vom Server zurück gesendet wird dann hat's ein Routingproblem
Wenn nichts ankommt hat's zwar auch ein Routing Problem, allerdings vermutlich an der Stelle der Aktivkomponenten.

3.) Ich kenn Sophos nicht, gehe aber ganz einfach mal davon aus, dass die Software ein Logging oder einen Packet-Sniffer haben muss mit dem du den Traffic zwischen den Subnetzen monitoren kannst... wird da irgendwas gedropped?

4.) Mehr eine Nachfrage, aber: Wir reden hier eh nicht von zwei Subnetzen im selben VLAN bzw. selber Collision-Domain? Das könnte auch zu interessanten Ergebnissen führen face-smile

lG
Terminatorthree
Terminatorthree 04.03.2016 aktualisiert um 19:02:43 Uhr
Goto Top
Hi,

auch dir vielen Dank für deine Vorschläge, denn damit bin ich wieder ein Stück weiter gekommen. Das Problem liegt darin, dass der WSUS Dienst (Port 8530) nur per IPv6 erreichbar ist. Im lokalen Subnet gibt es IPv6 autoconfig, daher ging hier der Zugriff. Geroutet wird v6 aber hier nicht.

Ich habe nun im IIS die Bindings kontrolliert und diese stehen alle auf * . Leider ist ein Zugriff über IPv4 dennoch nicht möglich.

Habt ihr hier auch noch Vorschläge, warum kein Binding an die IPv4 Adresse erfolgt?

Grüße
Terminatorthree

Edit: netstat -aon zeigt ein Bindung sowohl auf 0.0.0.0:8530 als auch [::]:8530 der PID 4, also System, an. Aber auch mit deaktivierter Firewall kann ich nicht auf http://<IPv4>:8530 zugreifen
emeriks
emeriks 04.03.2016 um 20:58:32 Uhr
Goto Top
Bindungsreihenfolge der Protokolle? Setz mal IPv4 an erster Stelle.
Terminatorthree
Terminatorthree 05.03.2016 um 13:18:33 Uhr
Goto Top
Es ist nur ein einziges Binding für "*" im IIS Manager definiert, daher kann ich natürlich keine Reihenfolge verändern
areanod
Lösung areanod 08.03.2016 um 11:42:13 Uhr
Goto Top
Was emeriks damit meint ist, dass du im Netzwerkmanagement die Reihenfolge der Protokolle abänderst, das hat nichts mit IIS per se zu tun.

In der Übersicht der Netzwerkadapter gibt es einen Menüpunkt "Erweitert" , da gibts ein "Erweiterte Einstellungen", hier kannst du die diverse Protkollreihenfolgen verändern.


Was mich persönlich noch interessieren würde:

1.) Kannst du vom lokalen Host aus via IPv4 auf den WSUS zugreifen?
2.) Hast du schon probiert ob's über HTTPS (8531) funktioniert?
3.) Gibt's evt. irgendwas das den Netzwerktraffic beeinflusst und dir einen Redirect generiert?
4.) Was für Software läuft denn noch auf dem Server? Ich weiß z.B. bei einem SBS, dass ein aktivierter Dial-In-RAS die Funktionalitäten des SBS massiv beeinflusst, evt. ist hier was ähnliches bei deinem WSUS?
5.) Gibts andere Netzwerkadapter, benutzt / unbenutzt? Wenn es hier mehrere gibt und nur einer genutzt wird --> alle anderen deaktivieren & Server neu starten.

lG
Terminatorthree
Terminatorthree 11.03.2016 um 09:59:14 Uhr
Goto Top
Hi,

auch dir danke für die Antwort und sorry für die späte Antwort. Ich bin einfach nicht früher dazu gekommen.
Die Reihenfolge der Protokolle bevorzugt IPv4.

1.) Nein, generell kein IPv4 auf den IIS/WSUS, egal von wo. IPv4 auf andere Dienste (RDP) funkioniert aber.
2.) Habe ich, gleiches Ergebnis
3.) Das war auch meine Vermutung. Der Server ist ausschließlich BackupDC und eben WSUS Server und da der Zugriff auch lokal nicht funktioniert, klingt das zunächst unwahrscheinlich
4.) Das halte ich für einen sehr guten Ansatz. Auf dem Server war testweise die RAS Funktionalität installiert, da mit DirectAccess experimentiert wurde. Vielleicht wurde das nicht sauber entfernt. Da muss ich definitiv nochmal ein bisschen nach gucken. Danke!
5.) Es ist nur ein Netzwerkadapter vorhanden

Grüße
Terminatorthree
areanod
areanod 16.03.2016 aktualisiert um 01:34:18 Uhr
Goto Top
Welche Hardwarekomponenten nutzt du um die Subnetze zu routen, wenn geht Modelltyp und -nummer?

Sorry wenn das schon gefragt wurde, aber der IIS ist grundsätzlich aus dem Fremdnetz via Port 80 zu erreichen?

Ich gehe außerdem davon aus, dass du deine Tests alle mit Windows Firewall = off getestet hast?

EDIT: Hab grade den Thread nochmal durchgelesen und gesehen, dass Port 80 funktioniert aus dem fremden Subnetz.
Terminatorthree
Terminatorthree 19.03.2016 um 10:24:20 Uhr
Goto Top
Hi,

danke für den weiteren Kommentar. Routing erfolgt über eine Sophos UTM (virtuell). Das ist hier aber eigentlich nicht relevant, weil ich das Problem auf die fehlende IPv4 Erreichbarkeit des WSUS Services (auch im gleichen IPv4 Subnet) eingrenzen konnte. Warum das der Fall ist, konnte ich leider noch immer nicht herausfinden.
Ich werde vermutlich, sobald die Zeit es zulässt, den WSUS Server nochmals auf einem frischen Server aufsetzen, um Seiteneffekte mit den früher installierten RAS Diensten auszuschließen.

Grüße
Terminatorthree
areanod
areanod 22.03.2016 um 16:26:41 Uhr
Goto Top
Bin gespannt was es ist, lass uns bitte wissen was deine Lösung dann war.
Terminatorthree
Terminatorthree 27.03.2016 um 21:11:54 Uhr
Goto Top
Wie versprochen hier meine "Lösung":

Ich habe einen neuen Server aufgesetzt und auf diesem WSUS frisch installiert. Aufgrund der Größe der Umgebung ist das hier problemlos möglich. Den alten Server habe ich soweit von allen Rollen außer AD befreit und werde ich bei nächste Gelegenheit zum Abbau freigeben. Server mit komischen Effekten möchte ich nicht haben und setze daher im Zweifel lieber neu auf.

Ich werde aber versuchen einen Snapshot oder Backup der Maschine aufzuheben. Falls ich irgendwann noch über eine Idee stolpere, kann ich die dann noch ausprobieren.

Grüße
Terminatorthree

P.S.: Sollte ich den Thread dennoch als gelöst markieren, auch wenn es keine wirkliche Lösung gab?
areanod
areanod 29.03.2016 um 17:55:06 Uhr
Goto Top
Es mag vl. keine hochtechnische Lösung sein einen Server neu aufzusetzen und wahrscheinlich wäre eine erklärende Lösung, warum das Problem eigentlich aufgetreten ist, besser.

Wenn's für dich allerdings kein Problem mehr ist dann würde ich es definitiv als GELÖST markieren.

lG
Terminatorthree
Terminatorthree 07.04.2016 um 21:06:19 Uhr
Goto Top
Nachtrag: Auch wenn ich nicht sicher bin, ob relevant: Heute ist aufgefallen, dass auf dem Server noch ein manuell eingerichteter Endpunkt für SSTP VPN über HTTPS vorhanden war. Möglicherweise hat der den IIS blockiert. Nachprüfen kann ich das aber nicht mehr.