16
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
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
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: 298203
Url: https://administrator.de/forum/wsus-server-in-anderem-gerouteten-subnet-nicht-erreichbar-298203.html
Ausgedruckt am: 31.12.2024 um 14:12 Uhr
16 Kommentare
Neuester Kommentar
Hi,
geht vom Client zum Server
Edit: Schon mal testweise die lokale Windows Firewall des Servers deaktiviert?
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?
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.
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.
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.
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.
Ich schließe daraus, dass es ein Problem im Netzwerk gibt, das erstmal gefunden werden muss, bevor ich mir den Anwendungslayer angucke.
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
lG
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
lG
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
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
Bindungsreihenfolge der Protokolle? Setz mal IPv4 an erster Stelle.
Es ist nur ein einziges Binding für "*" im IIS Manager definiert, daher kann ich natürlich keine Reihenfolge verändern
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
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
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
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
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.
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.
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
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
Bin gespannt was es ist, lass uns bitte wissen was deine Lösung dann war.
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?
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?
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
Wenn's für dich allerdings kein Problem mehr ist dann würde ich es definitiv als GELÖST markieren.
lG
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.
