IPSEC VPN von MS ISA 2004 zu LANCOM 1611+

[s.nehrbauer]

Hallo zusammen,

seit ca. vier Tagen durchforste ich nun schon alle mir bekannten Suchmaschinen und Foren, auf der Suche nach der Ursache für mein Problem.

Folgendes Vorhaben:
Außenstelle mit S-DSL2000 (feste IP) soll über einen LANCOM 1611+ eine Verbindung ins Internet aufbauen. Über eine IPSEC VPN Verbindung soll dann eine Verbindung zu einem MS ISA 2004 hergestellt werden, um mit den Maschinen in der Zentrale zu kommunizieren.

Struktur:


Bisher erfolgreich/erkannt:
- Verbindung ins Internet
- Abgleich der Proposals für IKE (Phase1) und IPSEC (Phase2)
- Ping vom Lancom zum ext. Interface des ISA 2004
- Im "Trace + vpn-status" sehe ich abgehende und ankommende VPN Verbindungen (die leider nicht zustande kommen)
- ISA kann nur "MAIN MODE" (darum helfen mir die Anleitungen von Lancom nicht sehr viel, da die alle auf Aggressive Mode hinauslaufen)
- keine Unterschiede beim Einsatz von 3DES oder DES bzw. SHA-1 und MD5
- keine Unterschiede mit/ohne PFS
-

Problem:
- Eine VPN Verbindung von ISA zum Lancom scheitert an der Phase-2 mit folgender Meldung im Trace:

[VPN-Status] 2007/01/23 18:37:49,370
IKE info: Phase-2 failed for peer ISA5: no rule matches the phase-2 ids <ext-ISA> <-> 10.0.0.254
IKE log: 183749 Default message_negotiate_sa: no compatible proposal found
IKE log: 183749 Default dropped message from <ext-ISA> port 500 due to notification type NO_PROPOSAL_CHOSEN
IKE info: dropped message from peer ISA5 <ext-ISA> port 500 due to notification type NO_PROPOSAL_CHOSEN


[VPN-Status] 2007/01/23 18:37:49,380
VPN: Error: IPSEC-R-No-rule-matched-IDs (0x3201) for ISA5 (<ext-ISA>)

[VPN-Status] 2007/01/23 18:37:49,380
VPN: selecting next remote gateway using strategy eFirst for ISA5
=> no remote gateway selected


Ich frage mich, warum der Lancom versucht, "<ext-ISA> <-> 10.0.0.254" eine Regel zu finden.
Die Phase-1 verläuft übrigens problemlos.

Kann es sein, dass es zwingend nötig ist, dass der ISA den LANCOM per ICMP erreichen muss, bevor eine VPN Verbindung überhaupt möglich ist? ICMP vom ISA ins wilde Internet verbietet die zweite Firewall.

Fragen über Fragen und sicher noch nicht genug Infos für eine Lösung.
Ich weiß aber nicht mehr weiter und hoffe auf Hilfe!

[backslash]

Hi s.nehrbauer

IKE info: Phase-2 failed for peer ISA5: no rule matches the phase-2 ids <ext-ISA> <-> 10.0.0.254

Du hast im ISA offenbar den Transport-Mode eingestellt, denn sonst würde da nicht die externe Adresse des ISA und nur die interne Adresse 1611+auftauchen.

Du mußt den ISA schon so konfigurieren, daß er die beiden Netze im Tunnel-Mode verbindet...


Gruß
Backslash

[s.nehrbauer]

Leider gibt es am ISA keine Option, um Transport- oder Tunneling-Modus auszuwählen.

Mein Problem war viel einfacher zu lösen: Ich habe versucht vom ISA Server das entfernte Netz anzupingen. Dabei wurde natürlich die ext. IP des ISA Servers verwendet und keine aus dem lokalen Netz. Nachdem ich von einer Station hinter dem ISA (im lok. Netz) ins entfernte Netz gepingt habe, wurde der Tunnel auch aufgebaut

Leider ergibt sich jetzt ein neues Problem: In die entgegengesetzte Richtung funktioniert es nicht, also der Tunnel wird nicht aufgebaut. Leider bekomme ich am ISA kein so schönes Tracewerkzeug an die Hand, wie beim LANCOM. Dafür gibt es auch nur ganz wenige Optionen, die man überhaupt einstellen kann.

Sobald ich jetzt aus dem entfernten Netz in mein lokales Netz pingen will (ohne aktiven VPN Tunnel), bekomme ich folgendes im Trace:

Code: Alles auswählen

root@:/
> 
[VPN-Status] 2007/01/24 14:50:28,650
VPN: connecting to ISA5 (<ext.-ISA>)

[VPN-Status] 2007/01/24 14:50:28,650
VPN: start dynamic VPN negotiation for ISA5 (<ext.-ISA>) via ICMP/UDP

[VPN-Status] 2007/01/24 14:50:28,660
VPN: create dynamic VPN V2 authentication packet for ISA5 (<ext.-ISA>)
     DNS: 192.168.155.254, 0.0.0.0
     NBNS: 192.168.155.254, 0.0.0.0
     polling address: 192.168.155.254

[VPN-Status] 2007/01/24 14:50:28,660
VPN: installing ruleset for ISA5 (<ext.-ISA>)

[VPN-Status] 2007/01/24 14:50:28,680
VPN: ruleset installed for ISA5 (<ext.-ISA>)

[VPN-Status] 2007/01/24 14:50:28,680
VPN: start IKE negotiation for ISA5 (<ext.-ISA>)

[VPN-Status] 2007/01/24 14:50:28,700
VPN: rulesets installed

[VPN-Status] 2007/01/24 14:50:28,700
IKE info: Phase-1 negotiation started for peer ISA5 rule isakmp-peer-ISA5 using MAIN mode


[VPN-Status] 2007/01/24 14:50:28,780
IKE info: The remote server <ext.-ISA>:500 peer ISA5 id <no_id> supports NAT-T in mode draft


[VPN-Status] 2007/01/24 14:50:28,780
IKE info: Phase-1 remote proposal 1 for peer ISA5 matched with local proposal 1


[VPN-Status] 2007/01/24 14:50:29,110
IKE info: Phase-1 [inititiator] for peer ISA5 between initiator id  <ext.-LANCOM>, responder id  <ext.-ISA> done
IKE info: SA ISAKMP for peer ISA5 encryption 3des-cbc authentication sha1
IKE info: life time ( 28800 sec/ 0 kb)


[VPN-Status] 2007/01/24 14:50:29,220
IKE info: NOTIFY received of type INVALID_ID_INFORMATION for peer ISA5


[VPN-Status] 2007/01/24 14:50:38,660
VPN: fallback to dynamic VPN V1 for ISA5 (<ext.-ISA>)

[VPN-Status] 2007/01/24 14:50:38,660
VPN: create dynamic VPN V1 authentication packet for ISA5 (<ext.-ISA>)
     DNS: 192.168.155.254, 0.0.0.0
     NBNS: 192.168.155.254, 0.0.0.0

Kann dazu jemand einen Tipp geben? Phase 1 scheint wieder erfolgreich abzulaufen.

Ping von und zu den externen Adressen des LANCOMs und des ISAs funktionieren mittlerweile auch problemlos.

[backslash]

Hi s.nehrbauer

Code: Alles auswählen

[VPN-Status] 2007/01/24 14:50:28,650 
VPN: start dynamic VPN negotiation for ISA5 (<ext.-ISA>) via ICMP/UDP 

[VPN-Status] 2007/01/24 14:50:28,660 
VPN: create dynamic VPN V2 authentication packet for ISA5 (<ext.-ISA>) 
     DNS: 192.168.155.254, 0.0.0.0 
     NBNS: 192.168.155.254, 0.0.0.0 
     polling address: 192.168.155.254 

der ISA versteht garantiert kein dynamic VPN... Schalte es ab (VPN -> Allgemein -> Verbindungs-Liste -> Verbindung -> Dynamische VPN-Verbindungen auf "Kein dynamisches VPN" stellen)

Code: Alles auswählen

VPN-Status] 2007/01/24 14:50:29,220 
IKE info: NOTIFY received of type INVALID_ID_INFORMATION for peer ISA5 

da stimmt die lokale ID, mit der sich das LANCOM meldet nicht mit der ein, die der ISA erwartet. Das kannst du unter VPN -> IKE-Auth. -> IKE-Schlüssen und Identitäten einstellen. Am sinnvollsten trägt man da einen passenden FQUN (EMail-Adresse) auf beiden Seiten gleich ein...

Gruß
Backslash

[s.nehrbauer]

Der Lancom steht schon auf "kein dynamisches VPN". Warum er es trotzdem versucht, verstehe ich auch nicht. Es gibt außer der fraglichen Verbindung auch keine weitere.

Soweit ich weiß, kann man am ISA Server nirgendwo eine Identität einstellen. Ich bin daher auf IP-Adressen gegangen, weil ich z. b. mit FQUN eine Fehlermeldung bekomme, die so aussieht (IP-Adresse und Mailadressen geändert):

Code: Alles auswählen

[VPN-Status] 2007/01/24 16:21:40,340
IKE info: Phase-1 negotiation started for peer ISA5 rule isakmp-peer-ISA5 using MAIN mode


[VPN-Status] 2007/01/24 16:21:40,400
IKE info: The remote server <ext.-ISA>:500 peer ISA5 id <no_id> supports NAT-T in mode draft


[VPN-Status] 2007/01/24 16:21:40,400
IKE info: Phase-1 remote proposal 1 for peer ISA5 matched with local proposal 1


[VPN-Status] 2007/01/24 16:21:40,730
IKE info: Phase-1 failed for peer ISA5: received ID IPV4_ADDR: <ext.-ISA> != expected ID USER_FQDN:hans@dampf.de


[VPN-Status] 2007/01/24 16:21:40,730
VPN: Error: IKE-R-ID-type-mismatch (0x2208) for ISA5 (<ext.-ISA>)

[VPN-Status] 2007/01/24 16:21:41,680
IKE info: Phase-1 failed for peer ISA5: received ID IPV4_ADDR: <ext.-ISA> != expected ID USER_FQDN:hans@dampf.de


[VPN-Status] 2007/01/24 16:21:41,680
VPN: Error: IKE-R-ID-type-mismatch (0x2208) for ISA5 (<ext.-ISA>)

[VPN-Status] 2007/01/24 16:21:43,680
IKE info: Phase-1 failed for peer ISA5: received ID IPV4_ADDR: <ext.-ISA> != expected ID USER_FQDN:hans@dampf.de


[VPN-Status] 2007/01/24 16:21:43,680
VPN: Error: IKE-R-ID-type-mismatch (0x2208) for ISA5 (<ext.-ISA>)

[VPN-Status] 2007/01/24 16:21:47,680
IKE info: Phase-1 failed for peer ISA5: received ID IPV4_ADDR: <ext.-ISA> != expected ID USER_FQDN:hans@dampf.de


[VPN-Status] 2007/01/24 16:21:47,680
VPN: Error: IKE-R-ID-type-mismatch (0x2208) for ISA5 (<ext.-ISA>)

[VPN-Status] 2007/01/24 16:21:49,310
VPN: fallback to dynamic VPN V1 for ISA5 (<ext.-ISA>)

Das einzige, was für mich eindeutig erscheint, ist die IP-Adresse.

[backslash]

Hi s.nehrbauer

Der Lancom steht schon auf "kein dynamisches VPN". Warum er es trotzdem versucht, verstehe ich auch nicht. Es gibt außer der fraglichen Verbindung auch keine weitere.

Hast du zufällig den NetBIOS-Proxy auf der VPN-Strecke aktiviert? Der Fuunktioniert so richtig eh nur gegen ein LANCOM.

Soweit ich weiß, kann man am ISA Server nirgendwo eine Identität einstellen. Ich bin daher auf IP-Adressen gegangen, weil ich z. b. mit FQUN eine Fehlermeldung bekomme, die so aussieht (IP-Adresse und Mailadressen geändert):

Hat der 1611 eine dynamische IP-Adresse oder eine feste?
Was passiert, wenn du im 1611 als Typ für die lokale Identikät "keine Identität" einträgst?

Gruß
Backslash

[s.nehrbauer]

Hallo,

danke für die vielen Tipps erstmal!

Den NetBIOS Proxy habe ich jetzt abgestellt (NETBIOS -> NetBIOS über IP Routing aktivieren).

Beide Seiten haben eine feste IP-Adresse.

Nehme ich auf dem 1611 die Identität raus, ändert sich leider nichts.

Auf dem ISA habe ich jetzt doch eine Möglichkeit gefunden, mehr Infos über die IKE Vorgänge zu erhalten. Leider ist das für mich nur Kauderwelsch:

<ENTFERNT, da fehlerhaft>

Gruß

S. Nehrbauer

[backslash]

Hi s.nehrbauer

das hier dürfte der Fehler sein:

Code: Alles auswählen

 1-24: 16:38:51:16:1034 Negotiated Proxy ID: Src 192.168.155.0.0 Dst 172.16.0.0.0 
 1-24: 16:38:51:16:1034 Src id for subnet.  Mask 255.255.255.0 
 1-24: 16:38:51:16:1034 Dst id for subnet.  Mask 255.255.0.0 

Das LANCOM fordert eine Netzbeziehung 192.168.155.0/24 <-> 172.16.0.0/16. Das stimmt aber nicht mit deiner Zeichnung überein. Dort hat das LANCOM das Netz 10.0.0.0/24.

Wenn ich mit den vorhertigen Trace mit den dynamic VPN anschaue, dann ist das LANCOM felsenfest der Meinung im 192.168.155.0/24 Netz zu stehen. Was hast du als Intranet und was als DMZ konfiguriert?

Oder soll der ISA beide Netze erreiche? Dann mußt du es dem ISA auch sagen...

Gruß
Backslash

[s.nehrbauer]

Oha, ich muss mit "Suchen und ersetzen" besser aufpassen.
Ich habe den Trace vom letzten Post "überarbeitet" und damit verfälscht!

172.16.0.0/16 ist das lokale Netz hinter dem ISA.
10.0.0.0/24 ist das Netz hinter dem Lancom.

Hier nun der korrekte Post:

Code: Alles auswählen

 1-24: 16:38:39:250:1034 
 1-24: 16:38:39:250:1034 Receive: (get) SA = 0x022d9730 from <ext-LANCOM>.500
 1-24: 16:38:39:250:1034 ISAKMP Header: (V1.0), len = 460
 1-24: 16:38:39:250:1034   I-COOKIE 3c02f4a647786efe
 1-24: 16:38:39:250:1034   R-COOKIE b07b1e622cd9c719
 1-24: 16:38:39:250:1034   exchange: Oakley Quick Mode
 1-24: 16:38:39:250:1034   flags: 1 ( encrypted )
 1-24: 16:38:39:250:1034   next payload: HASH
 1-24: 16:38:39:250:1034   message ID: 7c2e5129
 1-24: 16:38:39:250:1034 Dropping Centry processing because SA status set.  SA 022D9730 Centry 000E9590 Status 3601
 1-24: 16:38:41:125:1034 
 1-24: 16:38:41:125:1034 Receive: (get) SA = 0x022d9730 from <ext-LANCOM>.500
 1-24: 16:38:41:125:1034 ISAKMP Header: (V1.0), len = 84
 1-24: 16:38:41:125:1034   I-COOKIE 3c02f4a647786efe
 1-24: 16:38:41:125:1034   R-COOKIE b07b1e622cd9c719
 1-24: 16:38:41:125:1034   exchange: ISAKMP Informational Exchange
 1-24: 16:38:41:125:1034   flags: 1 ( encrypted )
 1-24: 16:38:41:125:1034   next payload: HASH
 1-24: 16:38:41:125:1034   message ID: cde44210
 1-24: 16:38:41:125:1034 processing HASH (Notify/Delete)
 1-24: 16:38:41:125:1034 processing payload DELETE
 1-24: 16:38:41:125:1034 SA Dead. sa:022D9730 status:35ef
 1-24: 16:38:41:125:1034 isadb_set_status sa:022D9730 centry:00000000 status 35ef
 1-24: 16:38:50:578:1034 
 1-24: 16:38:50:578:1034 Receive: (get) SA = 0x00000000 from <ext-LANCOM>.500
 1-24: 16:38:50:578:1034 ISAKMP Header: (V1.0), len = 152
 1-24: 16:38:50:578:1034   I-COOKIE 132f12cfca37d638
 1-24: 16:38:50:578:1034   R-COOKIE 0000000000000000
 1-24: 16:38:50:578:1034   exchange: Oakley Main Mode
 1-24: 16:38:50:578:1034   flags: 0
 1-24: 16:38:50:578:1034   next payload: SA
 1-24: 16:38:50:578:1034   message ID: 00000000
 1-24: 16:38:50:578:1034 Filter to match: Src <ext-LANCOM> Dst <ext-ISA>
 1-24: 16:38:50:578:1034 MM PolicyName: ISA Server VPN_LANCOM_TEST MM Policy
 1-24: 16:38:50:578:1034 MMPolicy dwFlags 0 SoftSAExpireTime 28800
 1-24: 16:38:50:578:1034 MMOffer[0] LifetimeSec 28800 QMLimit 0 DHGroup 2
 1-24: 16:38:50:578:1034 MMOffer[0] Encrypt: Dreifach-DES CBC Hash: SHA
 1-24: 16:38:50:578:1034 Auth[0]:PresharedKey KeyLen 18
 1-24: 16:38:50:578:1034 Responding with new SA 22dbca8
 1-24: 16:38:50:578:1034 processing payload SA
 1-24: 16:38:50:578:1034 Received Phase 1 Transform 0
 1-24: 16:38:50:578:1034      Encryption Alg Dreifach-DES CBC(5)
 1-24: 16:38:50:578:1034      Hash Alg SHA(2)
 1-24: 16:38:50:578:1034      Auth Method Vorinstallierter Schl

[s.nehrbauer]

Hi,

hier noch die Ausgabe eines "show vpn long" vom LANCOM:

Code: Alles auswählen

> sh vpn long

VPN SPD and IKE configuration:

  # of connections = 1

  Connection #1                 10.0.0.0/255.255.255.0:0 <-> 172.16.0.0/255.255.0.0:0 any

    Name:                       SRVISABA01
    Unique Id:                  ipsec-0-SRVISABA01-pr0-l0-r0
    Flags:                      main-mode
    Local  Network:             IPV4_ADDR_SUBNET(any:0, 10.0.0.0/255.255.255.0)
    Local  Gateway:             IPV4_ADDR(any:0, <ext-LANCOM>)
    Remote Gateway:             IPV4_ADDR(any:0, <ext-ISA>)
    Remote Network:             IPV4_ADDR_SUBNET(any:0, 172.16.0.0/255.255.0.0)
    IKE Proposal List:          isakmp-WIZ-IKE-PRESH-KEY-gr2
      # of proposals = 1
      IKE Proposal #1:          prop-ISA-3DES-SHA-ike-gr2
        IKE Encryption:         3DES_CBC
        IKE Hash:               SHA
        Authentication:         PRE_SHARED
        IKE Group:              MODP_1024
        Lifetime (sec, hard):   28800,0:28800
        Lifetime (KB, hard):    ANY
    IKE Identities and Key:     
      Key:                      *
    IPSec Proposal List:        ipsec-IPS-SRVISABA01-gr2
      # of proposals = 1
      IPSec Proposal #1:        IPSEC_ESP 3DES HMAC_SHA
          Encapsulation Mode:   TUNNEL
          PFS Group:            MODP_1024
          Lifetime (sec, hard): 3600,0:3600
          Lifetime (KB, hard):  100000,0:100000

und sowas ähnliches vom ISA (frag mich keiner, warum der das Netz so zerstückelt):

Code: Alles auswählen

Lokaler Tunnelendpunkt: <ext-ISA>
Remotetunnelendpunkt: <ext-LANCOM>

Die Remotesitekonfiguration muss die lokale 
Standortunnel-Endpunkt-IP-Adresse enthalten, um HTTP-Proxy- 
oder NAT-Datenverkehr an den lokalen Standort zuzulassen.

IKE-Phase I-Parameter:
    Modus: Hauptmodus
    Verschlüsselung: 3DES
    Integrität: SHA1
    Diffie-Hellman-Gruppe: Gruppe 2 (1024 Bit)
    Authentifizierungsmethode: Vorinstallierter Schlüssel (blablabla)
    Sicherheitsassoziationsgültigkeitsdauer: 28800 Sekunden 

IKE-Phase II-Parameter:
    Modus: ESP-Tunnelmodus
    Verschlüsselung: 3DES
    Integrität: SHA1
    Perfect Forward Secrecy: EIN
    Diffie-Hellman-Gruppe: Gruppe 2 (1024 Bit)
    Zeit für die neue Schlüsselerstellung: EIN
    Sicherheitsassoziationsgültigkeitsdauer: 3600 Sekunden 
    KB für die neue Schlüsselerstellung: EIN
    Neue Schlüsselerstellung nach Sendung: 100000 KB

IP-Subnetze des Remotenetzwerks "VPN_LANCOM_TEST":
    Subnetz: 10.0.0.1/255.255.255.255
    Subnetz: 10.0.0.254/255.255.255.255
    Subnetz: 10.0.0.2/255.255.255.254
    Subnetz: 10.0.0.252/255.255.255.254
    Subnetz: 10.0.0.4/255.255.255.252
    Subnetz: 10.0.0.248/255.255.255.252
    Subnetz: 10.0.0.8/255.255.255.248
    Subnetz: 10.0.0.240/255.255.255.248
    Subnetz: 10.0.0.16/255.255.255.240
    Subnetz: 10.0.0.224/255.255.255.240
    Subnetz: 10.0.0.32/255.255.255.224
    Subnetz: 10.0.0.192/255.255.255.224
    Subnetz: 10.0.0.64/255.255.255.192
    Subnetz: 10.0.0.128/255.255.255.192

Soweit ich es erkennen kann, stimmen beide Seiten überein.

[backslash]

Hi s.nehrbauer

Soweit ich es erkennen kann, stimmen beide Seiten überein.

nein: die Netze stiimen nicht überein: der ISA lehnt den Broadcast (10.0.0.255) ab - das LANCOM aber fordert ihn (er ist Bestandteil des Netzes 10.0.0.0/24).

Warum das so zerstückelt ist, mußt du schon herausfinden - vermutlich weil genau der Broadcast nicht durch soll...

Entweder du bringst dem ISA bei, das ganze Netz zu akzeptieren, oder du mußt im LANCOM die Regelerzeugung auf manuell stellen und eine Passende Regel in der Firewall aufnehmen, die diese Subnetze enthält:

Code: Alles auswählen

Aktion: Übertragen

Quelle: 10.0.0.1/255.255.255.255 
        10.0.0.254/255.255.255.255 
        10.0.0.2/255.255.255.254 
        10.0.0.252/255.255.255.254 
        10.0.0.4/255.255.255.252 
        10.0.0.248/255.255.255.252 
        10.0.0.8/255.255.255.248 
        10.0.0.240/255.255.255.248 
        10.0.0.16/255.255.255.240 
        10.0.0.224/255.255.255.240 
        10.0.0.32/255.255.255.224 
        10.0.0.192/255.255.255.224 
        10.0.0.64/255.255.255.192 
        10.0.0.128/255.255.255.192 

Ziel:   172.16.0.0/255.255.0.0

An dieser Regel mußt du dann noch das Häkchen bei "Diese Regel wird zur Erzeugung von VPN-Regeln herangezogen" setzen.

Gruß
Backslash

[s.nehrbauer]

Das Netz 10.0.0.0/24 war "von 10.0.0.1 bis 10.0.0.254" eingetragen. Damit fehlten natürlich zwei Adressen u. a. die Broadcast. Wurde geändert und nun wird das Netz auch nicht mehr zerstückelt dargestellt.
Ändert aber leider nichts daran, dass der Verbindungsaufbau von Seiten Lancom 1611 nicht funktioniert. Von ISA zum Lancom funktionierts nach wie vor.

Gruß

S. Nehrbauer

[s.nehrbauer]

HALT, alles zurück! Es funktioniert jetzt von beiden Seiten!
Entweder hat der ISA mehr als lange gebraucht, um die Änderung an der Netzdefinition zu aktualisieren oder eine höhere Macht ... (backslash ?)

Wow, mir fallen grade mehrere Steine runter! Jetzt muss es nur noch so bleiben DANKE!