Microsoft TMG 2010, HP Server und VLAN Tagging – Beschreibung eines “unglaublichen” Problems

Letzte Woche gelang die Lösung eines Problems, welches mich bei einem Kunden schon fast ein Jahr beschäftigt. Es ist eines der Probleme aus der Gattung “das kann so aber garnicht sein” und hat sich daher lange gegen eine Lösung gewehrt. Wir konnten es auch nicht zum Support eines Geräteherstellers eskalieren, die Beteiligten schoben sich gegenseitig die Schuld zu, denn die Beteiligten sind:

• Ein Windows 2008 R2 Server von Microsoft mit Microsoft Threat Management Gateway (TMG) 2010 als Proxy-Server und Firewall zum Internet
• Der läuft auf einem Hewlett Packard ProLiant DL 350 Server mit originalen HP Netzwerkkarten
• Zum Backbone und zu den VLANs angeschlossen per Cisco Switches
• Zum Internet direkt am Router des Providers

Da war für unser Problem natürlich keiner zuständig und “das kann so aber garnicht sein” habe ich öfter gehört. Nun aber zu diesem völlig unglaublichen Problem:

Der Proxy verbindet mehrere “fremde” Netzwerke im Haus mit dem Backbone und läßt den Zugriff auf ausgewählte Rechner dort und aufs Internet zu. Diese “fremden” Netzwerke werden immer mehr und uns gingen die Ports am Server aus. Ich möchte in ein Gerät, das seit einem Jahr superstabil läuft, keine neue Netzwerkkarte einbauen. Also stellten wir einen der Ports am Switch als VLAN Trunk ein mit dem Ziel, die Pakete der einzelnen VLANs auf diesem Port via VLAN Tagging abzugreifen. Der HP Server generiert dazu für jedes VLAN, das man anmeldet eine eigene Netzwerkkarte, so daß man diese im TMG eintragen kann und die Pakete ganz gewohnt routen oder NATen kann.

So weit, so gut, die Konfiguration war schnell eingetragen, vom Firewall konnte man auch munter alle Geräte in den VLANs anpingen, man konnte von überall her aus ins Internet, man konnte vom Backbone Geräte in den “fremden” Netzwerken anpingen, der Reply kam aber nie zurück. Der Netzwerksniffer zeigt, daß der Ping auf dem Backbone Adapter ankommt, vom Firewall weitergeleitet wird, im “fremden” Netzwerk ausgeliefert wird, dort der Reply zurückkommt, vom Firewall wieder weitergeleitet und auf dem Backbone Adapter abgeliefert wird. Im Sniffier auf dem Backbone Switch kommen die Pakete aber nie an. Wo gehen sie verloren?

Zurückgeswitcht auf Portbasierte VLANS flutschen die Pakete sofort wieder und alles ist wieder gut (bis auf die Tatsache, daß uns die Ports ausgehen). Der Backbone Port des Proxy ist sowieso nur auf portbasiertes VLAN eingestellt und das VLAN Tagging ist im Netzwerkadapter abgeschaltet:

Alles stellte sich so dar, als ob die Pakete, wenn sie aus dem VLAN zurückkommen, vom Backbone Switch einfach nicht mehr akzeptiert würden. Da sitzt man natürlich zwischen den Stühlen. Microsoft verweist darauf, daß TMG 2010 tagged VLANS einwandfrei unterstützen würde, der Betreuer des Netzwerkswitches verweist darauf, daß das Paket auf seinem Switch nicht ankommen würde (mit einem gewissen Unterton, der so etwa klingt wie “man nimmt auch keine Microsoft Produkte zum Routen her“), HP schließlich verweist darauf, daß die tagged VLANs erstklassig funktionieren und man schließlich vom Proxy aus PINGen könnte.

Eine Idee war, man könnte zwischen den Backbone Switch und den Proxy einen Switch von HP schalten, die haben wir aber wieder verworfen, weil das sind bei HP ja auch zwei verschiedene Abteilungen.

Also muß man grundlagentheoretisch an das Problem rangehen:

• PINGt man vom Backbone ins “fremde” Netzwerk, kann man das Paket jeweils sehen: auf dem Backbone Adapter des Proxy, auf dem Adapter fürs “fremde” Netzwerk auf dem Proxy, am Endgerät, dann wieder auf dem Adapter fürs “fremde” Netzwerk auf dem Proxy, dann nochmal auf dem Backbone Adapter des Proxy, dann ists weg.
• PINGt man vom Endgerät in den Backbone sieht man das Paket am Endgerät, dann wieder auf dem Adapter fürs “fremde” Netzwerk auf dem Proxy, dann nochmal auf dem Backbone Adapter des Proxy, dann ists weg.

Das Problem kann also begrenzt werden auf Pakete, die aus einem tagged VLAN in das untagged VLAN geroutet werden. In der Netzwerktheorie gehen wir natürlich davon aus, daß die 802.1Q Headers im Frame beim Routing über Layer 3 aus den Paketen entfernt werden. Was wäre aber, wenn nicht? Wenn das Paket aus dem VLAN nach dem Routing durch den TMG 2010 sein VLAN Tag immer noch behalten hätte? Dann müßten wir folglich auf den Backbone Switch ein Paket sehen, wenn wir den Port auf Trunk stellen und mit dem Sniffer genau das VLAN abgreifen aus dem wir auch PINGen.

Ich könnte nicht behaupten, daß wir uns irre gefreut haben, als wir das Paket sahen. Aber es ist tatsächlich so. Pakete, die von Microsoft TMG auf einem HP ProLiant Server aus einem tagged VLAN in ein untagged VLAN geroutet werden, behalten ihr VLAN Tag bei! Das ist für mich völlig widersinnig, ich konnte aber keine Dokumentation irgendwo finden (bis jetzt), die das bestätigen oder widerlegen würde. Ich kann nur theoretisch entscheiden, daß es beim Routing absolut keinen Sinn macht, ein VLAN Tag mitzugeben, denn selbst, wenn das Zielnetz VLAN Tags besitzt, sind die sicher nicht die gleichen, wie im Quellnetz.

Oder macht es vielleicht doch Sinn?

Sieht man sich den 802.1Q Header genau an, dann transportiert der nicht nur das VLAN Tag, sondern auch die Priority aus der Class of Service (CoS):

Egal, ob das Sinn macht, oder nicht, Priority hatte ich schon mal gesehen – an den Adaptersettings des HP Netzwerkadapters. Genau im Zusammenhang mit den Erweiterten Einstellungen für die VLANs kann man zusätzlich die Priority deaktivieren. Tut man das, wird anscheinend der gesamte 802.1Q Header aus allen Paketen auf diesem Adapter entfernt, denn auf einmal funktioniert das Routing einwandfrei!

Und die Moral von der Geschichte: Man stelle jeden HP Server Netzwerkadapter, der nicht an einem VLAN Port Trunk hängt auf “Priority & VLAN disabled” ein.

Noch ein Nachtrag: Auch wenn der Microsoft TMG 2010 als Proxyserver gerne belächelt wird – er ist stabil und ohne weitere Zusatzprodukte in der Lage, Internetbenutzer anhand ihres Logins im Active Directory zu identifizieren und den Namen des Benutzers ganz einfach ins Log zu schreiben.

Artikel, die Sie auch interessieren könnten:

• Interessantes Problem nach Änderung des Default VLANs an einem Switchport
• Mit dem Microsoft TMG Proxy auf ungewöhnlichen Ports per SSL kommunizieren
• Fehler im Service Pack 2 für Microsoft TMG 2010 nun behoben
• GFI MailSecurity darf auf keinen Fall auf einem Microsoft Forefront TMG Server installiert werden!
• So funktioniert der endlos haltbare Akku an meinem Notebook
• ILO Port in HP Insight Manager ist degraded
• Einer der letzten seiner Art - mein neuer Laptop
• Power Shell Editor
• Mit Junction einzelne Verzeichnisse auf eine andere Platte mappen
• Zuordnen von Computern zu Active Directory Gruppen