10
Microsoft TMG Firewall - Internal Network Destination unreachable
Hallo,
wir besitzen eine TMG Firewall in unserem Testnetzwerk. Diese überwacht den Zugriff vom Testnetzwerk auf das Produktivsystem. Diese läuft wunderbar. Danach kommt für jeden Azubi eine eigene TMG Firewall. Diese trennt dann die Azubidomain von unserem Testnetzwerk.
Nun kamen die neuen Azubis und es mussten weitere TMG aufgesetzt werden. Dabei ist uns nun aufgefallen, dass die ganzen TMGs der Azubis keinen Zugriff auf ihre Netzwerke gestatten.
Es kommt immer die Fehlermeldung: "A packet was dropped because its destination IP address is unreachable."
Die TMGs der Azubis besitzen 2 Beinchen. Eins ins Testnetzwerk und eins eben in ihr Netzwerk. Die Policy Ping ist zu Testzwecken nun komplett offen. Man kann beide Beinchen auch anpingen. Wenn ich aber nun zum Beispiel einen Ping auf den DC von den Azubinetzwerk mache, kommt die oben beschriebene Fehlermeldung. Das interessante ist, dass ich über das interne Beinchen der TMG auch keinen in diesem Netz anpingen kann. Die Client sim Azubinetzwerk können ihr Gateway auch nicht anpingen.
Jetzt habe ich irgendwie die Vermutung, dass die TMG das interne Beinchen deaktviert hat oder so. Vielleicht wegen spoofing etc. keine Ahnung.
Ich hoffe ihr könnt mir da etwas weiterhelfen.
Vielen Dank Euch schon mal im Voraus.
wir besitzen eine TMG Firewall in unserem Testnetzwerk. Diese überwacht den Zugriff vom Testnetzwerk auf das Produktivsystem. Diese läuft wunderbar. Danach kommt für jeden Azubi eine eigene TMG Firewall. Diese trennt dann die Azubidomain von unserem Testnetzwerk.
Nun kamen die neuen Azubis und es mussten weitere TMG aufgesetzt werden. Dabei ist uns nun aufgefallen, dass die ganzen TMGs der Azubis keinen Zugriff auf ihre Netzwerke gestatten.
Es kommt immer die Fehlermeldung: "A packet was dropped because its destination IP address is unreachable."
Die TMGs der Azubis besitzen 2 Beinchen. Eins ins Testnetzwerk und eins eben in ihr Netzwerk. Die Policy Ping ist zu Testzwecken nun komplett offen. Man kann beide Beinchen auch anpingen. Wenn ich aber nun zum Beispiel einen Ping auf den DC von den Azubinetzwerk mache, kommt die oben beschriebene Fehlermeldung. Das interessante ist, dass ich über das interne Beinchen der TMG auch keinen in diesem Netz anpingen kann. Die Client sim Azubinetzwerk können ihr Gateway auch nicht anpingen.
Jetzt habe ich irgendwie die Vermutung, dass die TMG das interne Beinchen deaktviert hat oder so. Vielleicht wegen spoofing etc. keine Ahnung.
Ich hoffe ihr könnt mir da etwas weiterhelfen.
Vielen Dank Euch schon mal im Voraus.
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: 177442
Url: https://administrator.de/contentid/177442
Ausgedruckt am: 22.11.2024 um 17:11 Uhr
10 Kommentare
Neuester Kommentar
über das interne Beinchen der TMG auch keinen in diesem Netz anpingen kann. Die Client sim Azubinetzwerk können ihr Gateway auch nicht anpingen.
Alles normal beim TMG.
Der erlaubt von Haus aus nichts.
Ohne Screenshots von den Regeln und der Netzwerkzuordnung rate ich aber nicht mit.
Daran soll es nicht scheitern 
Also hier meine Firewall policies. Die Computernamen mussten geschwärzt werden aber die Regeln sollten alle selbsterklärend sein. Falls nicht, einfach fragen ;) Zu Testzwecken ist die Pingregel nach allen Seiten offen.
Unter den Network Rules habe ich die Routen All (Hinroute) und Rückroute eingetragen, damit erlaubt wird, dass Verbindungen aufgebaut werden.
Internal ist das 192.168.100.0 Netzwerk und External eben alles andere.
Zusätzlich habe ich unter Routing noch die Route vom Testnetzwerk zum Produktivsystem eingetragen. Brauche ich reintheoretisch nicht, da das Gateway der Azubinetzwerke auf die Firewall zwischen dem Testnetzwerk und Produktivsystem weiterleitet. Nur wegen der Sicherheit :D
Also hier meine Firewall policies. Die Computernamen mussten geschwärzt werden aber die Regeln sollten alle selbsterklärend sein. Falls nicht, einfach fragen ;) Zu Testzwecken ist die Pingregel nach allen Seiten offen.
Unter den Network Rules habe ich die Routen All (Hinroute) und Rückroute eingetragen, damit erlaubt wird, dass Verbindungen aufgebaut werden.
Internal ist das 192.168.100.0 Netzwerk und External eben alles andere.
Zusätzlich habe ich unter Routing noch die Route vom Testnetzwerk zum Produktivsystem eingetragen. Brauche ich reintheoretisch nicht, da das Gateway der Azubinetzwerke auf die Firewall zwischen dem Testnetzwerk und Produktivsystem weiterleitet. Nur wegen der Sicherheit :D
Also wenn ich mit dem internen Beinchen der 2. Firewall in ihrem Netz etwas anpingen möchte, klappt das auch nicht.
In der Log steht dann drin: " A packet generated on the local host was rejected because its source IP address is assigned to one network adapter and its destination IP address is reachable through another network adapter. "
Das externe Beinchen kann alles was extern ist erreichen.
In der Log steht dann drin: " A packet generated on the local host was rejected because its source IP address is assigned to one network adapter and its destination IP address is reachable through another network adapter. "
Das externe Beinchen kann alles was extern ist erreichen.
Also die Routing-Regel 4 wird schon mit Regel 2 abgedeckt.
Sonst sieht es OK aus.
Poste bitte mal die Ausgabe von
Und vom ISA die Netzwerkzuordnung für alle Netzwerke:
Sonst sieht es OK aus.
Poste bitte mal die Ausgabe von
ipconfig /all und route print.Und vom ISA die Netzwerkzuordnung für alle Netzwerke:
Die 2. Regel wurde nur erstellt, um jetzt irgendwelche Konfigurationsfehler auszuschließen. Aber wie gesagt, es ging ja noch alles vor ein paar Monaten. Und laut den Kollegen wurde nichts geändert.
Allerdings wurden die ESX-Server geupdatet. Unsere Kommunikation zwischen den Azubinetzwerk und Testnetzwerk wird über virtuelle Switche von VMWare abgedeckt. Aber ich habe alle Konfigurationen in den vSwitchen gecheckt und da keine Veränderungen feststellen können. Naja, schaut euch mal die Routen an. Vielleicht fällt euch ja was auf.
Also auf den Screenshots sehe ich soweit keinen Fehler.
Die Meldung ist relativ komisch.
Sie bedeutet, wenn du einen ISA mit den Netzwerken 1.1.1.0/24 und 2.2.2.0/24 hast und jetzt ein
Das darf er aber nicht, denn die Regeln für Routingtabellen schreiben vor, dass eine direkte Verbindung immer gewinnt.
Der ISA müsste also für ein Ping nach 1.1.1.X auch seine 1.1.1.Y IP benutzen, aber entscheided sich für die falsche IP.
Normalerweise darf das nicht passieren, außer wenn
Ist der "Client für Microsoft-Netzwerke" auf beiden Schnittstellen aktiv?
Hast du sichergestellt, das nicht in irgendeiner VM eine Netzwerkbrücke vorhanden ist?
A packet generated on the local host was rejected because its source IP address is assigned to one network adapter and its destination IP address is reachable through another network adapter.
Die Meldung ist relativ komisch.
Sie bedeutet, wenn du einen ISA mit den Netzwerken 1.1.1.0/24 und 2.2.2.0/24 hast und jetzt ein
ping 1.1.1.10 ausführst, dann benutzt der ISA als Quell-IP 2.2.2.XDas darf er aber nicht, denn die Regeln für Routingtabellen schreiben vor, dass eine direkte Verbindung immer gewinnt.
Der ISA müsste also für ein Ping nach 1.1.1.X auch seine 1.1.1.Y IP benutzen, aber entscheided sich für die falsche IP.
Normalerweise darf das nicht passieren, außer wenn
ping meint, dass das eigentliche Interface für ein ping nicht benutzt werden kann.Ist der "Client für Microsoft-Netzwerke" auf beiden Schnittstellen aktiv?
Hast du sichergestellt, das nicht in irgendeiner VM eine Netzwerkbrücke vorhanden ist?
Hey,
also ich habe nicht jede VM von jedem Azubi kontrolliert. Das sind sehr viele. Entweder muss ich das morgen wohl oder übel machen oder ich habe noch eine andere Idee.
Ich werde morgen die komplette Konfiguration der virtuellen Switche prüfen. Ich denke, dass da die Kommunikation scheitert. Da ich nach Draußen, sprich external kommunizieren kann und internal in den virtuellen Switchen abgewickelt wird. Näheres kann ich morgen erst sagen.
Deine Fragen werde ich morgen zum Teil dann auch beantworten können
also ich habe nicht jede VM von jedem Azubi kontrolliert. Das sind sehr viele. Entweder muss ich das morgen wohl oder übel machen oder ich habe noch eine andere Idee.
Ich werde morgen die komplette Konfiguration der virtuellen Switche prüfen. Ich denke, dass da die Kommunikation scheitert. Da ich nach Draußen, sprich external kommunizieren kann und internal in den virtuellen Switchen abgewickelt wird. Näheres kann ich morgen erst sagen.
Deine Fragen werde ich morgen zum Teil dann auch beantworten können
"Client for Microsoft Networks" ist auf beiden Schnittstellen aktiv!
Und IPv6 ist auch deaktiviert.
Und IPv6 ist auch deaktiviert.
Da kann ich momentan auch nichts mehr sagen.
Das könnte ich mir nur per Teamviewer mal selbst angucken.
Das könnte ich mir nur per Teamviewer mal selbst angucken.
Habe den Fehler gefunden.
Ich bin noch mal alle Einstellungen in den virtuellen switchen geprüft. Diese waren in Ordnung. Nur wurde vor einem Monat ein zusätzlicher esx Host hinzugefügt und aus irgendeinem Grund wurden die trunkporteinstellungen gelöscht und der neue esx konnte nicht mit den alten esx hosts kommunizieren.
Danke euch allen
Ich bin noch mal alle Einstellungen in den virtuellen switchen geprüft. Diese waren in Ordnung. Nur wurde vor einem Monat ein zusätzlicher esx Host hinzugefügt und aus irgendeinem Grund wurden die trunkporteinstellungen gelöscht und der neue esx konnte nicht mit den alten esx hosts kommunizieren.
Danke euch allen
