VPN S2S - Verbindung mit Drittanbieter klappt nicht richtig

23/04/2008 - 14:34 von Markus Dotzel | Report spam
Hallo,
vielleicht kann mir jemand einen Tipp geben.

Vorsicht jetzt wird es ein wenig umfangreich um mein Problem zu beschreiben.
Hoffentlich hat jemand lust diese Menge an Text zu lesen.


Habe eine S2S-VPN-Verbindung (Ipsec) mit einer Support-Firma aufgebaut.
Zwischen einem ISA2004 (meine FW) und einer Fortinet (Support Firma).

Folgendes Problem tritt allerdings hierbei auf. Der VPN-Tunnel làsst sich
nur von der Gegenstelle aus aufbauen. Hin und wieder bricht der Tunnel ab und
eine neue Verbindung làsst sich nicht mehr aufbauen. Hier kommt es allerdings
darauf an von welcher Seite als erstes nach dem Verbindungsabbruch der
Neuaufbau der Verbindung stattfindet. Von der Gegenstelle klappt es immer,
wenn nicht von meiner Seite aus vorher versucht wurde die Verbindung
aufzubauen. Falls dies der Fall ist, kann die Verbindung weder von mir noch
von der Gegenstelle mehr aufgebaut werden. Erst nachdem die Zeit für die
Phase 2 abgelaufen ist.

Probleme gibt es allerdings immer auch nur bei dem Aufbau der Phase 2 die
Phase 1 ist immer erfolgreich.

Nach einiger Recherche habe ich einen möglichen Grund für dieses Problem
gefunden.
Beim Versuch die Verbindung von meiner Seite aufzubauen. Wird folgendes im
IPSec-Protokoll protokolliert.

4-22: 13:36:54:156:544 Acquire from driver: op000006 src2.16.195.3.0
dst.10.125.250.0 proto = 0, SrcMask%5.255.0.0, DstMask%5.255.255.0,
Tunnel 1, TunnelEndpt!7.6.108.182 Inbound TunnelEndpt‚.212.250.2
4-22: 13:36:54:296:1cc Filter to match: Src 217.6.108.182 Dst 82.212.250.2
4-22: 13:36:54:296:1cc MM PolicyName: ISA Server Site-To-Site-Command MM
Policy

4-22: 13:36:54:640:1cc Starting Negotiation: src = 82.212.250.2.0500, dst =
217.6.108.182.0500, proto = 00, context = 00000006, ProxySrc =
172.16.0.0.0000, ProxyDst = 10.10.125.0.0000 SrcMask = 255.255.0.0 DstMask =
255.255.255.0

Hier steht bei SrcMask%5.255.0.0
Diese SubnestMaske ist allerdings nicht korrekt. Sie müsste eigentlich
255.255.255.248 lauten.

In den Firewallrichtlinien vom ISA2004 ist diese Quelle immer mit der
SubnetMask /29 angegeben. In den Netzwerkregeln wurde auch diese SubnetMask
verwendet.

Hier ein paar Infos zur Konfiguration.

LAN Remote <-> Remote Gateway <-> www <-> ISA2004 <-> DMZ <-> ISA2004 <->
LAN <-> Subnetz 172.16.195.3.0 /29

Das Subnetz 172.16.195.3.0 /29 ist ein künstlich erzeugtes Subnetz im
Subnetz 172.16.0.0 /24 da die Gegenstelle (Supportfirma) nicht unser ganzes
LAN-Netz freischalten kann, da Teile vom Netz von anderen Firmen genutzt
werden.

Somit wurden die entsprechenden Server in ein Subnetz mit 8 Server
zusammengefasst.

Die interne Firewall routet das Subnetz nur zum Tunnel hin.
Auf der Externen Firewall wurde folgendes für den IPSec Tunnel S2S
konfiguriert.

Es wurde ein VPN _Remotestandort eingerichtet mit dem Zeil Netz und dessen
Subnetz.
Es wurde ein Netzwerkobjekt Subnetze in der Toolbox angelegt das mit der
Netzwerkadresse 172.16.195.0 /29 dies soll das Subnetz der 8 Server
Simulieren. Dieses Netz gibt es allerdings in dieser Form nicht, da es
eigentlich Bestandteil des Lan-netzes 172.16.195.0 /24 ist.

Nun wurde eine Netzwerkregel eingerichtet
Mit Routing zwischen den Netzen Sit-To-Site-Command und dem Simulierten
Netzwerkobjekt 172.16.195.0 /29

Es gibt nun auch noch 2 Firewallrichtlinen die die Protokolle RDP, Ping,
Telnet in dem Tunnel in beide Richtungen erlauben.

Nun verstehe ich nicht, wo die SrcMask 255.255.0.0 im IPSec Protokoll
herkommt.
Da das Subnetz als Netzwerkobjekt 172.16.195.0/29 eingerichtet wurde und in
den Netzwerkregeln hier auch so hinterlegt wurde.


Hat jemand einen Tipp für mich.
Wo die SrcMask herkommt und wie ich den Tunnel dahin bringe dass er im
Protokoll die richtige Subnetzmask übermittelt.
Ich vermute nàmlich das dies das Problem auch für die Verbindungsabbrüche im
Tunnel ist. Da hier der Quick-Modus jedes Mal neu verhandelt wird EreignisID
542 u. 541. Und falls unserer ISA-Server den Verbindungsaufbau einleitet
schlàgt dies Fehl und die Verbindung wird gekappt.

Gruß Markus
 

Lesen sie die antworten

#1 Christian Gröbner [MVP]
23/04/2008 - 14:56 | Warnen spam
Hallo Markus,

das könnte an vielen Einstellungen liegen.

Wenn der Tunnel zu frühzeitig abgebaut wird fàllt mir folgender KB-Artikel
ein:

http://support.microsoft.com/kb/917025/en-us

Das im Oakley-Log die Subnetzmaske 255.255.0.0 auftaucht würde ich vorerst
mal nicht als die Ursache des Problems betrachten.

Vielleicht ist folgendes Tool hilfreich bei der Fehlersuche:

http://blogs.technet.com/steriley/a...-tool.aspx

Gruß

Christian

Christian Gröbner
MVP Forefront
Hilfe & Infos rund um den ISA Server: http://www.msisafaq.de !!!!

NEU !!! Das Handbuch zum ISA 2006 - http://www.msisafaq.de/buch/

"Markus Dotzel" schrieb im
Newsbeitrag news:
Hallo,
vielleicht kann mir jemand einen Tipp geben.

Vorsicht jetzt wird es ein wenig umfangreich um mein Problem zu
beschreiben.
Hoffentlich hat jemand lust diese Menge an Text zu lesen.


Habe eine S2S-VPN-Verbindung (Ipsec) mit einer Support-Firma aufgebaut.
Zwischen einem ISA2004 (meine FW) und einer Fortinet (Support Firma).

Folgendes Problem tritt allerdings hierbei auf. Der VPN-Tunnel làsst sich
nur von der Gegenstelle aus aufbauen. Hin und wieder bricht der Tunnel ab
und
eine neue Verbindung làsst sich nicht mehr aufbauen. Hier kommt es
allerdings
darauf an von welcher Seite als erstes nach dem Verbindungsabbruch der
Neuaufbau der Verbindung stattfindet. Von der Gegenstelle klappt es immer,
wenn nicht von meiner Seite aus vorher versucht wurde die Verbindung
aufzubauen. Falls dies der Fall ist, kann die Verbindung weder von mir
noch
von der Gegenstelle mehr aufgebaut werden. Erst nachdem die Zeit für die
Phase 2 abgelaufen ist.

Probleme gibt es allerdings immer auch nur bei dem Aufbau der Phase 2 die
Phase 1 ist immer erfolgreich.

Nach einiger Recherche habe ich einen möglichen Grund für dieses Problem
gefunden.
Beim Versuch die Verbindung von meiner Seite aufzubauen. Wird folgendes im
IPSec-Protokoll protokolliert.

4-22: 13:36:54:156:544 Acquire from driver: op000006 src2.16.195.3.0
dst.10.125.250.0 proto = 0, SrcMask%5.255.0.0, DstMask%5.255.255.0,
Tunnel 1, TunnelEndpt!7.6.108.182 Inbound TunnelEndpt‚.212.250.2
4-22: 13:36:54:296:1cc Filter to match: Src 217.6.108.182 Dst 82.212.250.2
4-22: 13:36:54:296:1cc MM PolicyName: ISA Server Site-To-Site-Command MM
Policy
.
4-22: 13:36:54:640:1cc Starting Negotiation: src = 82.212.250.2.0500, dst
> 217.6.108.182.0500, proto = 00, context = 00000006, ProxySrc > 172.16.0.0.0000, ProxyDst = 10.10.125.0.0000 SrcMask = 255.255.0.0 DstMask
> 255.255.255.0

Hier steht bei SrcMask%5.255.0.0
Diese SubnestMaske ist allerdings nicht korrekt. Sie müsste eigentlich
255.255.255.248 lauten.

In den Firewallrichtlinien vom ISA2004 ist diese Quelle immer mit der
SubnetMask /29 angegeben. In den Netzwerkregeln wurde auch diese
SubnetMask
verwendet.

Hier ein paar Infos zur Konfiguration.

LAN Remote <-> Remote Gateway <-> www <-> ISA2004 <-> DMZ <-> ISA2004 <->
LAN <-> Subnetz 172.16.195.3.0 /29

Das Subnetz 172.16.195.3.0 /29 ist ein künstlich erzeugtes Subnetz im
Subnetz 172.16.0.0 /24 da die Gegenstelle (Supportfirma) nicht unser
ganzes
LAN-Netz freischalten kann, da Teile vom Netz von anderen Firmen genutzt
werden.

Somit wurden die entsprechenden Server in ein Subnetz mit 8 Server
zusammengefasst.

Die interne Firewall routet das Subnetz nur zum Tunnel hin.
Auf der Externen Firewall wurde folgendes für den IPSec Tunnel S2S
konfiguriert.

Es wurde ein VPN _Remotestandort eingerichtet mit dem Zeil Netz und dessen
Subnetz.
Es wurde ein Netzwerkobjekt Subnetze in der Toolbox angelegt das mit der
Netzwerkadresse 172.16.195.0 /29 dies soll das Subnetz der 8 Server
Simulieren. Dieses Netz gibt es allerdings in dieser Form nicht, da es
eigentlich Bestandteil des Lan-netzes 172.16.195.0 /24 ist.

Nun wurde eine Netzwerkregel eingerichtet
Mit Routing zwischen den Netzen Sit-To-Site-Command und dem Simulierten
Netzwerkobjekt 172.16.195.0 /29

Es gibt nun auch noch 2 Firewallrichtlinen die die Protokolle RDP, Ping,
Telnet in dem Tunnel in beide Richtungen erlauben.

Nun verstehe ich nicht, wo die SrcMask 255.255.0.0 im IPSec Protokoll
herkommt.
Da das Subnetz als Netzwerkobjekt 172.16.195.0/29 eingerichtet wurde und
in
den Netzwerkregeln hier auch so hinterlegt wurde.


Hat jemand einen Tipp für mich.
Wo die SrcMask herkommt und wie ich den Tunnel dahin bringe dass er im
Protokoll die richtige Subnetzmask übermittelt.
Ich vermute nàmlich das dies das Problem auch für die Verbindungsabbrüche
im
Tunnel ist. Da hier der Quick-Modus jedes Mal neu verhandelt wird
EreignisID
542 u. 541. Und falls unserer ISA-Server den Verbindungsaufbau einleitet
schlàgt dies Fehl und die Verbindung wird gekappt.

Gruß Markus

Ähnliche fragen