Cisco 876 VPN zu ASA- Probleme mit Phase 1

[bnice]

Hallo zusammen,

habe gerade mal ein kleines Problem mit einem L2L VPN von einem 876 zu einer ASA, jeweils beide mit fester öff. IP.

Laut dem Debug scheint Phase 1 erst erfolgreich zu klappen, die SAs werden dann aber kurze Zeit später doch wieder gelöscht:

167880: Oct  9 14:03:20.386 PCTime: ISAKMP:(2111):SA has been authenticated with x.x.x.x
167881: Oct  9 14:03:20.386 PCTime: ISAKMP: Trying to insert a peer y.y.y.y/x.x.x.x/500/,  and inserted successfully 833EC76C.
167882: Oct  9 14:03:20.386 PCTime: ISAKMP:(2111):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
167883: Oct  9 14:03:20.386 PCTime: ISAKMP:(2111):Old State = IKE_I_MM5  New State = IKE_I_MM6

und dann... :

167895: Oct  9 14:03:20.442 PCTime: ISAKMP (0:2111): received packet from x.x.x.x dport 500 sport 500 Global (I) QM_IDLE
167896: Oct  9 14:03:20.442 PCTime: ISAKMP: set new node 1982641305 to QM_IDLE
167897: Oct  9 14:03:20.442 PCTime: ISAKMP:(2111): processing HASH payload. message ID = 1982641305
167898: Oct  9 14:03:20.442 PCTime: ISAKMP:(2111): processing NOTIFY PROPOSAL_NOT_CHOSEN protocol 3
        spi 0, message ID = 1982641305, sa = 83548830
167899: Oct  9 14:03:20.442 PCTime: ISAKMP:(2111):deleting node 1982641305 error FALSE reason "Informational (in) state 1"
167900: Oct  9 14:03:20.442 PCTime: ISAKMP:(2111):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
167901: Oct  9 14:03:20.442 PCTime: ISAKMP:(2111):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

167902: Oct  9 14:03:20.446 PCTime: ISAKMP (0:2111): received packet from x.x.x.x dport 500 sport 500 Global (I) QM_IDLE
167903: Oct  9 14:03:20.446 PCTime: ISAKMP: set new node 1214460594 to QM_IDLE
167904: Oct  9 14:03:20.446 PCTime: ISAKMP:(2111): processing HASH payload. message ID = 1214460594
167905: Oct  9 14:03:20.446 PCTime: ISAKMP:(2111): processing DELETE payload. message ID = 1214460594
167906: Oct  9 14:03:20.446 PCTime: ISAKMP:(2111):peer does not do paranoid keepalives.

167907: Oct  9 14:03:20.446 PCTime: ISAKMP:(2111):deleting SA reason "No reason" state (I) QM_IDLE       (peer x.x.x.x)
167908: Oct  9 14:03:20.446 PCTime: ISAKMP:(2111):deleting node 1214460594 error FALSE reason "Informational (in) state 1"
167909: Oct  9 14:03:20.446 PCTime: ISAKMP: set new node -1893712350 to QM_IDLE
167910: Oct  9 14:03:20.446 PCTime: ISAKMP:(2111): sending packet to x.x.x.x my_port 500 peer_port 500 (I) QM_IDLE
167911: Oct  9 14:03:20.450 PCTime: ISAKMP:(2111):purging node -1893712350
167912: Oct  9 14:03:20.450 PCTime: ISAKMP:(2111):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
167913: Oct  9 14:03:20.450 PCTime: ISAKMP:(2111):Old State = IKE_P1_COMPLETE  New State = IKE_DEST_SA

Hab leider nur Config-Zugriff auf meine Seite (876, IP y.y.y.y)
Kann jemand genauer entschlüsseln, wo das Problem liegt?

Hab schon mehrere ISAKMP Policies angelegt, und er greift sich auch eine, die dann passt (3DES, DH2, SHA, Lifetime 3600). Der PSK wird auch akzeptiert...

[Wordo]

Du debuggst zu wenig, kann das sein? Sieht auf ner Cisco eigentlich bisschen anders aus. Wenn da QM_IDLE steht ist die 2te Phase eigentlich auch durch. Sieht eher nach DPD aus ...

[bnice]

Hi Wordo!

Habe ein "debug crypto isakmp" und ein "debug crypto ipsec" laufen...
Hatte ja auch schon diverse Meldungen gegoogelt, und einiges im Zusammenhang mit DPD gefunden - aber an welchen Stellen kann ich da jetzt für DPD was ändern?
Weiss leider auch nicht, ob die Gegenseite DPD fährt...
Muss ich morgen mal klären.

[Wordo]

Mach mal noch n "verbose" und "engine" rein, clear crypto sa und isakmp, dann debug aktivieren und n Ping absetzen.

[bnice]

Hi Wordo,

Kille ich mit einem "clear crypto sa" nicht auch die bestehenden Tunnel zu anderen Lokationen?
DPD hat die Gegenseite übrigens aktiviert, ich allerdings noch nicht, weil mir noch die Daten dazu fehlen (oder kann ich die irgendwo aus dem debug erahnen?)

Was mich ja auch wundert ist folgendes:
Am Anfang akzeptiert er die atts (die zweite Policy matcht):

409790: Oct 10 11:20:28.185 PCTime: ISAKMP:(0): processing SA payload. message ID = 0
409791: Oct 10 11:20:28.185 PCTime: ISAKMP:(0): processing vendor id payload
409792: Oct 10 11:20:28.185 PCTime: ISAKMP:(0): vendor ID seems Unity/DPD but major 194 mismatch
409793: Oct 10 11:20:28.185 PCTime: ISAKMP:(0):found peer pre-shared key matching x.x.x.x
409794: Oct 10 11:20:28.185 PCTime: ISAKMP:(0): local preshared key found
409795: Oct 10 11:20:28.185 PCTime: ISAKMP : Scanning profiles for xauth ...
409796: Oct 10 11:20:28.185 PCTime: ISAKMP:(0):Checking ISAKMP transform 2 against priority 1 policy
409797: Oct 10 11:20:28.185 PCTime: ISAKMP:      encryption 3DES-CBC
409798: Oct 10 11:20:28.185 PCTime: ISAKMP:      hash MD5
409799: Oct 10 11:20:28.185 PCTime: ISAKMP:      default group 2
409800: Oct 10 11:20:28.185 PCTime: ISAKMP:      auth pre-share
409801: Oct 10 11:20:28.185 PCTime: ISAKMP:      life type in seconds
409802: Oct 10 11:20:28.185 PCTime: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
409803: Oct 10 11:20:28.185 PCTime: ISAKMP:(0):Hash algorithm offered does not match policy!
409804: Oct 10 11:20:28.185 PCTime: ISAKMP:(0):atts are not acceptable. Next payload is 0
409805: Oct 10 11:20:28.185 PCTime: ISAKMP:(0):Checking ISAKMP transform 2 against priority 2 policy
409806: Oct 10 11:20:28.189 PCTime: ISAKMP:      encryption 3DES-CBC
409807: Oct 10 11:20:28.189 PCTime: ISAKMP:      hash MD5
409808: Oct 10 11:20:28.189 PCTime: ISAKMP:      default group 2
409809: Oct 10 11:20:28.189 PCTime: ISAKMP:      auth pre-share
409810: Oct 10 11:20:28.189 PCTime: ISAKMP:      life type in seconds
409811: Oct 10 11:20:28.189 PCTime: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
409812: Oct 10 11:20:28.189 PCTime: ISAKMP:(0):atts are acceptable. Next payload is 0
409813: Oct 10 11:20:28.189 PCTime: ISAKMP:(0): processing vendor id payload
409814: Oct 10 11:20:28.189 PCTime: ISAKMP:(0): vendor ID seems Unity/DPD but major 194 mismatch

aber später dann diese Meldung:

409844: Oct 10 11:20:28.401 PCTime: ISAKMP (0:2068): received packet from x.x.x.x dport 500 sport 500 Global (I) MM_KEY_EXCH
409845: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068): processing ID payload. message ID = 0
409846: Oct 10 11:20:28.404 PCTime: ISAKMP (0:2068): ID payload
        next-payload : 8
        type         : 1
        address      : x.x.x.x
        protocol     : 17
        port         : 500
        length       : 12
409847: Oct 10 11:20:28.404 PCTime: ISAKMP:(0):: peer matches *none* of the profiles
409848: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068): processing HASH payload. message ID = 0
409849: Oct 10 11:20:28.404 PCTime: ISAKMP:received payload type 17
409850: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068): processing vendor id payload
409851: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068): vendor ID is DPD
409852: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068):SA authentication status:
        authenticated
409853: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068):SA has been authenticated with x.x.x.x
409854: Oct 10 11:20:28.404 PCTime: ISAKMP: Trying to insert a peer y.y.y.y/x.x.x.x/500/,  and inserted successfully 8348C1FC.
409855: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
409856: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068):Old State = IKE_I_MM5  New State = IKE_I_MM6

Aber die Authentication lief demnach ja trotzdem erfolgreich durch...

[bnice]

So,

Tunnel steht jetzt soweit! :-)
Einstellungen für DPD und PFS waren noch nicht ganz sauber...
Allerdings gehen noch keine Pakete über den Tunnel - vermute mal, dass die ACLs der Gegenseite noch nicht mitspielen. Oder gibt es sonst noch Möglichkeiten, wo die Pakete hängen bleiben könnten?
Mache gerade von einem Client ein Dauerping zu einem Rechner im entfernten LAN.
Sehe auch, das die Pakete durch meine "noNAT"-ACL gehen und ebenso die ACL für den IPSec-Traffic durchlaufen. Allerdings kommen keine Pakete zurück, müsste ich sonst in meiner incoming ACL sehen...