cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

4269
Views
0
Helpful
7
Replies
Beginner

VPN Site-to-Site Tunnel Issue

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

7 REPLIES 7

Re: VPN Site-to-Site Tunnel Issue

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.

Beginner

Re: VPN Site-to-Site Tunnel Issue

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

Re: VPN Site-to-Site Tunnel Issue

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.

Beginner

Hi all,

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

Cisco Employee

Re: VPN Site-to-Site Tunnel Issue

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.

Beginner

Re: VPN Site-to-Site Tunnel Issue

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

Cisco Employee

Re: VPN Site-to-Site Tunnel Issue

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)

on ASA
access-list 120 permit tcp 192.168.2.0 255.255.255.0 host 192.168.1.2 eq 22

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.