ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Site-to-Site VPN between Cisco ASA and Meraki MX: The KB I Wish Meraki Had Written

    Self Promotion
    meraki meraki mx cisco cisco asa ipsec networknerd meraki networknerd blog meraki kb vpn
    6
    12
    14.8k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • NetworkNerdN
      NetworkNerd
      last edited by NetworkNerd

      We lit up a new site earlier this year with Charter fiber and needed to connect it back to HQ. Then another site in our area needed to be connected back to HQ, presenting a firewall decision. Should we look to next generation Cisco ASA gear to replace our aging (and soon out of life) 5505s and 5510, look at a different type of product for a firewall, or look at UTMs as a viable option? Our network has been a hub and spoke for a while now with a 5510 at HQ and 5-6 other ASA 5505s out in the wild.

      After much research and deliberation, we landed on Meraki MX gear. We got a MX84 for HQ and MX64s for the remote sites. This post is a little bit about the implementation and some hurdles we needed to jump to get the different gear working for site-to-site VPN capabilities to work as expected.

      The plan was to take care of the spoke sites first, get all of the ASA 5505s replaced with MX64s, and connect them back to HQ's 5510 using IPSec. Then we'd replace the ASA 5510 with the MX84 and connect all sites again. I started reading up on this before we got the Meraki gear to prepare for what was coming. When deploying ASAs in the past, we had hired a consultant to do the configuration for us since none of us are Cisco proficient. I know enough to be dangerous within ASDM, but I cannot say the same from the command line. After several years in IT, I had never once tried to setup an IPSec tunnel on my own. This was the time. I'd save the company consultant fees for every device by tackling it myself.

      Here's the KB from Meraki on creating a tunnel between Cisco ASAs and Meraki MX: https://documentation.meraki.com/MX-Z/Site-to-site_VPN/Cisco_ASA_Site-to-site_VPN_with_MX_Series. That article is written for ASA version 8.3 and higher. We just happened to be on version 8.4(4)1 across the board, so things looked a little different. In any case, the directions were pretty easy to follow. Here's a click by click using ASDM in the version we had. The steps were similar to this and performed on our ASA 5510

      • Go to Wizards -> VPN Wizard -> Site-to-Site VPN Wizard, and click Next to continue.
        0_1470693660724_ASASitetoSiteVPNWiz.png

      • Leave the VPN interface as outside, and enter the peer ip (which, in my case, was the WAN ip of one of the MX64 devices).
        0_1470693754750_ASASitetoSiteStep2.png

      • Turn off IKEv2 since Meraki only supports v1.
        0_1470693815323_ASASitetoSiteStep3.png

      • Identify local and remote networks. We liked using network objects in the ASA.
        0_1470694303511_ASASitetoSiteStep4.png

      • Enter the pre-shared key for your tunnel. No device certificate is needed here.
        0_1470694373299_ASASitetoSiteStep5.png

      • There is no need to change anything here. As the Meraki KB states, the MX security appliance can accept any of the following Encryption algorithms: DES, 3DES, AES-128, AES-192 and AES-256. Additionally the MX can accept either SHA1 or MD5 as the authentication hashing algorithm.
        0_1470694429696_ASASitetoSiteStep6.png

      • Be sure to check the option to exempt ASA side host/network from address translation, and leave it set to inside interface.
        0_1470694559935_ASASitetoSiteStep7.png

      • Now you see the summary of the changes, so go ahead and click finish to setup the connection profile on the ASA side.
        0_1470694640741_ASASitetoSiteStep8.png

      As seen in the connection Profiles list...
      0_1470694680604_ASASitetoSiteStep9.png

      • As we all know, sometimes using a wizard enables some options you don't want. At this point, I like to go to Configuration -> Site-to-Site VPN in ASDM and edit the connection profile. Once the edit profile window opens, expand Advanced from the left-hand tree, and go to Cryptomap Entry. Uncheck the option for NAT-T (since we have no other NAT device between the ASA and the MX). Click ok, and apply the changes. Be sure to save those to the startup configuration of the ASA as well.
        0_1470695164334_ASASitetoSiteNATT.png

      • That's all that should be needed on the ASA side in terms of changes, so the rest we do on the Meraki MX side. This involves jumping into the Dashboard and setting up a Non-Meraki Peer (under Security Appliance -> Site-to-Site VPN on the Meraki network in question). We'll assume the public ip of the ASA is 2.2.2.2. Use the same pre-shared key for the tunnel as you entered on the ASA side. Save your changes, and wait a couple of minutes.
        0_1470695451213_MerakiMXSitetoSite1.png

      • If you start testing after making these changes to the MX, you will find that the tunnel connects, and you can send traffic between networks. It may even work for the better part of a day, but the tunnel will eventually drop unexpectedly. The root cause here is that the phase 1 and phase 2 negotiations for IKE / IPSec start to fail according to what you see in the Meraki event logs. But I followed the article. Everything should be fine, right? Wrong.

      *Here's another article Meraki links to at the bottom of that first article - https://documentation.meraki.com/MX-Z/Site-to-site_VPN/Troubleshooting_Non-Meraki_Site-to-site_VPN_Peers. Inside that article they finally tell you the default settings a MX uses when connecting with a 3rd party vendor's gear:

      Cisco Meraki devices have the following requirements for their VPN connections to non-Meraki peers:
      Preshared keys (no certificates).
      LAN static routes (no routing protocol for the VPN interface).
      IKEv1 (IKEv2 not supported) in Main Mode (aggressive mode not supported).
      Access through UDP ports 500 and 4500.

      • Go back to the ASA for a second, and dig into the connection profile you setup earlier. In the Basic settings, you see the IKE Policy list. Click the Manage button next to that to see a listing of all IKE policies.
        0_1470696024327_ASAIKEPolicies.png
        If you highlight one of the polcies and choose to edit, you will see the default negotiation settings the ASA is using.
        0_1470696031508_ASAIKEPolicies1.png

      At this point there are two options - change negotiation settings on the ASA side to match the Meraki MX, or change the Meraki MX negotiation settings to match the ASA side. I went with the latter option since I had the ASA 5510 connected to several 5505s and did not want to have to touch all of them.

      • Back inside the same Site-to-Site VPN area of Meraki Dashboard as before, click the Custom link under IPsec Policies.
        0_1470696384014_MerakiMXSitetoSite2.png

      *Once that opens, you can adjust all of the parameters so that the lifetime matches and the encryption and authentication settings for both settings match everything being used in your IKE Policies from the Cisco ASA. The settings below are what worked for me.
      0_1470696516701_MerakiCustomIPsec.png

      Once these changes were made, the tunnel was solid. I learned this the hard way so hopefully this can benefit someone else. I will also say that every MX device you want to connect back to a 3rd party device must be in Hub mode (can't just be in spoke mode). The Non-Meraki peer you setup will be available to connect to any other MX devices in your Meraki Organization.

      1 Reply Last reply Reply Quote 12
      • Reid CooperR
        Reid Cooper
        last edited by

        Great write up!

        1 Reply Last reply Reply Quote 1
        • Q
          qwerty_123_
          last edited by

          HI,

          I never leave replies for anything but this is really helped me out. I have 12 locations with ASAs and couldn't figure out why they kept dropping. Made the changes you mentioned and have had solid tunnels. Meraki really dropped the ball on that tutorial.

          Many thanks

          NetworkNerdN 1 Reply Last reply Reply Quote 3
          • NetworkNerdN
            NetworkNerd @qwerty_123_
            last edited by

            @qwerty_123_ said in Site-to-Site VPN between Cisco ASA and Meraki MX: The KB I Wish Meraki Had Written:

            HI,

            I never leave replies for anything but this is really helped me out. I have 12 locations with ASAs and couldn't figure out why they kept dropping. Made the changes you mentioned and have had solid tunnels. Meraki really dropped the ball on that tutorial.

            Many thanks

            You're most welcome. I'm glad it helped someone else get it solved quicker than the first time I tried. 🙂

            1 Reply Last reply Reply Quote 0
            • wirestyle22W
              wirestyle22
              last edited by

              @NetworkNerd How reliable has this been for you and what do you have a each site out of curiousity?

              NetworkNerdN Q 2 Replies Last reply Reply Quote 0
              • NetworkNerdN
                NetworkNerd @wirestyle22
                last edited by

                @wirestyle22 said in Site-to-Site VPN between Cisco ASA and Meraki MX: The KB I Wish Meraki Had Written:

                @NetworkNerd How reliable has this been for you and what do you have a each site out of curiousity?

                After making the changes here, the tunnel was solid (no issues that I was ever aware of after that). We eventually replaced every ASA with a Meraki MX device (last ASA 5505 swapped out in October / November sometime).

                For the purposes of this article, we had a Cisco ASA 5510 on one end and a Meraki MX64 on the other end.

                1 Reply Last reply Reply Quote 0
                • Q
                  qwerty_123_ @wirestyle22
                  last edited by

                  @wirestyle22 I am replacing a 5515 at HQ with an MX84. I have 12 locations with 10 ASA 5505s and 2 Peplink devices. I also have a vpn connection from HQ to AWS. I have only had it up for the past couple days but it seems to be holding steady. The taking off of the NAT-T and changing the lifetime.

                  1 Reply Last reply Reply Quote 2
                  • J
                    jakub.wawrzacz-p1
                    last edited by

                    Hi NetworkNerd,

                    I SIMPLY HAD TO create an account to say BIG THANK YOU for putting this together, so thoroughly and being so pedantic about details (just like me) with all information that one could possibly need. It saved my "bacon" two days ago when setting up S2S VPN between MX84 and ASA5510. I couldn't work out why it doesn't sync. Without your KB I'd have to reschedule an important project so again, thank you. I can only hope you got more of these coming.

                    NetworkNerdN 1 Reply Last reply Reply Quote 3
                    • NetworkNerdN
                      NetworkNerd @jakub.wawrzacz-p1
                      last edited by NetworkNerd

                      @jakub-wawrzacz-p1 said in Site-to-Site VPN between Cisco ASA and Meraki MX: The KB I Wish Meraki Had Written:

                      Hi NetworkNerd,

                      I SIMPLY HAD TO create an account to say BIG THANK YOU for putting this together, so thoroughly and being so pedantic about details (just like me) with all information that one could possibly need. It saved my "bacon" two days ago when setting up S2S VPN between MX84 and ASA5510. I couldn't work out why it doesn't sync. Without your KB I'd have to reschedule an important project so again, thank you. I can only hope you got more of these coming.

                      You are most welcome. I'm so glad it helped someone! It was too crazy of a situation not to tell the story. I have more articles if you search for the networknerd blog tag in Mangolassi (https://mangolassi.it/tags/networknerd blog). And, I've recently created my own personal blog at http://blog.thenetworknerd.com that I try to update regularly with different content.

                      J 1 Reply Last reply Reply Quote 2
                      • J
                        jakub.wawrzacz-p1 @NetworkNerd
                        last edited by jakub.wawrzacz-p1

                        @networknerd I will check out the blog as well thank you. Btw: just to give you an update, I had to do 2 more things to get a stable tunnel and that is set the 2nd Phase Lifetime to be lower than the Phase 1 and remove other encryption policies on the ASA. For example, I used for Phase One 3DES, SHA, DH Group 2 and Lifetime 86400 and for Phase 2 I used AES192, SHA, PFS Off and Lifetime 28800. On the ASA side, I disabled the IKev2 and for the Encryption Policy I only left enabled what you see above, plus obviously matched the time to 28800. I got stable tunnel then. Before these changes the tunnel kept dropping.

                        NetworkNerdN 1 Reply Last reply Reply Quote 1
                        • NetworkNerdN
                          NetworkNerd @jakub.wawrzacz-p1
                          last edited by

                          @jakub-wawrzacz-p1 said in Site-to-Site VPN between Cisco ASA and Meraki MX: The KB I Wish Meraki Had Written:

                          @networknerd I will check out the blog as well thank you. Btw: just to give you an update, I had to do 2 more things to get a stable tunnel and that is set the 2nd Phase Lifetime to be lower than the Phase 1 and remove other encryption policies on the ASA. For example, I used for Phase One 3DES, SHA, DH Group 2 and Lifetime 86400 and for Phase 2 I used AES192, SHA, PFS Off and Lifetime 28800. On the ASA side, I disabled the IKev2 and for the Encryption Policy I only left enabled what you see above, plus obviously matched the time to 28800. I got stable tunnel then. Before these changes the tunnel kept dropping.

                          That's great information to have. Thanks for sharing!

                          1 Reply Last reply Reply Quote 0
                          • jt1001001J
                            jt1001001
                            last edited by

                            Old post but just had to do this for an implementation we are rolling out. Thanks!

                            1 Reply Last reply Reply Quote 1
                            • 1 / 1
                            • First post
                              Last post