Probleme mit Cisco 876 in Phase 2

[Whistleblower 45]

Hallo zusammen,

 

versuche gerade ein VPN zwischen einem Cisco 876 und einem anderen Hersteller einzurichten.

Problem (meines Erachtens) dabei:

Es wird keine Lan-2-Lan Verbindung aufgebaut, sondern nur Host-2-Host (bzw. quasi eine Matrix mit 5 Hosts auf der einen Seite und 5 auf der anderen).

 

Beim Debug bekomme ich folgende Fehler:

 

004110: Oct 24 16:01:33.212 PCTime: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
004111: Oct 24 16:02:12.300 PCTime: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
004112: Oct 24 16:02:29.128 PCTime: crypto_engine: Create DH shared secret
004113: Oct 24 16:02:29.128 PCTime: crypto_engine: Modular Exponentiation
004114: Oct 24 16:02:29.136 PCTime: crypto_engine: Create IKE SA
004115: Oct 24 16:02:29.136 PCTime: crypto engine: deleting DH phase 2 SW:53
004116: Oct 24 16:02:29.136 PCTime: crypto_engine: Delete DH shared secret
004117: Oct 24 16:02:29.236 PCTime: crypto_engine: Decrypt IKE packet
004118: Oct 24 16:02:29.236 PCTime: ISAKMP:(2107):Unable to copy name into saved_grpname

 

Laut Cisco sollte der Fehler in den ACLs zu suchen sein (nicht auf beiden Seiten identisch).

 

Meine Frage ist jetzt erstmal, ob Cisco diese Konfiguration überhaupt unterstützt?

Weiss da jemand genaueres zu?

[Ciscler 10]

Hallo,

 

klar warum sollte Cisco das nicht unterstützen. Habe auch schon viele IPsec Verbindungen zu anderen Routern wo nicht Cisco drauf steht konfiguriert.

Was hängt denn auf der Gegenseite?

[Whistleblower 45]

Hi,

 

Gegenseite steht eine Checkpoint - hab aber leider keinerlei Zugriff darauf, und kann daher auch nicht überprüfen, ob da die Proposals stimmen...

Gabs bei Cisco nicht auch nen Befehl, um zu erkennen, mit welchen proposals die Gegenseite reinkommt?

Hab auch schon VPNs zu non-Ciscos gebaut, aber es waren immer Lan-2-Lan VPNs...

 

Hier ist das Schema ja ungefähr so:

 

permit host 192.168.123.1 host 172.16.1.1

permit host 192.168.123.1 host 172.16.1.2

permit host 192.168.123.1 host 172.16.1.3

 

permit host 192.168.123.2 host 172.16.1.1

permit host 192.168.123.2 host 172.16.1.2

permit host 192.168.123.2 host 172.16.1.3

 

permit host 192.168.123.2 host 172.16.1.1

permit host 192.168.123.2 host 172.16.1.2

permit host 192.168.123.2 host 172.16.1.3

 

nur mit jeweils 5 Hosts pro Seite...

[Wordo 11]

Bei Checkpoint ist es wichtig zu wissen auf welches Interface die IPSec Lizenz registriert ist. Klingt komisch, is aber so :D Musste mal mit ner Linux zu Checkpoint ein VPN machen und die Leute haben die Lizenz auf das interne Interface registriert. Zwang mich dazu, sowohl fuer externe, als auch fuer interne IP einen PSK anzulegen.

 

Debug einfach alles was bei crypto geht und setz nen Ping ab, da stehen die Netze dann schon drin.

[Whistleblower 45]

Bei Checkpoint ist es wichtig zu wissen auf welches Interface die IPSec Lizenz registriert ist. Klingt komisch, is aber so :D Musste mal mit ner Linux zu Checkpoint ein VPN machen und die Leute haben die Lizenz auf das interne Interface registriert. Zwang mich dazu, sowohl fuer externe, als auch fuer interne IP einen PSK anzulegen.

 

Hm, aber sollten dann nicht die Probleme schon an anderer Stelle auftreten?

 

Ich habe gestern noch mal ein paar Sachen getestet, und mir noch mal die IPSec SA's angeschaut. Demnach legt der Cisco ganz korrekt für jede Host-zu-Host Verbindung einen Eintrag an.

Ich sehe auch, dass da Pakete durchgingen, allerdings nur Encaps und Encrypted:

 

local  ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/0/0)
  remote ident (addr/mask/prot/port): (192.168.123.1/255.255.255.255/0/0)
  current_peer x.x.x.x port 500
    PERMIT, flags={origin_is_acl,}
   #pkts encaps: 261, #pkts encrypt: 261, #pkts digest: 261
   #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
   #pkts compressed: 0, #pkts decompressed: 0
   #pkts not compressed: 0, #pkts compr. failed: 0
   #pkts not decompressed: 0, #pkts decompress failed: 0
   #send errors 1, #recv errors 3

    local crypto endpt.: y.y.y.y, remote crypto endpt.: x.x.x.x
    path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet4
    current outbound spi: 0x0(0)

 

Habe dann noch einmal von einer anderen IP getestet und dann folgende Fehler gesehen:

 

008188: Oct 25 16:37:21.248 PCTime: 
IPSEC(crypto_ipsec_process_proposal): transform proposal not supported for identity:
   {esp-aes 256 esp-md5-hmac comp-lzs }
008189: Oct 25 16:37:21.248 PCTime: ISAKMP:(2009): IPSec policy invalidated proposal with error 256
008190: Oct 25 16:37:21.248 PCTime: 
IPSEC(crypto_ipsec_process_proposal): transform proposal not supported for identity:
   {esp-aes 256 esp-sha-hmac comp-lzs }
008191: Oct 25 16:37:21.248 PCTime: ISAKMP:(2009): IPSec policy invalidated proposal with error 256
008192: Oct 25 16:37:21.248 PCTime: 
IPSEC(crypto_ipsec_process_proposal): transform proposal not supported for identity:
   {esp-aes esp-md5-hmac comp-lzs }
008193: Oct 25 16:37:21.248 PCTime: ISAKMP:(2009): IPSec policy invalidated proposal with error 256
008194: Oct 25 16:37:21.248 PCTime: 
IPSEC(crypto_ipsec_process_proposal): transform proposal not supported for identity:
   {esp-aes esp-sha-hmac comp-lzs }
008195: Oct 25 16:37:21.248 PCTime: ISAKMP:(2009): IPSec policy invalidated proposal with error 256

... usw ...

 

Demnach haperts da irgendwo ganz deutlich noch an den Proposals, aber warum nur von der einen IP?

[tom12 10]

Hi,

 

wir hatten verschiedene VPNs zwischen Checkpoint un Cisco. Ohne Probleme.

 

Leider kenne ich Checkpoint zu wenig.

 

Kann es vielleicht nur am PFS liegen? Versuche PFS auf beiden Seiten abzuschelten.

 

Grüsse,

THomas

[Whistleblower 45]

Hi,

 

konnte mich zwischenzeitlich wieder mit dem Thema befassen.

PFS ist jetzt auf beiden Seiten abgeschaltet.

Ausserdem haben wir uns jetzt auf einen Tunnel beschränkt, also in der Art

"permit ip host 172.16.1.1 host 192.168.123.1"

 

Hat leider keine Verbesserung gebracht, bekomme immer noch die Meldung

000539: Oct 31 09:27:36.269 PCTime: IPSEC(epa_des_crypt): decrypted packet failed SA identity check

 

Das heisst doch eigentlich, das Pakete über den Tunnel gehen, aber nicht korrekt entschlüsselt werden können... Kann dann doch eigentlich nur noch eine Kleinigkeit sein...

Any ideas?

[Wordo 11]

Wieso steht denn da "des"?

[Whistleblower 45]

Wieso steht denn da "des"?

 

Habe ich auch erst überlegt.

So wie ich das sehe, steht das "des" da für "decrypt sa" oder ähnliches, nicht für den verwendeten Algorithmus, der richtigerweise 3DES lauten sollte...

Zumindest gibt es bei Cisco auch nur diese Fehlermeldung "IPSEC(epa_des_crypt)" und keine mit 3DES.

[Wordo 11]

Jetzt wo ichs grad seh:

 

local ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/0/0)

remote ident (addr/mask/prot/port): (192.168.123.1/255.255.255.255/0/0)

 

 

Ist da NAT irgendwo dazwischen?

[Whistleblower 45]

Hi Wordo,

 

klar, NAT ist aktiv, aber auch mit entsprechender ACL.

Das Problem hat sich aber mittlerweile gelöst - Auf der anderen Seite war noch eine ACL auf dem CoreSwitch, die unsere Zugriffe geblockt hat...

Jetzt funzt es soweit, konnte auch wieder die "Host-Matrix-ACL" in Betrieb nehmen...

PFS werde ich dann auch nochmal testen und nach Möglichkeit wieder aktivieren.

 

Trotzdem Danke für die Tipps!! :-)

[Wordo 11]

Wie sieht denn so eine ACL aus wenn es erst bei Phase II scheitert?