09-14-2007 08:23 AM - edited 03-11-2019 04:11 AM
though making sure all phase 1 and phase 2 configs are same on both the sides, i am seeing these errors on my ASA running 7.0(7) version and tunnel not coming up.
%ASA-5-713904: Group = <remote-ip>, IP = <remote-ip>, All IPSec SA proposals found unacceptable!
%ASA-3-713902: Group = <remote-ip>, IP = <remote-ip>, QM FSM error (P2 struct &0x35b2cb8, mess id 0xe4437b61)!
%ASA-3-713902: Group = <remote-ip>, IP = <remote-ip>, Removing peer from correlator table failed, no match!
%ASA-4-113019: Group = <remote-ip>, Username = <remote-ip>, IP = <remote-ip>, Session disconnected. Session Type: IPSecLAN2LAN, Duration: 0h:03m:22s, Bytes xmt: 0, Bytes rcv: 0, Reason: Phase 2 Mismatch
%ASA-5-713904: IP = <remote-ip>, Received encrypted packet with no matching SA, dropping
%ASA-4-713903: Group = <remote-ip>, IP = <remote-ip>, Freeing previously allocated memory for authorization-dn-attributes
%ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = <remote-ip>
%ASA-3-713119: Group = <remote-ip>, IP = <remote-ip>, PHASE 1 COMPLETED
any luck even debug says config are same both the sides.
Sep 12 05:17:24 [IKEv1]: IP = <remote-ip>, IKE_DECODE RECEIVED Message (msgid=35f3232c) with payloads : HDR + HASH (8) + SA (1) + NONCE (10) + KE (4) + ID (5) + ID (5) + NONE (0) total length : 396
Sep 12 05:17:24 [IKEv1 DEBUG]: Group = <remote-ip>, IP = <remote-ip>, processing hash payload
Sep 12 05:17:24 [IKEv1 DEBUG]: Group = <remote-ip>, IP = <remote-ip>, processing SA payload
Sep 12 05:17:24 [IKEv1 DEBUG]: Group = <remote-ip>, IP = <remote-ip>, processing nonce payload
Sep 12 05:17:24 [IKEv1 DEBUG]: Group = <remote-ip>, IP = <remote-ip>, processing ke payload
Sep 12 05:17:24 [IKEv1 DEBUG]: Group = <remote-ip>, IP = <remote-ip>, processing ISA_KE for PFS in phase 2
Sep 12 05:17:24 [IKEv1 DEBUG]: Group = <remote-ip>, IP = <remote-ip>, processing ID payload
Sep 12 05:17:24 [IKEv1 DECODE]: Group = <remote-ip>, IP = <remote-ip>, ID_IPV4_ADDR_SUBNET ID received--<remote-net>--255.255.255.0
Sep 12 05:17:24 [IKEv1]: Group = <remote-ip>, IP = <remote-ip>, Received remote IP Proxy Subnet data in ID Payload: Address <remote-net>, Mask 255.255.255.0, Protocol 0, Port 0
Sep 12 05:17:24 [IKEv1 DEBUG]: Group = <remote-ip>, IP = <remote-ip>, processing ID payload
Sep 12 05:17:24 [IKEv1 DECODE]: Group = <remote-ip>, IP = <remote-ip>, ID_IPV4_ADDR_SUBNET ID received--<local-net>--255.255.255.240
Sep 12 05:17:24 [IKEv1]: Group = <remote-ip>, IP = <remote-ip>, Received local IP Proxy Subnet data in ID Payload: Address <local-net>, Mask 255.255.255.240, Protocol 0, Port 0
Sep 12 05:17:24 [IKEv1]: Group = <remote-ip>, IP = <remote-ip>, QM IsRekeyed old sa not found by addr
Sep 12 05:17:24 [IKEv1]: Group = <remote-ip>, IP = <remote-ip>, Static Crypto Map check, checking map = mymap, seq = 1...
Sep 12 05:17:24 [IKEv1]: Group = <remote-ip>, IP = <remote-ip>, Static Crypto Map check, map mymap, seq = 1 is a successful match
Sep 12 05:17:24 [IKEv1]: Group = <remote-ip>, IP = <remote-ip>, IKE Remote Peer configured for crypto map: mymap
Sep 12 05:17:24 [IKEv1 DEBUG]: Group = <remote-ip>, IP = <remote-ip>, processing IPSec SA payload
Sep 12 05:17:24 [IKEv1]: Group = <remote-ip>, IP = <remote-ip>, All IPSec SA proposals found unacceptable!
Sep 12 05:17:24 [IKEv1 DEBUG]: Group = <remote-ip>, IP = <remote-ip>, sending notify message
Sep 12 05:17:24 [IKEv1 DEBUG]: Group = <remote-ip>, IP = <remote-ip>, constructing blank hash payload
Sep 12 05:17:24 [IKEv1 DEBUG]: Group = <remote-ip>, IP = <remote-ip>, constructing ipsec notify payload for msg id 35f3232c
Sep 12 05:17:24 [IKEv1 DEBUG]: Group = <remote-ip>, IP = <remote-ip>, constructing qm hash payload
Sep 12 05:17:24 [IKEv1]: IP = <remote-ip>, IKE_DECODE SENDING Message (msgid=88df93be) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 80
09-14-2007 11:07 AM
Guarang,
My first thoughts are get off 7.02 and upgrade to 7.22, its way more stable and functional.
My second thoughts are surrounding this particular error message from youor post:
%ASA-5-713904: Group =
This tells me that the configurations and settings that define the vpn tunnel do *not* match. Your ASA is telling you that without them matching on both ends that ISAKMP cannot complete its negoiations and thus bring the tunnel up.
Verify both sides are the same throughout all the crypto settings.
10-17-2007 10:58 AM
Don't know if you found an answer, I am having a similar issue with an ASA to Fortigate, appears the fortigate is doing something odd with the netmasks on the ACL, search in the tac case collection for K13430516 and you will see it, I don't have a fix for this yet..
12-23-2007 12:14 PM
Whisperwind,
Where did base the information that 7.22 is
way more stable and function thatn 7.02?
I can tell you 7.22 is not stable and it
is full of bugs.
12-23-2007 08:52 AM
You need to use the 'Quick Mode Selector' within the Phase2 Advanced on the Fortinet to match up with the Crypto Map traffic selection on the ASA.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide