QM FSM error is typically phase 2 issue on VPN L2L and can be simply remediated.
When establishing VPN L2L tunnel you may experience misconfiguration/mismatch between both peers.
From my experience most two common issues with VPN’s(ikev1 or ikev2) are:
- Mismatch on proposals (isakamp or ipsec)
- Crypto mismatch for interesting traffic
QM FSM error belongs to the second one but to get to this point we need to debug in order to see this. Remember debug is your friend so use it habitually!
Two powerful debug commands to remember are:
debug cryptko ikev1 127
debug crypto ipsec 127
Make sure your terminal monitor is enabled on your cli prior enabling them. #127 is a magic number that balances noise with useful information.
Once enabled please make sure you are logging session to a file.
Relevant debug output below from the broken VPN L2L:
Nov 6 10:10:35 10.254.116.57 Nov 06 2017 09:10:35: %ASA-3-713902: Group = 188.8.131.52, IP = 184.108.40.206, QM FSM error (P2 struct &0x00007fcf8f5fdbe0, mess id 0xcdd52f6a)!
Nov 6 10:10:35 10.254.116.57 Nov 06 2017 09:10:35: %ASA-3-713061: Group = 220.127.116.11, IP = 18.104.22.168, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 192.168.70.0/255.255.254.0/0/0 local proxy 192.168.174.0/255.255.255.0/0/0 on interface outside
Nov 6 10:10:27 10.254.116.57 Nov 06 2017 09:10:27: %ASA-3-713902: Group = 22.214.171.124, IP = 126.96.36.199, Removing peer from correlator table failed, no match!
From the debug it states that for the peer group =188.8.131.52(your remote peer) IPSEC is being rejected due to no matching crypto map.
At this point verify your crypto map ACL and make sure both sides are matching. It could be as simple as mismatch in subnet that will cause the tunnel to reject it. In fact that was the case in this scenario where remote peer was proposing /23 and local side was /24.
Configuration should always be identical. Make sure to utilize some kind of VPN form so both sides agrees on all the settings. Unfortunately there is always a human error factor.