Site to Site VPn fails after router exchange

[Isynth]

Dear community,

after switching the router in our datacenter from a RV180 to RV340 the VPN tunnels won't come up.

I get this output from two asas trying to establish the tunnel

 IKE MM Initiator FSM error history (struct &0x00007f9794ad6d00)  <state>, <event>:  MM_DONE, EV_ERROR-->MM_WAIT_MSG6, EV_PROB_AUTH_FAIL-->MM_WAIT_MSG6, EV_TIMEOUT-->MM_WAIT_MSG6, NullEvent-->MM_SND_MSG5, EV_SND_MSG-->MM_SND_MSG5, EV_START_TMR-->MM_SND_MSG5, EV_RESEND_MSG-->MM_WAIT_MSG6, EV_TIMEOUT

And at the end a NAT-T message

Automatic NAT Detection Status:     Remote end is NOT behind a NAT device     This   end   IS   behind a NAT device
Jul 17 06:57:39 [IKEv1]Group = XXXXXXX, IP = XXXXX Floating NAT-T to port 4500
Jul 17 06:57:39 [IKEv1]IKE Receiver: Packet received on 10.10.100.1:4500 from XXXXX

I checked the preshared keys and the configuration of the old router, still no luck

IKEv1 SAs:

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: XXXXXXX
    Type    : L2L             Role    : initiator
    Rekey   : no              State   : MM_WAIT_MSG6

No Nat or portforwarding configured on the router. Firewall disabled for testing purpose.

Every hint is really appritiated. I am so stuck here.

kr

[Dennis Mink]

Can you check, double check and check again the configuration of the previous 180 with that of the 340.

also have you changed IOS?

[Isynth]

I checked again. Everything is the same... I don't understand why the tunnel isn't coming up on the new router. As soon as I switch back to the old one it's working.

Updated both router to the newest OS

Please find the debug message of the ASA in my next post

[Isynth]

Checked several times I'm 100% sure

This is the last output I get:

PHASE 1 COMPLETED
Aug 21 07:51:26 [IKEv1]IP = XXX.XXX.XXX.XXX, Keep-alive type for this connection: DPD
Aug 21 07:51:26 [IKEv1 DEBUG]Group = XXX.XXX.XXX.XXX, IP = XXX.XXX.XXX.XXX, Starting P1 rekey timer: 27360 seconds.
Aug 21 07:51:26 [IKEv1]Group = XXX.XXX.XXX.XXX, IP = XXX.XXX.XXX.XXX, Add to IKEv1 Tunnel Table succeeded for SA with logical ID 96706560
Aug 21 07:51:26 [IKEv1]Group = XXX.XXX.XXX.XXX, IP = XXX.XXX.XXX.XXX, Add to IKEv1 MIB Table succeeded for SA with logical ID 96706560
Aug 21 07:51:26 [IKEv1]IKE Receiver: Packet received on 10.10.100.1:4500 from XXX.XXX.XXX.XXX:4500
Aug 21 07:51:26 [IKEv1]IP = XXX.XXX.XXX.XXX, IKE_DECODE RECEIVED Message (msgid=9aabc695) with payloads : HDR + HASH (8) + DELETE (12) + NONE (0) total length : 80
Aug 21 07:51:26 [IKEv1 DEBUG]Group = XXX.XXX.XXX.XXX, IP = XXX.XXX.XXX.XXX, processing hash payload
Aug 21 07:51:26 [IKEv1 DEBUG]Group = XXX.XXX.XXX.XXX, IP = XXX.XXX.XXX.XXX, processing delete
Aug 21 07:51:26 [IKEv1]Group = XXX.XXX.XXX.XXX, IP = XXX.XXX.XXX.XXX, Connection terminated for peer XXX.XXX.XXX.XXX.  Reason: Peer Terminate  Remote Proxy 0.0.0.0, Local Proxy 0.0.0.0
Aug 21 07:51:26 [IKEv1]Group = XXX.XXX.XXX.XXX, IP = XXX.XXX.XXX.XXX, Remove from IKEv1 Tunnel Table succeeded for SA with logicalId 96706560
Aug 21 07:51:26 [IKEv1]Group = XXX.XXX.XXX.XXX, IP = XXX.XXX.XXX.XXX, Remove from IKEv1 MIB Table succeeded for SA with logical ID 96706560
Aug 21 07:51:26 [IKEv1 DEBUG]Group = XXX.XXX.XXX.XXX, IP = XXX.XXX.XXX.XXX, IKE SA MM:b2554993 terminating:  flags 0x0101c802, refcnt 0, tuncnt 0
Aug 21 07:51:26 [IKEv1]Group = XXX.XXX.XXX.XXX, IP = XXX.XXX.XXX.XXX, Warning: Ignoring IKE SA (src) without VM bit set
Aug 21 07:51:26 [IKEv1]Group = XXX.XXX.XXX.XXX, IP = XXX.XXX.XXX.XXX, Session is being torn down. Reason: User Requested

[syz]

Migrating from RV to ASA sometimes can be tricky since RV'gui allows only one entry for the Security Association wherein the ASA you can have a full ACL as interesting traffic. Here my humble guess without config info:

It could be a mismatch on the Crypto ACL for phase based on the following log:

Reason: Peer Terminate  Remote Proxy 0.0.0.0, Local Proxy 0.0.0.0

that seems to be an any to any in the Crypto ACL for one of the sites. After the migration you need to confirm ACL in the crypto map looks exactly mirrored. let's say SiteA: subnetA to subnetB   -  SiteB: subnetB to subnetA

[syz]

Isynth 
I hope you found the issue since this was 2 years ago, 

MM_WAIT_MSG6

Most of the times could be related to PSK mismatch but in this case, it seems to be related to NAT-T, you can see it is in use enforced by the remote end since:

This   end   IS   behind a NAT device

But then in the logs shown below you can see Phase1 completed