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.
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