locked
VPN Clients können nicht auf einen Remote Standort zugreifen, der über einen IPSec Tunnel angebunden ist RRS feed

  • Frage

  • Hallo,

    wir haben hier eine Testinstallation zum Forefront Server mit einem Testnetz aufgebaut und bekommen folgendes Problem nicht gelöst:

    Wenn man sich über einen VPN Client einwählt, kann man in das interne Netz zugreifen. Ruft man vom VPN Client eine IP auf, die im Remote-Standard liegt, klappt der Zugriff nicht. Aus dem Intranet heraus klappt der Zugriff zum Remote-Standort. Der Standort ist über einen IPSec Tunnel aufgebaut. Eine Netzwerkregel zwischen VPN Clients, Intern und dem Remotestandort ist erstellt. Über die Diagnose habe ich keine Blockierung der Pakete feststellen können. (es wird der gesamte Datenverkehr von Intern und VPN Client erlaubt)

    Netze:

    • Intern: 192.168.80.0 – 192.168.80.255
    • Remote-Standort: 192.168.10.0 – 192.168.10.255
    • VPN Clients: 192.168.70.1 – 192.168.70.255
    • Forefront Server: 192.168.80.3
    • Remote Server: 192.168.10.5 (hier sind 2 Routen definiert, der Pakte von 192.168.80.0 und 192.168.70.0 an das VPN Gateway vom Remote Standort zurückleitet)

    Der Zugriff vom Forefront Server auf den Remote-Standort funktioniert ebenfalls nicht.

    Beispiel:

    * von 192.168.80.112 zu 192.168.10.5 über RDP geht

    * von 192.168.70.2 (VPN Client) zu 192.168.10.5 über RDP geht nicht

    * von 192.168.80.3 (Forefront Server) zu 192.168.10.5 über RDP geht nicht

    Fehlt auf dem Forefront Server noch eine statische Route? Der gleiche Test mit einem Hardware-Router ging auf Anhieb. Mir ist nun nicht klar, wieso das nicht mit dem Forefront klappt. 

    Ein PING von VPN Clients an den Remote-Server wird ebenfalls nicht beantwortet. Aus dem Intranet heraus klappt das.

    Danke
    Ralf

     

    Dienstag, 28. Dezember 2010 07:10

Alle Antworten

  • Hi,

    ganz kurz, bevor wir fortsetzen der Hinweis/Tipp: Forefront Server ist nicht ganz richtig. Um Verwechselungen auszuschliessen solltest Du den Begriff Forefront TMG verwenden, da Forefront der Sammelbegriff fuer eine ganze Reihe von Servern ist und das hier ein allgemeines Forefront Forum ist.

    Zu Deinem Problem:

    1) Wenn Du von einem VPN Client einen Tracert machst, wie sieht das Ergebnis aus? Wo wird der Zugriff gestoppt?
    2) Wenn im TMG Log keine verweigerte Verbindung gezeigt wird, sollte es eigentlich funzen. Hast Du denn in der Protokollierung erlaubte Pakete?
    3) auf dem Remote Server brauchst Du keine manuelle Route fuer die Netze. Das Routing soll ja der VPN Server im RemoteStandort machen.
    4) Die Clients im remote Standort haben den VPN Server des Remote Standorts als Gateway?
    5) Wenn Du vom TMG Server nur RDP auf den Remote VPN Server machen kannst, aber nicht auf die Clients im dahinterliegenden Netzwerk kann es ein Routingproblem sein. Du musst auf beiden VPN Servern im lokalen und Remote Standort entsprechende Routen fuer die jewweiligen Netze erstellen. Auf den Clients brauchst Du keine Routen erstellen, dass muss alles der VPN Server / TMG Server / Gateway machen


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Dienstag, 28. Dezember 2010 07:37
  • Moin,

    kannst du denn unter Sitzungen sehen, das der Tunnel aufgebaut wurde ?

    Das Zugriffe vom TMG nicht gehen, interne aber schon, könnte daran liegen, das TMG zum Netzwerk "Localhost" gehört. Wenn du also eine Regel für den Tunnel erstellst, musst du das Netzwerk localhost auch mit einbeziehen damit TMG auch was darf. Das gleiche gilt auch für die VPN-Client.

    Poste mal die Firewallpolicy für den Tunnel ..

    Was für ein System hast du auf der Gegenstelle ?

     


    Viele Grüße Carsten
    Dienstag, 28. Dezember 2010 07:47
  • und noch ein weiterer tipp von mir: kontrolliere das firewallregelwerk, auf das die benötigten protokolle zwischen den standorten erlaubt sind und checke die netzwerkregeln, es sollte eine netzwerkregel mit route-relation zwischen den betroffenen netzen vorhanden sein (intern - remotestandort). von deiner schilderung her würde ich (so das regelwerk vorhanden ist) am ehesten auf ein routingproblem tippen.
    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Dienstag, 28. Dezember 2010 09:26
  • Hallo,

    danke schon mal für die schnellen Antworten und dem Tipp mit dem Server. Es ist ein Forefront TMG.

    1) Wenn Du von einem VPN Client einen Tracert machst, wie sieht das Ergebnis aus? Wo wird der Zugriff gestoppt?

    Leider klappt bekomme ich nur von einer IP eine Antwort. Ansonsten kommt keine Antwort rein. Das konnte ich mir bisher auch noch nicht erklären, da ich dachte, über die Systemrichtlinie ICMP erlaubt zu haben. Hatte auch noch eine Firewall Regel erstellt, die PING und ICMP extra erlauben...

    VPN Client zu dem Remote Netzwerk:

    tracert 192.168.10.15

    Routenverfolgung zu 192.168.10.15 über maximal 30 Abschnitte

      1     *        *        *     Zeitüberschreitung der Anforderung.

      2   265 ms     *        *     FOREFRONT2010 [192.168.70.1]

      3     *        *        *     Zeitüberschreitung der Anforderung.

      4     *        *        *     Zeitüberschreitung der Anforderung.



    Der Tracert geht aber auch  nicht über alle Stationen, wenn ich aus dem internen Netz das mache. Es kommt nur ein PING vom internen Netz durch.

    PPP-Adapter VPN Test:

       Verbindungsspezifisches DNS-Suffix:

       Beschreibung. . . . . . . . . . . : VPN Test

       Physikalische Adresse . . . . . . :

       DHCP aktiviert. . . . . . . . . . : Nein

       Autokonfiguration aktiviert . . . : Ja

       IPv4-Adresse  . . . . . . . . . . : 192.168.70.2(Bevorzugt)

       Subnetzmaske  . . . . . . . . . . : 255.255.255.255

       Standardgateway . . . . . . . . . : 0.0.0.0

       DNS-Server  . . . . . . . . . . . : 192.168.80.3

       NetBIOS über TCP/IP . . . . . . . : Aktiviert

    Das Gateway ist auf 0.0.0.0 gesetzt. Ich wüsste nicht, wie man das bei der VPN Einwahl bestimmen kann. Eigentlich müsste das doch automatisch laufen.


    2) Wenn im TMG Log keine verweigerte Verbindung gezeigt wird, sollte es eigentlich funzen. Hast Du denn in der Protokollierung erlaubte Pakete?

    Ja, wenn ich einen PING erstellt, wird der in schwarz gezeigt. Es kommt aber keine Antwort rein.


    3) auf dem Remote Server brauchst Du keine manuelle Route fuer die Netze. Das Routing soll ja der VPN Server im RemoteStandort machen. 

    4) Die Clients im remote Standort haben den VPN Server des Remote Standorts als Gateway?

    Ja, das Gateway von dem Remote Standort ist 192.168.10.1 und hier habe ich eine Route für 192.168.80.0 und 192.168.70.0 gesetzt. 

    5) Wenn Du vom TMG Server nur RDP auf den Remote VPN Server machen kannst, aber nicht auf die Clients im dahinterliegenden Netzwerk kann es ein Routingproblem sein. Du musst auf beiden VPN Servern im lokalen und Remote Standort entsprechende Routen fuer die jewweiligen Netze erstellen. Auf den Clients brauchst Du keine Routen erstellen, dass muss alles der VPN Server / TMG Server / Gateway machen

    Also, ich habe nur 2 zusätzliche Netzwerkregen:

    Route, Quelle = Intern, VPNClients,Quarantäne , Ziel = Intern, Extern, RemoteServer (192.168.10.x)

    NAT, Quelle = Intern, VPN Clients, Quarantäne, Ziel = Extern

    Sieht einer schon den Fehler? Wie kann ich erreichen, dass die ICMP Pakete durchgelassen werden. Muss ich noch was in der Systemrichtlinie einstellen?

    Danke
    Ralf

    Dienstag, 28. Dezember 2010 11:53
  • Hallo Carsten,

    wir genau würde ich das sehen? In dem RAS Dienst? Die Firewallregeln kann man als XML exportieren. Meinst Du das? Das wäre aber recht viel. Meinst Du das?

    So schau eine Route von intern 192.168.80.112 nach Remote aus:

    Routenverfolgung zu EXTERN [192.168.10.5] über maximal 30 Abschnitte:

      1    <1 ms     *       <1 ms  FOREFRONT2010 [192.168.80.3]
      2    <1 ms     *        *     FOREFRONT2010 [192.168.80.3]
      3     *        *        *     Zeitüberschreitung der Anforderung.
      4     *        *        *     Zeitüberschreitung der Anforderung.
      5     *        *        *     Zeitüberschreitung der Anforderung.
      6     *        *        *     Zeitüberschreitung der Anforderung.
      7     *        *        *     Zeitüberschreitung der Anforderung.
      8     *        *        *     Zeitüberschreitung der Anforderung.
      9     *        *        *     Zeitüberschreitung der Anforderung.
     10     *        *        *     Zeitüberschreitung der Anforderung.
     11     *        *        *     Zeitüberschreitung der Anforderung.
     12   847 ms    17 ms    15 ms  EXTERN [192.168.10.5]

    Von dem Forefornt TMG selbts kommt keine Routenverfolgung zu stande.

    Ralf

    Dienstag, 28. Dezember 2010 12:20
  • So eine Regel ist vorhanden:

    Route, Quelle = Intern, VPNClients,Quarantäne , Ziel = Intern, Extern, RemoteServer (192.168.10.x)

    NAT, Quelle = Intern, VPN Clients, Quarantäne, Ziel = Extern

     

    Dienstag, 28. Dezember 2010 12:21
  • Hi,

    Netzwerkverhaeltnis ROUTE von INTERN nach EXTERN? Machst Du kein NAT?


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Dienstag, 28. Dezember 2010 12:35
  • Hi,

    sieht wirklich nach einem Routenproblem aus. Du musst wirklich alle Netzwerke / Regeln und Routen nochmal checken. Hast Du die Routen ueber die Netzwerktopologierouten am TMG erstellt?


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Dienstag, 28. Dezember 2010 12:37
  • Hi,

    was heisst denn es kommt nur von einer IP eine Antwort? Wenn eine antwortet, ist das Routing OK?
    Das Gateway am Client kannst Du nicht bestimmen, der ganze Traffic geht dann ueber den TMG und seine Netzwerke, das ist OK so!
    Wenn Ping im Log auftaucht dann vermutlich als iniitierte Verbindung? Die Antwortpakete kommen aber nicht zurueck was auf ein Routingproblem deutet
    also nochmal alle Netzwerkregeln und Routen checken


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Dienstag, 28. Dezember 2010 12:44
  • Ob ein Tunnel steh, kann man in der TMG Konsole unter "Sitzungen" sehen. Da du aber eine RDP-Verbindung hinbekommst, steht der Tunnel.

    Bleibt noch die Frage des Systems auf der Gegenstelle.

    Bei den Policys reicht mir der Inhalt für die Regel, die für den Tunnel erstellt wurde.

    von 192.168.80.112 zu 192.168.10.5 über RDP geht
    gut ;) Tunnel funktioniert

    * von 192.168.70.2 (VPN Client) zu 192.168.10.5 über RDP geht nicht
    evt. kommt die Antwort nicht zurück. Poste mal ein route print von der 192.168.10.5
    das VPN-Netzt muss auch in der Firewall-Policy erlaubt sein
    Die Gegenstelle muss das Netz auch erlauben

     

    * von 192.168.80.3 (Forefront Server) zu 192.168.10.5 über RDP geht nicht
    hier fehlt denke ich das Netzwerk "localhost" in der Regel

    Also:
    - Firewal-Policy auf beiden Seiten checken
    - route print posten

     


    Viele Grüße Carsten
    Dienstag, 28. Dezember 2010 13:30
  • Leider immer noch kein Erfolg. Ich kann mit den anderen Routing-Regeln rumspielen und es verhält sich alles so wie gewünscht. Hier die Routing Tabelle:

    IPv4-Routentabelle

    ===========================================================================

    Aktive Routen:

         Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik

              0.0.0.0          0.0.0.0    85.180.200.17    85.180.200.28    258

        85.180.200.16  255.255.255.240   Auf Verbindung     85.180.200.28    258

        85.180.200.28  255.255.255.255   Auf Verbindung     85.180.200.28    258

        85.180.200.31  255.255.255.255   Auf Verbindung     85.180.200.28    258

            127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306

            127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306

      127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306

          192.168.1.0    255.255.255.0   Auf Verbindung       192.168.1.3    257

          192.168.1.3  255.255.255.255   Auf Verbindung       192.168.1.3    257

        192.168.1.255  255.255.255.255   Auf Verbindung       192.168.1.3    257

         192.168.70.1  255.255.255.255   Auf Verbindung      192.168.70.1    291

         192.168.70.4  255.255.255.255     192.168.70.4     192.168.70.1     36

         192.168.80.0    255.255.255.0   Auf Verbindung      192.168.80.3    276

         192.168.80.3  255.255.255.255   Auf Verbindung      192.168.80.3    276

       192.168.80.255  255.255.255.255   Auf Verbindung      192.168.80.3    276

            224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306

            224.0.0.0        240.0.0.0   Auf Verbindung      192.168.80.3    276

            224.0.0.0        240.0.0.0   Auf Verbindung     85.180.200.28    258

            224.0.0.0        240.0.0.0   Auf Verbindung       192.168.1.3    257

            224.0.0.0        240.0.0.0   Auf Verbindung      192.168.70.1    291

      255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306

      255.255.255.255  255.255.255.255   Auf Verbindung      192.168.80.3    276

      255.255.255.255  255.255.255.255   Auf Verbindung     85.180.200.28    258

      255.255.255.255  255.255.255.255   Auf Verbindung       192.168.1.3    257

      255.255.255.255  255.255.255.255   Auf Verbindung      192.168.70.1    291

    ===========================================================================

    Ständige Routen:

      Netzwerkadresse          Netzmaske  Gatewayadresse  Metrik

              0.0.0.0          0.0.0.0    85.180.200.17  Standard

    ===========================================================================

     

    IPv6-Routentabelle

    ===========================================================================

    Aktive Routen:

     If Metrik Netzwerkziel             Gateway

      1    306 ::1/128                  Auf Verbindung

      1    306 ff00::/8                 Auf Verbindung

    ===========================================================================

    Ständige Routen:

      Keine

     

    Nach den Firewallrichtlinie ist der gesamte Datenverkehr zugelassen. So ist das auch in dem externen VPN Gateway eingestellt (ist ein mGuard). Die Gleiche Teststellung mit einem Astaro Router (anstelle dem TMG) hat auf Anhieb funktioniert. 

    Wieso klappt das mit dem TMG Produkt nicht. Es ist mir ein Rätsel. Aus lauter Verzweiflung habe ich den IPSec Tunnel noch um einen Tunnel erweitert: 192.168.10.0/24 und 192.168.70.0/24

    Pakte nach 192.168.70.4 werden zurück an 192.168.10.1 geschickt (also an das Gateway von dem Remote-Standort - müsste also wieder bei dem TMG ankommen).

    Sieht aber so aus, als wenn das nicht so ist.

    Noch eine Idee? 

    Dienstag, 28. Dezember 2010 21:10
  • Ist das die Routingtabelle der Kiste  192.168.10.5 ?

    poste mal bitte zusätzlich ein ipconfig /all und route print von der Adresse  192.168.10.5 !!!

    Wir werden dann einen "manuellen" tracert von dort aus starten ... 


    Viele Grüße Carsten
    Mittwoch, 29. Dezember 2010 11:36
  • Ich habe auf dem 192.168.10.5 folgende ständige Routen:

      Netzwerkadresse          Netzmaske  Gatewayadresse  Metrik
          192.168.0.0    255.255.255.0     192.168.10.1       1
         192.168.20.0    255.255.255.0     192.168.10.1       1
         192.168.80.0    255.255.255.0     192.168.10.1       1
         192.168.70.0    255.255.255.0     192.168.10.1       1

    Nachdem ich die Firewallregel für PING und ICMP auch für eingehende Verbindungen konfiguriert habe (also aus dem RemoteNetz an Intern) klappt auch ein Tracert.

    Routenverfolgung zu 192.168.80.112 über maximal 30 Abschnitte

      1    <1 ms    <1 ms    <1 ms  192.168.10.1
      2     *        *        *     Zeitüberschreitung der Anforderung.
      3     *       15 ms    14 ms  192.168.80.112

    Ablaufverfolgung beendet.

    Routenverfolgung zu 192.168.70.1 über maximal 30 Abschnitte

      1    13 ms    15 ms    <1 ms  192.168.10.1
      2     *        *        *     Zeitüberschreitung der Anforderung.
      3     *        *        *     Zeitüberschreitung der Anforderung.
      4     *        *        *     Zeitüberschreitung der Anforderung.
      5     *        *        *     Zeitüberschreitung der Anforderung.
    usw...

    Der Tracert vom Laptop über VPN Einwahl von 192.168.70.6 bekommt nur einmal den Forefront2010 mit 192.168.70.1 zu sehen und mehr nicht.

    Routenverfolgung zu 192.168.10.5 über maximal 30 Abschnitte

      1     *        *        *     Zeitüberschreitung der Anforderung.
      2   194 ms     *        *     FOREFRONT2010 [192.168.70.1]
      3     *        *        *     Zeitüberschreitung der Anforderung.
      4     *        *        *     Zeitüberschreitung der Anforderung.
    usw...

    Vom VPN Client ins Intranet geht.

    Routenverfolgung zu 192.168.80.112 über maximal 30 Abschnitte

      1     *        *        *     Zeitüberschreitung der Anforderung.
      2     *        *        *     Zeitüberschreitung der Anforderung.
      3  1422 ms   358 ms   377 ms  [192.168.80.112]

    Aus meiner Sicht klappt das Routing nicht von einem VPN Client in das RemoteNetzwerk, obwohl eine Netzwerkregel vorhanden ist. Die Gegenprobe mit dem internen Netz klappt. Nimmt man die Regel raus, kommt man vom Intranet in das Remotenetz nicht mehr. Ergo müsste ja die VPN regel zum RemoteNetz korrekt sein.

    Das sieht so aus, als wenn der TMG nichts mit den Paketen anfangen kann. Muss man eine Route noch in dem RAS Dienst eintragen, damit er weiss, dass Pakete von 192.168.10.0 auch in das 192.168.70.x Netz geroutet werden?

     

    Mittwoch, 29. Dezember 2010 12:23
  • Du brauchst keine Konfigurationen im RAS-Dienst vornehmen. Das wird über die Netzwerkregeln durchgeführt.
    Route, Quelle = Intern, VPNClients,Quarantäne , Ziel = Intern, Extern, RemoteServer (192.168.10.x)

    PS: (ich würde extern aus der Route Regel entfernen)

    Wenn du dich per VPN einwählst, und dann ein tracert zur 192.168.10.5 startest, siehst du die 192.168.70.1.

    Was wird dabei im Log des TMG angezeigt ?


    Viele Grüße Carsten
    Mittwoch, 29. Dezember 2010 13:29
  • Du brauchst keine Konfigurationen im RAS-Dienst vornehmen. Das wird über die Netzwerkregeln durchgeführt.
    Route, Quelle = Intern, VPNClients,Quarantäne , Ziel = Intern, Extern, RemoteServer (192.168.10.x)

    Ist so gesetzt und Extern ist raus. Der Server 192.168.70.1 ist in dem Tracert enthalten. Sonst meldet sich aber keine Server.

    RDP Versuch von VPN client zu Remote Standort:

    + 9088 FOREFRONT2010   2010-12-29      16:25:27        TCP     192.168.70.4:49256      192.168.80.112:3389     192.168.70.4    VPN-Clients     Intern  Establish       0x0     Netzwerkdienste RDP (Terminaldienste)   Y       0       0       0       0       -       -       -       FOREFRONT2010\thietztest        -       26      181     -       -       -       2010-12-29 16:25:27     -       -       ::      -       -       -       Trusted -       -       -       -       -       0       -       -
    + 9090 FOREFRONT2010   2010-12-29      16:25:29        TCP     192.168.70.4:49256      192.168.80.112:3389     192.168.70.4    VPN-Clients     Intern  Terminate       0x80074e21      Netzwerkdienste RDP (Terminaldienste)   Y       191     191     191     191     1997    1997    -       FOREFRONT2010\thietztest        -       26      181     -       -       -       2010-12-29 16:25:29     -       -       ::      -       -       -       Trusted -       -       -       -       -       0       -       -
    + 9091 FOREFRONT2010   2010-12-29      16:25:29        TCP     192.168.70.4:49257      192.168.80.112:3389     192.168.70.4    VPN-Clients     Intern  Establish       0x0     Netzwerkdienste RDP (Terminaldienste)   Y       0       0       0       0       -       -       -       FOREFRONT2010\thietztest        -       26      182     -       -       -       2010-12-29 16:25:29     -       -       ::      -       -       -       Trusted -       -       -       -       -       0       -       -
    + 9107 FOREFRONT2010   2010-12-29      16:25:43        TCP     192.168.70.4:49257      192.168.80.112:3389     192.168.70.4    VPN-Clients     Intern  Terminate       0x80074e21      Netzwerkdienste RDP (Terminaldienste)   Y       28616   28616   30351   30351   13993   13993   -       FOREFRONT2010\thietztest        -       26      182     -       -       -       2010-12-29 16:25:43     -       -       ::      -       -       -       Trusted -       -       -       -       -       0       -       -

    8434 FOREFRONT2010   2010-12-29      16:17:13        ICMP    192.168.70.3:2048       192.168.10.5     192.168.70.3    VPN-Clients     RemoteServer    Denied   0xc004005a      Keine - siehe Ergebniscode      PING    N       0       0       0       0       -       -       -       -       -       0       0       192.168.70.1    45 00 00 5c 01 24 00 00 01 01 e7 24 c0 a8 46 03 c0 a8 0a 05     08 00 f6 e0 00 01 01 1e 00 00 00 00 00 00 00 00 00 00 00 00     2010-12-29 16:17:13     -       -       ::      -       -       -       Trusted -       -       -       -       -       0       -       -
    8435 FOREFRONT2010   2010-12-29      16:17:13        ICMP    192.168.70.3:2048       192.168.10.5     192.168.70.3    VPN-Clients     RemoteServer    Denied   0xc004005a      Keine - siehe Ergebniscode      PING    N       0       0       0       0       -       -       -       -       -       0       0       192.168.70.1    45 00 00 5c 01 26 00 00 01 01 e7 22 c0 a8 46 03 c0 a8 0a 05     08 00 f6 de 00 01 01 20 00 00 00 00 00 00 00 00 00 00 00 00     2010-12-29 16:17:13     -       -       ::      -       -       -       Trusted -       -       -       -       -       0       -       -
    8527 FOREFRONT2010   2010-12-29      16:18:02        TCP     192.168.70.3:49249      192.168.10.5:3389       192.168.70.3    VPN-Clients     RemoteServer    Terminate       0xc0040038      Netzwerkdienste   RDP (Terminaldienste)   Y       104     104     0       0       61994   61994   -       FOREFRONT2010\thietztest        -       20      137     -       -       -       2010-12-29 16:18:02     -       -       ::      -       -       -       Trusted -       -       -       -       -       0       -       -
    8537 FOREFRONT2010   2010-12-29      16:18:11        UDP     192.168.70.3:137        192.168.10.5:137        192.168.70.3    VPN-Clients     RemoteServer    Terminate       0x80074e20      Netzwerkdienste   NetBios-Namendienst     Y       234     234     0       0       64008   64008   -       FOREFRONT2010\thietztest        -       20      140     -       -       -       2010-12-29 16:18:11     -       -       ::      -       -       -       Trusted -       -       -       -       -       0       -       -
    8858 FOREFRONT2010   2010-12-29      16:23:02        ICMP    192.168.70.3:8   192.168.10.5     192.168.70.3    VPN-Clients     RemoteServer    Terminate       0x80074e20      Netzwerkdienste   PING      N       9568    9568    0       0       485818  485818  -       FOREFRONT2010\thietztest        -       20      119     -       -       -       2010-12-29 16:23:02     -       -       ::      -       -       -       Trusted -       -       -       -       -       0       -       -
    9129 FOREFRONT2010   2010-12-29      16:25:53        TCP     192.168.70.4:49258      192.168.10.5:3389       192.168.70.4    VPN-Clients     RemoteServer    Establish       0x0      Netzwerkdienste R  DP (Terminaldienste)   Y       0       0       0       0       -       -       -       FOREFRONT2010\thietztest        -       26      187     -       -       -       2010-12-29 16:25:53     -       -       ::      -       -       -       Trusted -       -       -       -       -       0       -       -

    Eine RDP von dem VPN Client zu 192.168.80.112 klappt - zu 192.168.10.5 kommt keine Antwort.  

    Mittwoch, 29. Dezember 2010 16:29
  • Ergebnis aus der Simulation:

    Zugelassener Datenverkehr

    Regelname: Netzwerkdienste
     
    Regelreihenfolge: 1
    Zusätzliche Informationen

    Von: VPN-Clients
    An: RemoteServer
    Netzwerkregelname: Intern an Remote
    Netzwerkbeziehung: Route
    Protokoll: RDP (Terminaldienste)
    Regelanwendungsfilter: <>

    Von Firewallrichtlinienregeln zugelassener Datenverkehr wird möglicherweise von Webfiltern oder Anwendungsfiltern blockiert.

     

    Mittwoch, 29. Dezember 2010 16:37
  • Wenn ich das Log richtig lese, werden verbindungsversuche vom vpn-client ins remotenetzwerk ohne angabe einer Regel geblockt.

    Das ist eigentlich ein Zeichen dafür, das die Netzwerk-Konfiguration nicht passt ...

    Aktuell ist das Netzverhältnis jetzt so:

     Quelle = Intern, VPNClients,Quarantäne , Ziel = Intern, RemoteServer

    Versuche es mal mit folgender Regel:

    Quelle = Intern Ziel = VPN-Clients, Quarantäne (optional) und RemoteServer Verhältnis Route

     


    Viele Grüße Carsten
    • Als Antwort vorgeschlagen Marc.Grote Donnerstag, 30. Dezember 2010 15:13
    Mittwoch, 29. Dezember 2010 17:58
  • Das habe ich nun so eingestellt. Leider keine Besserung.

    Ich habe auch mal die Regel mit dem NAT Verhätnis entfernt und noch mal weitere Kombinationen getestet.

    Leider ohne erfolgt.

    Test:

    Zugelassener Datenverkehr
    Regelname: Netzwerkdienste
    Regelreihenfolge: 1

    Zusätzliche Informationen

            * Von: VPN-Clients
            * An: RemoteServer
            * Netzwerkregelname: VPN Client zu Intern, Remote
            * Netzwerkbeziehung: Route
            * Protokoll: RDP (Terminaldienste)
            * Regelanwendungsfilter: <>

    Von Firewallrichtlinienregeln zugelassener Datenverkehr wird möglicherweise von Webfiltern oder Anwendungsfiltern blockiert.

    Donnerstag, 30. Dezember 2010 11:01
  • Hilft das hier noch weiter?

     

    6440    FOREFRONT2010   2010-12-30      09:59:37        TCP     192.168.70.3:49750      192.168.10.5:3389       192.168.70.3    VPN-Clients     RemoteServer    Establish       0x0     Netzwerkdienste RDP (Terminaldienste)   Y

    6446    FOREFRONT2010   2010-12-30      09:59:46        TCP     192.168.70.3:49749      192.168.10.5:3389       192.168.70.3    VPN-Clients     RemoteServer    Terminate       0xc0040038      Netzwerkdienste RDP (Terminaldienste)   Y

    6487    FOREFRONT2010   2010-12-30      10:00:07        UDP     192.168.70.3:137        192.168.10.5:137        192.168.70.3    VPN-Clients     RemoteServer    Terminate       0x80074e20      Netzwerkdienste NetBios-Namendienst     Y

    6543    FOREFRONT2010   2010-12-30      10:00:46        TCP     192.168.70.3:49750      192.168.10.5:3389       192.168.70.3    VPN-Clients     RemoteServer    Terminate       0xc0040038      Netzwerkdienste RDP (Terminaldienste)   Y

    6941    FOREFRONT2010   2010-12-30      10:05:19        TCP     192.168.70.3:49751      192.168.10.5:3389       192.168.70.3    VPN-Clients     RemoteServer    Establish       0x0     Netzwerkdienste RDP (Terminaldienste)   Y

     

    Donnerstag, 30. Dezember 2010 11:09
  • Im Logfile von Gestern hatten wir einen anderen Statuscode ...

    Der Code  0xc0040038  sagt, das keine Antwort zurück kommt ....

    Kannst du die Pakete auf der zweiten Firewall sehen ?

    Noch ne andere Frage: Hast du Alerts im TMG (Dashboard)


    Viele Grüße Carsten
    Donnerstag, 30. Dezember 2010 12:01
  • Hallo Carsten,

    die Pakete kann man auf der RemoteFirewall sehen.

    2010-12-30_14:20:41.78409 kernel: fw-vpn-v005_000-in-1-352be743-82e5-16f2-b00e-000cbe013488 act=ACCEPT IN=ipsec0 OUT=eth1 SRC=192.168.80.112 DST=192.168.10.5 LEN=60 TOS=0x00 PREC=0x00 TTL=126 ID=31611 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=6666 
    2010-12-30_14:20:42.46318 kernel: fw-vpn-v005_000-in-1-352be743-82e5-16f2-b00e-000cbe013488 act=ACCEPT IN=ipsec0 OUT=eth1 SRC=192.168.70.2 DST=192.168.10.5 LEN=60 TOS=0x00 PREC=0x00 TTL=126 ID=3476 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=11983
    2010-12-30_14:20:42.79802 kernel: fw-vpn-v005_000-in-1-352be743-82e5-16f2-b00e-000cbe013488 act=ACCEPT IN=ipsec0 OUT=eth1 SRC=192.168.80.112 DST=192.168.10.5 LEN=60 TOS=0x00 PREC=0x00 TTL=126 ID=31616 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=6922
    2010-12-30_14:20:43.46346 kernel: fw-vpn-v005_000-in-1-352be743-82e5-16f2-b00e-000cbe013488 act=ACCEPT IN=ipsec0 OUT=eth1 SRC=192.168.70.2 DST=192.168.10.5 LEN=60 TOS=0x00 PREC=0x00 TTL=126 ID=3479 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=11985
    2010-12-30_14:20:43.81459 kernel: fw-vpn-v005_000-in-1-352be743-82e5-16f2-b00e-000cbe013488 act=ACCEPT IN=ipsec0 OUT=eth1 SRC=192.168.80.112 DST=192.168.10.5 LEN=60 TOS=0x00 PREC=0x00 TTL=126 ID=31620 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=7178
    2010-12-30_14:20:44.46396 kernel: fw-vpn-v005_000-in-1-352be743-82e5-16f2-b00e-000cbe013488 act=ACCEPT IN=ipsec0 OUT=eth1 SRC=192.168.70.2 DST=192.168.10.5 LEN=60 TOS=0x00 PREC=0x00 TTL=126 ID=3481 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=11987

    Ich habe ja einen IPSec Tunnel angelegt und darin zum Schluss 2 Netze:

    192.168.10.0/24  192.168.80.0/24

    und dann noch angelegt:

    192.168.10.0/24  192.168.70.0/24

    Nach einem Reset des RemoteGateways klappt der Verbindungsbaufbau (krass, dass es daran gelegen hat).

    Wenn ich nun eine Kleinigkeit in dem entfernen router ändere oder den Tunnel nur neu starte, kommt keine Verbindung mehr zu stande. (aus dem 192.168.80.x Netzwerk geht es immer)

    Kann ich auch dem Forefront sagen, dass er die Pakete von 192.168.70.x so umwandeln soll, dass diese von 192.168.80.x kommen? Würde das gehen?

    Oder noch eine andere Idee?

    Danke
    Ralf

     

    Donnerstag, 30. Dezember 2010 13:23
  • mmmhhh, du könntest den Adresspool für die VPN-Clients aus dem internen Netz verwenden oder sie direkt vom internen DHCP abverlangen ....

    Die 70 auf 80 zu naten klinkt nach keiner guten Idee


    Viele Grüße Carsten
    Donnerstag, 30. Dezember 2010 13:33
  • Mum, ich werde das nun erst mal beobachten und dann mal den Hersteller von dem RemoteVPN Gateway anfragen. Vielleicht gibt es ja dafür eine Erklärung.

    Rückblickend hat es folgende Probleme gegeben:

    * Wegen 192.168.70.x musste in dem IPSec Tunnel ein zusätzlicher Tunnel integriert werden (ich hatte gedacht, dass sich der Server immer unter 192.168.80.3 melden würde - das war falsch).

    * Die Rückrichtung musste auf dem Remote-Server auch eingetragen werden über eine statische Route. (der hat noch ein anderes Gateway)

    * Wenn es ohne Neustart von dem RemoteVPN Router direkt geklappt hätte, wäre alles schneller gegangen. So hat man lange an der falschen Stelle gesucht.

    Habe nun auch eine Redundanz beim ISP konfiguriert und die Routen stehen immer noch. Sieht so aus, also wäre das Problem gelöst.

    Herzlichen Dank noch mal für die Hilfe und einen guten Rusch :-)

    Ralf

    Donnerstag, 30. Dezember 2010 15:02