DHCP-Problem nach Regelerstellung

[Max Habermehl]

Hallo zusammen,

ich habe auf einem SBS2003 ("R1") mit ISA2004 (alle SPs eingespielt) folgendes Problem:

Scheinbar aus heiterem Himmel erhielt ein PC vom DHCP des SBS beim Hochfahren keine IP mehr zugeteilt ("eingeschränkte
Konnektivität").
Da es früher schoneinmal mit baugleichen PCs Probleme gab, die an einer defekten Netzwerkkarte lagen, ging die Vermutung zunächst
in diese Richtung (NIC kaputt).
Kunde "reparierte" selbst durch Einbau einer zusätzlichen NIC - daß dies nicht geklappt hatte und der PC weiterhin keine IP
erhielt, erfuhr ich erst heute.

Ca. 2 Wochen später erhielt nun der nächste PC im Netzwerk beim Hochfahren keine IP mehr zugeteilt.
Als ich mir das vor Ort angesehen habe, war schnell klar, das der Netzwerkzugriff sofort klappte , sobald man den Clients feste
IPs zuwies.

Ich habe dann via ISA-Überwachung eine Protokollierung angestoßen und siehe da:
Der ISA verweigerte den DHCP-Verkehr (leider habe ich nicht notiert, ob die Lease-Anforderung oder deren Bestätigung).

Die einzigen in den letzten Monaten neu erstellten FW-Richtlinien waren 2 Richtlinien, die den Zugriff via Teamviewer auf den
Server ermöglichen sollten:
1. Zugriffsregel: Zulassen, Protokoll: TCP ausgehend für Port 5938, von Intern nach Extern, alle Benutzer, alle Zeiten, alle
Inhaltstypen.
2. Url-Satz: Zulassen, gesamter ausgehender Datenverkehr, von Intern nach "Teamviewer Server" (*dyngate.com, *teamviewer.com),
alle Benutzer, alle Zeiten, alle Inhaltstypen.

Sobald ich diese beiden Regeln deaktivierte, klappte die Verteilung der DHCP-Adressen an die Clients stante pede wieder.
(die Regeln waren übrigens an 1. und 4. Stelle des Regelwerkes platziert.)

Ich kann mir nicht erklären, was nun DHCP mit diesen Regeln zu tun haben könnte - habt Ihr vielleicht einen hilfreichen Hinweis
hierzu?

Vielen Dank im Voraus,

Max

[Dieter Rauscher [MVP]]

Hallo Max

Post by Max Habermehl
Der ISA verweigerte den DHCP-Verkehr (leider habe ich nicht notiert, ob
die Lease-Anforderung oder deren Bestätigung).
Die einzigen in den letzten Monaten neu erstellten FW-Richtlinien waren 2
Richtlinien, die den Zugriff via Teamviewer auf den Server ermöglichen
1. Zugriffsregel: Zulassen, Protokoll: TCP ausgehend für Port 5938, von
Intern nach Extern, alle Benutzer, alle Zeiten, alle Inhaltstypen.
2. Url-Satz: Zulassen, gesamter ausgehender Datenverkehr, von Intern nach
"Teamviewer Server" (*dyngate.com, *teamviewer.com), alle Benutzer, alle
Zeiten, alle Inhaltstypen.
Sobald ich diese beiden Regeln deaktivierte, klappte die Verteilung der
DHCP-Adressen an die Clients stante pede wieder.
(die Regeln waren übrigens an 1. und 4. Stelle des Regelwerkes platziert.)
Ich kann mir nicht erklären, was nun DHCP mit diesen Regeln zu tun haben
könnte - habt Ihr vielleicht einen hilfreichen Hinweis hierzu?

Ich kann mir auch keinen Reim daraus machen erstmal.

Schau doch mal bitte in der ISA-Protokollierung genauer nach. Wegen was wird
der Verkehr verweigert?
Was sagt das Windows-Eventlog dazu?

Viele Grüße
Dieter

[Jens Baier]

Hi,

Post by Max Habermehl
Ich kann mir nicht erklären, was nun DHCP mit diesen Regeln zu tun haben
könnte - habt Ihr vielleicht einen hilfreichen Hinweis hierzu?

ISA arbeitet die Regeln nach First Match ab.
Schau mal, welche Regel den DHCP Traffic blockt.
pack die DHCP Regel vor die anderen Regeln, dann sollte es wieder funzen.

gruss Jens
www.nt-faq.de
www.it-training-grote.de
www.forefront-tmg.de

[unknown]

servus max und hallo an die werten kellogs,

Post by Max Habermehl
Scheinbar aus heiterem Himmel erhielt ein PC vom DHCP des SBS beim
Hochfahren keine IP mehr zugeteilt ("eingeschränkte Konnektivität").
Da es früher schoneinmal mit baugleichen PCs Probleme gab, die an einer
defekten Netzwerkkarte lagen, ging die Vermutung zunächst in diese
Richtung (NIC kaputt).
Kunde "reparierte" selbst durch Einbau einer zusätzlichen NIC - daß dies
nicht geklappt hatte und der PC weiterhin keine IP erhielt, erfuhr ich
erst heute.

ich hatte mal ähnliche probleme mit einem sbs2003premium. ich denke nicht,
das hier dieselbe geschichte vorliegt, sei aber sicherheitshalber trotzdem
erwähnt. kontrolliere mal dein netzwerk "intern", ob hier korrekt die
adressbereiche eingetragen sind, vor allem die broadcast-bereiche sollten
mit zu "intern" gehören. bei mir fehlte damals die 192.168.1.255, da der
admin nur bis 254 eingetragen hatte. kleiner fehler, große wirkung.

[Max Habermehl]

Hallo ihr Drei,

vielen Dank für Eure Antworten.

Mittlerweile hat der Teamviewer-Support einen "Fix" herausgegeben (bzw. ab TV Version 5 standardmäßig integriert) , der die von
mir gesetzten Url-Sätze bzw. die Zugriffsregel überflüssig machen soll (ich nehme an, der Weg via Port 80 (bzw. 8080) ist nun auch
direkt auf Rechnern störungsfrei möglich, auf denen ISA läuft - genauere Angaben zum Umfang des "Fixes" habe ich keine erhalten).

Auf einem Server getestet --> Scheint zu klappen.

Schau doch mal bitte in der ISA-Protokollierung genauer nach. Wegen was wird der Verkehr verweigert?

Der Verkehr wurde wegen der genannten 2 Teamviewer-Regeln verweigert. Wenn ich mir das genauer anschauen möchte, passiert das:
Beim Auslesen der ISA-Protokolle erhalte ich den Fehler "Firewall protokolliert nicht nach MSDE" (gleiches gilt für den
Webproxy-Dienst).
Der Fehler tritt beim bearbeiten der Abfrage-Filter auf.
Kann die ISA-Protokollierung kein W3C darstellen?

Was sagt das Windows-Eventlog dazu?

Leider gar nichts (Anwendungs-, System-, ISA-Protokolle), außer Spoofing-Alarmen für die mangels DHCP-Lease durch die Clients
selbst vergebenen APIPA-Adressen.

Merkwürdigerweise waren ja auch nur zwei und nicht alle PCs betroffen (alle baugleich, alle gleicher Softwarestand).

---

ISA arbeitet die Regeln nach First Match ab.
Schau mal, welche Regel den DHCP Traffic blockt.
pack die DHCP Regel vor die anderen Regeln, dann sollte es wieder funzen.

Beim SBS bin ich mir nicht ganz sicher, welche Konsequenzen das haben könnte.
Vor der DHCP-Regel ("SBS Localhost Access Rule") sind die SBS RWW- und OWA- Regeln gesetzt.
Bei diesem Server möchte ich aber lieber keine Versuche starten.

---

ich hatte mal ähnliche probleme mit einem sbs2003premium. ich denke nicht, das hier dieselbe geschichte vorliegt, sei aber
sicherheitshalber trotzdem erwähnt. kontrolliere mal dein netzwerk "intern", ob hier korrekt die adressbereiche eingetragen
sind, vor allem die broadcast-bereiche sollten mit zu "intern" gehören. bei mir fehlte damals die 192.168.1.255, da der admin
nur bis 254 eingetragen hatte. kleiner fehler, große wirkung.

Habe ich geprüft, ist in Ordnung.

Viele Grüße,

Max

[Dieter Rauscher [MVP]]

Hallo Max,

Post by Max Habermehl
Mittlerweile hat der Teamviewer-Support einen "Fix" herausgegeben (bzw. ab
TV Version 5 standardmäßig integriert) , der die von mir gesetzten
Url-Sätze bzw. die Zugriffsregel überflüssig machen soll (ich nehme an,
der Weg via Port 80 (bzw. 8080) ist nun auch direkt auf Rechnern
störungsfrei möglich, auf denen ISA läuft - genauere Angaben zum Umfang
des "Fixes" habe ich keine erhalten).
Auf einem Server getestet --> Scheint zu klappen.

Prima! Dann ist das "Problem" nun beseitigt?

Post by Max Habermehl
Der Verkehr wurde wegen der genannten 2 Teamviewer-Regeln verweigert. Wenn
Beim Auslesen der ISA-Protokolle erhalte ich den Fehler "Firewall
protokolliert nicht nach MSDE" (gleiches gilt für den Webproxy-Dienst).
Der Fehler tritt beim bearbeiten der Abfrage-Filter auf.
Kann die ISA-Protokollierung kein W3C darstellen?

Nicht historisch, nur live. Wenn Du W3C-Protokolle nachträglich auswerten
willst, kannst Du das mit jedem Texteditor oder zum Beispiel
http://www.msisafaq.de/Anleitungen/Verschiedenes/BareTail.htm tun.

Viele Grüße
Dieter