11-19-2010 01:01 PM
I am having a problem that has recently cropped up that I have spent a couple hours trying to troubleshoot. The basis of the problem is a phase 2 mismatch. Here is the complete config on both sides of the tunnel. I have confirmed the pre-shared key is 100% correct. I am wondering if the problem has to do with perfect forward secrecy (PFS) as this is our only client that demanded PFS. I am about to have the client disable PFS for testing but I am sure they want to use it. Any suggestions as I believe the following config is correct.
Branch location 1 (using PIX 515E):
access-list outside_5_cryptomap remark ******************************
access-list outside_5_cryptomap extended permit tcp host yyy.yyy.yyy.yyy xxx.xxx.xxx.xxx 255.255.255.0 eq ftp-data
access-list outside_5_cryptomap extended permit tcp host yyy.yyy.yyy.yyy xxx.xxx.xxx.xxx 255.255.255.0 eq ftp
access-list outside_5_cryptomap extended permit tcp host yyy.yyy.yyy.yyy xxx.xxx.xxx.xxx 255.255.255.0 eq ssh
access-list outside_5_cryptomap extended permit tcp host yyy.yyy.yyy.yyy xxx.xxx.xxx.xxx 255.255.255.0 eq telnet
crypto map outside_map 5 match address outside_5_cryptomap
crypto map outside_map 5 set pfs
crypto map outside_map 5 set peer www.www.www.www
crypto map outside_map 5 set transform-set ESP-3DES-SHA
crypto map outside_map 5 set security-association lifetime seconds 28800
crypto map outside_map 5 set security-association lifetime kilobytes 4608000
tunnel-group www.www.www.www type ipsec-l2l
tunnel-group www.www.www.www ipsec-attributes
pre-shared-key *
Branch location 2 (using ASA 5510):
access-list acl_9999999 extended permit tcp xxx.xxx.xxx.xxx 255.255.255.0 host yyy.yyy.yyy.yyy eq ftp-data
access-list acl_9999999 extended permit tcp xxx.xxx.xxx.xxx 255.255.255.0 host yyy.yyy.yyy.yyy eq ftp
access-list acl_9999999 extended permit tcp xxx.xxx.xxx.xxx 255.255.255.0 host yyy.yyy.yyy.yyy eq ssh
access-list acl_9999999 extended permit tcp xxx.xxx.xxx.xxx 255.255.255.0 host yyy.yyy.yyy.yyy eq telnet
crypto map partner-map 27 match address acl_9999999
crypto map partner-map 27 set pfs
crypto map partner-map 27 set peer zzz.zzz.zzz.zzz
crypto map partner-map 27 set transform-set sha3des
crypto map partner-map 27 set security-association lifetime seconds 28800
crypto map partner-map 27 set security-association lifetime kilobytes 4608000
tunnel-group zzz.zzz.zzz.zzz type ipsec-l2l
tunnel-group zzz.zzz.zzz.zzz ipsec-attributes
pre-shared-key *
Errors in Branch 2 syslog:
2010-11-19 09:00:29 Local5.Warning Nov 19 2010 09:00:29: %ASA-4-713903: Group = zzz.zzz.zzz.zzz, IP = zzz.zzz.zzz.zzz, Freeing previously allocated memory for authorization-dn-attributes
2010-11-19 09:00:29 Local5.Error Nov 19 2010 09:00:29: %ASA-3-713902: Group = zzz.zzz.zzz.zzz, IP = zzz.zzz.zzz.zzz, QM FSM error (P2 struct &0xaa71e1d8, mess id 0xd16b4052)!
2010-11-19 09:00:29 Local5.Error Nov 19 2010 09:00:29: %ASA-3-713902: Group = zzz.zzz.zzz.zzz, IP = zzz.zzz.zzz.zzz, Removing peer from correlator table failed, no match!
2010-11-19 09:00:29 Local5.Warning Nov 19 2010 09:00:29: %ASA-4-113019: Group = zzz.zzz.zzz.zzz, Username = zzz.zzz.zzz.zzz, IP = zzz.zzz.zzz.zzz, Session disconnected. Session Type: IKE, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Phase 2 Mismatch
11-19-2010 01:16 PM
Hi,
I don't think PFS is the problem because it matches on both ends.
Do you have to specify the crypto ACL with ports? The recommendation is to have the VPN ACL defined as IP.
In order to fix the problem, the transform-sets applied use 3DES and SHA on both ends correct?
The ''sh cry isa sa'' shows phase 1 established and as a site-to-site tunnel correct? (not as a remote-access connection).
Anyway... I would start by veryfing the transform-sets and disable PFS to test (it won't hurt).
Federico.
11-19-2010 01:39 PM
Yes, both sides are using SHA/3DES based on the following lines of config:
crypto map outside_map 5 set transform-set ESP-3DES-SHA
crypto map partner-map 27 set transform-set sha3des
As for port numbers on the ACL's, yes, I believe we want to limit the types of traffic coming across the tunnel to FTP, TELNET, and SSH. Now that you mention that, however, I vaguely recall reading somewhere that they don't recommend specifying port numbers on ACL's applied to a VPN tunnel. Can anyone confirm whether this is acceptable practice?
I can see if the other branch will disable PFS momentarily to test, but I want to say that the network admin prior to me stated that he has had several issues with PFS in the past. However, this client demanded that we use it for their data.
Mike
11-19-2010 01:47 PM
Mike,
The recommendation is to specify IP in the crypto ACL (no ports) because IPsec should be defined for IP traffic (no TCP/UDP).
The commands:
crypto map outside_map 5 set transform-set ESP-3DES-SHA
crypto map partner-map 27 set transform-set sha3des
Are merely indicating the name of the transform-set on each side applied to the crypto map, you need to check the configuration of the transform-set itself ''sh run cry ipsec''
Most likely they are correct because of their name (3des/sha), but it does not necessarily means they are correct, please check them with the above command.
I have seen problems with PFS but with other vendors. I guess PFS have this compatibility issues.
Check it out and let us know.
Federico.
01-30-2017 02:44 AM
11-19-2010 06:58 PM
The crypto ACLs are the problem in your case:
PIX515E:
Branch location 1 (using PIX 515E):
access-list outside_5_cryptomap remark ******************************
access-list outside_5_cryptomap extended permit tcp host yyy.yyy.yyy.yyy xxx.xxx.xxx.xxx 255.255.255.0 eq ftp-data
access-list outside_5_cryptomap extended permit tcp host yyy.yyy.yyy.yyy xxx.xxx.xxx.xxx 255.255.255.0 eq ftp
access-list outside_5_cryptomap extended permit tcp host yyy.yyy.yyy.yyy xxx.xxx.xxx.xxx 255.255.255.0 eq ssh
access-list outside_5_cryptomap extended permit tcp host yyy.yyy.yyy.yyy xxx.xxx.xxx.xxx 255.255.255.0 eq telnet
Branch location 2 (using ASA 5510):
access-list acl_9999999 extended permit tcp xxx.xxx.xxx.xxx 255.255.255.0 host yyy.yyy.yyy.yyy eq ftp-data
access-list acl_9999999 extended permit tcp xxx.xxx.xxx.xxx 255.255.255.0 host yyy.yyy.yyy.yyy eq ftp
access-list acl_9999999 extended permit tcp xxx.xxx.xxx.xxx 255.255.255.0 host yyy.yyy.yyy.yyy eq ssh
access-list acl_9999999 extended permit tcp xxx.xxx.xxx.xxx 255.255.255.0 host yyy.yyy.yyy.yyy eq telnet
The crypto ACL have to be 'mirror' images. In your case they are not
Ex. topo:
ssh server(192.168.1.2)-------PIX515----internet---------asa5510------sshclient (192.168.2.2)
crypto ACL on PIX515
access-list 120 permit tcp host 192.168.1.2 eq ssh 192.168.2.0 255.255.255.0
crypto ACL on ASA5510
access-list 120 permit tcp 192.168.2.0 255.255.255.0 host 192.168.1.2 eq ssh
please include 'debug cry isa 127' output if you face any further problem. Also, you should try filters in the tunnel because the crypto acl will be too complicated to be maintained eaisly.
Please do not mask the whole ip address or if you need to mask the complete IP then make sure you are using the same mask every where for that ip address.
11-19-2010 08:15 PM
Vikas,
Thanks for your response. However, I am not sure what you mean by "make sure I am using the same mask if I mask the entire IP address." I did exactly that. All of the xxx.xxx.xxx.xxx addresses are the same IP address, all the yyy.yyy.yyy.yyy addresses are the same IP, etc. As for the ACL's, I can understand your format for the PIX is slightly different than what is currently configured; however, is this the reason why I am getting a phase 2 mismatch and the QM FSM errors in my syslogs on the branch side with the ASA? By the way, I should add that from the branch 2 side, I can ping the yyy.yyy.yyy.yyy node and I get successful responses. However, I cannot telnet to the node on the branch 1 side and they cannot telnet to the branch 2 side.
Mike
11-19-2010 08:58 PM
Hey Mike,
Let me clarify:
>> As for the ACL's, I can understand your format for the PIX is slightly different than what is currently configured; however, is this the reason why I am getting a phase 2 mismatch and the QM FSM errors in my syslogs on the branch side with the ASA?
Yes, your tunnel negotiation is failing because of this, (this is a bit assumed because syslogs will not have the failing proxy IDs but if the peer is same then based on your crypto ACL and the symptoms then negotiations are failing because of this)
It is actually about where is the server port and where is the client port. In the example topology:
sshserver(192.168.1.2)---------PIX515-----------ASA----------ssh client (192.168.2.2)
The server port will always be tcp/22 and the client port will be a higher number random (free) port, based on the above topology if I construct my ipsec sa the local and remote proxy IDs will look like:
On PIX
access-list 120 permit tcp host 192.168.1.2 eq 22 192.168.2.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.1.2/255.255.255.255/6/22)
remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/6/0)
local ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/6/0)
remote ident (addr/mask/prot/port): (192.168.1.2/255.255.255.255/6/22)
In both the above outputs (192.168.X.2/255.255.255.255/6/22) === (6/22) is actually (TCP/22) {6 is decimal protocol number for TCP)
and
(6/0) will be TCP/Any Port
So, the IPSEC SA will be constructed based on the crypto ACL which should be a mirror image on the other side.
>> By the way, I should add that from the branch 2 side, I can ping the yyy.yyy.yyy.yyy node and I get successful responses
I am unable to understand that how can you ping the yyy node from branch 2 when the tunnel negotiation failed, also your crypto ACL does not permit ICMP. Do you have an alternate route to reach yyy from branch2?
>>However, I cannot telnet to the node on the branch 1 side and they cannot telnet to the branch 2 side.
That means in your topology you have the telnet servers on both the side. In that case you have to specify the crypto ACL in this way:
Topology PIX:
telnet server(192.168.1.3)--------PIX------internet-----------asa-------telnet client (192.168.2.0/24)
Topology ASA:
telnet client (192.168.1.X)-----PIX-------internet--------ASA------telnet server(192.168.2.5)
access-list on PIX for server/client
access-list 120 permit tcp 192.168.1.3 eq 23 192.168.2.0 255.255.255.0 >>> When the PIX has the telnet server
access-list 120 permit tcp 192.168.1.0 255.255.255.0 192.168.2.5 eq 23 >>> When the PIX side will become client
Mirror image on ASA
access-list 120 permit tcp 192.168.2.0 255.255.255.0 192.168.1.3 eq 23 >>>> ASA side is client
access-list 120 permit tcp 192.168.2.5 eq 23 192.168.1.0 255.255.255.0 >>>> ASA side is server
Please include the output of show crypto ipsec sa if there is confusion and I will try to be more focused on your configuration rather focus on concept.
>>"make sure I am using the same mask if I mask the entire IP address." I did exactly that. All of the xxx.xxx.xxx.xxx addresses are the same IP address, all the yyy.yyy.yyy.yyy addresses are the same IP,
Sorry, I missed that.
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
Hi all,
I have the same problem: QM FSM error (P2 struct &0x00007ffee97a8450, mess id 0xf613adca)!
The problem is in fase 2 IPSEC.
We are using ASA (release 8.5) and GOOGLE VPN Cloud.
We already checked all the parameters about fase 2 and we finish our idea.
Do you have resolve the problems about QM FSM error?
Parameters:
Encryption protocol
ESP
Hash algorithm
MD5
Authentication Algorithm
aes-cbc-128 (128 bits)
Encryption-Algorithm
SHA1
Transport Mode
Tunnel
Perfect Forward Secrecy
No
PFS group
N.A.
Key Lifetime
10800 seconds
let me know. thanks