locked
TMG 2010 - Routing durch Tunnel in entfernte DMZ klappt nicht RRS feed

  • Frage

  • Folgende Situation:
    Zwei LANs an zwei Standorten, jeweils mit einem TMG 2010 gesichert und über einen VPN-Site-to-Site-Tunnel verbunden:

    Haupt-LAN 192.168.0.0/24, Haupt-TMG = 192.168.0.15, Interface im Tunnel = 192.168.102.15
    Remote-LAN 192.168.2.0/24, Remote-TMG = 192.168.2.14, Interface im Tunnel = 192.168.100.14
    Die Verbindung funktioniert (Routen durch Assi angelegt, Netzwerkregel durch Assi angelegt, Firewallrichtlinie durch Assi angelegt).

    Zusätzlich gibt es an jedem Standort eine DMZ:

    Haupt-DMZ 192.168.4.0/24, Haupt-TMG = 192.168.4.15
    Remote-DMZ 192.168.6.0/24, Haupt-TMG = 192.168.6.14
    Routing und Zugriff Haupt-LAN -> Haupt-DMZ funktionieren ebenfalls, dto. Remote-LAN -> Remote-DMZ

    Bisher hatten wir einen weiteren VPN-Tunnel zwischen den beiden DMZs, und alle Zugriffe funktionierten;
    unser Ziel ist es nun aber, mit nur einem Tunnel auszukommen und die anderen Zugriffe entsprechend zu routen.

    Jedoch gelingt der Zugriff, z.B. von Haupt-LAN nach Remote-DMZ NICHT,
    und wir können uns nicht erklären, woran das liegt.

    Es gibt eine manuell angelegte Route zu 192.168.6.0 über Gateway 192.168.100.14 an Interface 192.168.102.15.
    Es gibt eine Netzwerkregel "Route Intern -> Remote-DMZ".
    Es gibt eine Firewallrichtlinie "Zulassen - alles - Intern -> Remote-DMZ".

    Dennoch gelingt nicht einmal "PING" auf einen Rechner in der Remote-DMZ.
    Was uns dabei völlig schleierhaft ist, als Fehler wird gemeldet, "weil die IP-Zieladresse nicht erreichbar ist".

    Das bedeutet doch aber, dass der Haupt-TMG gar nicht weiß, wie er zu einem Rechner in der DMZ routen soll, oder?

    Machen wir hier einen grundsätzlichen Denkfehler, oder fehlt es an einer bestimmten Einstellung?

    Zur Erläuterung ein Diagramm der Netzwerktopologie:

    Routing innerhalb der Standorte (0-Netz ins 4-Netz bzw. 2-Netz in 6-Netz) funktioniert,
    Routing zwischen den beiden "Intern" (die durch den Tunnel verbunden sind) (0-Netz ins 2-Netz)funktioniert auch.
    Routing durch den Tunnel in DMZ (z.B. 0-Netz ins 6-Netz) klappt nicht, weil "IP-Zieladresse nicht erreichbar".

    Vielen Dank für einen Tipp!

    ---

    Liebe Grüße, Ralf Pichocki.


    • Bearbeitet pichocki Freitag, 23. September 2016 09:22 Ergänzung
    Donnerstag, 22. September 2016 14:00

Alle Antworten

  • Da offenbar niemand eine Lösung zu unserem Problem weiß, will ich beschreiben, was wir letztendlich getan haben:

    Offenbar ist es dem TMG nicht möglich "durch den Tunnel zu routen", es reicht ihm wohl nicht aus, dass ich eine entsprechende Route angebe, sondern er muss anscheinend die Zieladressen "selbst sehen", wenn es durch den Tunnel gehen soll. (Finde ich zwar seltsam, aber da es anders einfach nicht klappen wollte, scheint es so zu sein.)

    Die "Lösung" war letztendlich, dass wir auf beiden Seiten des Tunnels jeweils ALLE beteiligten Subnetze als Teil der VPN-Verbindung definiert haben. Es gibt also EINEN Tunnel von den Subnetzen 192.168.0.0 UND 192.168.4.0 zu den Subnetzen 192.168.2.0 UND 192.168.6.0.

    Immer noch wäre ich an einer Lösung interessiert, die nur die "Haupt"-Netze (0 und 2) verbindet, und bei der ich die DMZs (4 und 6) jeweils geeignet routen kann.

    ---

    Liebe Grüße, Ralf Pichocki.




    • Bearbeitet pichocki Donnerstag, 12. Januar 2017 14:38
    Donnerstag, 12. Januar 2017 14:36
  • Moin,

    Du wirfst hier zwei Dinge in einen Topf, die nichts miteinander zu tun haben.

    Das eine ist der VPN Tunnel. Der muss alle zu erreichenden Subnetze aller Teilnehmer enthalten. In IKE Phase 2 wird nur der "Interesting Traffic" - also die definierten Subnetze - in den Tunnel geschickt. Sind Subnetze nicht in der Tunneldefinition oder einer lokalen Route enthalten, gehen sie an den Default Gateway - also ins Internet; dort werden private Subnetze i.d.R. vom Provider geblockt.

    Dein sogenanntes "Routing Problem" gibt es nicht. Das Kommunikation erlaubt oder verboten ist, wird über die Firewallregeln festgelegt. Die Routen - egal ob Tunnel, MPLS oder "was auch immer" - müssen bekannt sein. Viele einfache VPN Gateways - auch der TMG - bilden häufig automatisch eine Assoziation zwischen Tunnel-Interface, Remotegateway und Route. Manuelle Konfiguration ist dort selten möglich.

    Möchtest Du komplexere Szenarien abbilden, benötigst Du möglicherweise eine Firewall mit Policy Routing und der Möglichkeit, den Tunnel-Interfaces eigene IP Adressen zuzuweisen (Bspw. Cisco, Fortigate, Juniper). Der TMG ist eher schlicht und kann solche fortgeschrittenen Szenarien nicht abbilden.


    This posting is provided AS IS with no warranties.

    Donnerstag, 12. Januar 2017 20:16
  • Hallo, und danke für die Antwort.

    Soll das bedeuten, dass ich GRUNDSÄTZLICH nicht in ein anderes, nur durch den Tunnel zu erreichendes Subnetz routen kann?

    Du schreibst: "Sind Subnetze nicht in der Tunneldefinition oder einer lokalen Route enthalten" - genau DAS ist aber der Fall: ich habe das entfernte Subnetz in einer Route auf meinem lokalen TMG angegeben!
    Oder meinst Du mit "lokale Route", dass der TMG nur lokal (also nicht durch den Tunnel) routen kann?
    Kann er tatsächlich nur über seine eigenen (Hardware-)Adapter routen, also in seine "Kabel", nicht aber die eigene RAS-(Client-)Verbindung als Routingziel nutzen?

    Konkretes, vereinfachtes, Beispiel:

    • Ich habe einen VPN-Tunnel zwischen den zwei Netzen lokal 192.168.0.0 und remote 192.168.2.0.
    • Dieser ist lokal realisiert über die Schnittstelle 192.168.102.15 (Client am entfernten RAS-Srv).
    • Am entfernten TMG hängt zusätzlich das Subnetz 192.168.6.0.
    • Am Remote-Standort zwischen den Netzen 2 und 6 kann der dortige TMG prima routen.
    • Wenn ich lokal jedoch als Route einstelle, dass das 6er-Netz über die 102er-Schnittstelle (also den Tunnel) zu erreichen ist - dann ignoriert der TMG das?

    Ist das nicht der Sinn einer Route? Dass ich dem TMG mitteile, über welche seiner Schnittstellen er ein bestimmtes Netz erreichen kann? Damit er eben NICHT alles, was nicht direkt an ihm hängt, ins Internet routet? Was ist denn daran so schrecklich fortgeschritten?

    Freitag, 13. Januar 2017 07:33

  • Konkretes, vereinfachtes, Beispiel:

    • Ich habe einen VPN-Tunnel zwischen den zwei Netzen lokal 192.168.0.0 und remote 192.168.2.0.
    • Dieser ist lokal realisiert über die Schnittstelle 192.168.102.15 (Client am entfernten RAS-Srv).
    • Am entfernten TMG hängt zusätzlich das Subnetz 192.168.6.0.
    • Am Remote-Standort zwischen den Netzen 2 und 6 kann der dortige TMG prima routen.
    • Wenn ich lokal jedoch als Route einstelle, dass das 6er-Netz über die 102er-Schnittstelle (also den Tunnel) zu erreichen ist - dann ignoriert der TMG das?

    Ist das nicht der Sinn einer Route? Dass ich dem TMG mitteile, über welche seiner Schnittstellen er ein bestimmtes Netz erreichen kann? Damit er eben NICHT alles, was nicht direkt an ihm hängt, ins Internet routet? Was ist denn daran so schrecklich fortgeschritten?

    Das ist in diesem Beispiel kein Routing Problem, sondern ein IKE Phase 2 Problem.

    Der lokale TMG hat zwar eine Route zum 6'er Netz am Remotestandort über das Tunnelinterface. Da das 6'er Subnetz jedoch nicht in der IKE Phase2-Tunneldefinition enthalten ist, kann es nicht getunnelt werden.

    IKE Phase 2 hat nichts mit Routing zu tun.


    This posting is provided AS IS with no warranties.

    Freitag, 13. Januar 2017 09:46
  • IKE Phase 2 hat nichts mit Routing zu tun.

    Ok, danke, das habe ich "ein bisschen verstanden", zumindest so weit, dass ich jetzt einsehe, dass und warum unser erster Ansatz nicht funktionierte, der jetzige aber schon.
    (Ich bin allerdings nicht tief genug im Stoff, dass mir "IKE Phase 2" wirklich viel sagt - sorry dafür.)

    Ist das denn eine grundsätzliche Einschränkung von IKE Phase 2, oder ist das eine "Spezialität" des TMG?


    • Bearbeitet pichocki Freitag, 13. Januar 2017 10:33
    Freitag, 13. Januar 2017 10:32
  • IKE ist Bestandteil von IPSec. Ganz grob:

    IKE Phase 1 beschreibt die gegenseitige Authetifizierung per PSK oder Zertifikat

    IKE Phase 2 beschreibt den eigentlichen Tunnel, durch den die Nutzlast geht. Dazu gehören auch die Subnetze.

    Das Prinzip gilt für alle VPN Gateways, nicht nur für den TMG.

    Der TMG war noch nie ein ernsthafter VPN Gateway und wurde seit Jahren nicht mehr weiterentwickelt. Andere Hersteller bieten deutlich mehr Steuerungsmöglichkeiten.


    This posting is provided AS IS with no warranties.

    Freitag, 13. Januar 2017 16:37