Meraki MX ❤️ Cisco CUBE

Meraki products provide incredibly simple setup, excellent network visibility, and cloud management. The CUBE (Cisco Unified Border Element) is the SBC market leader. Sounds like a match made in heaven! Unfortunately, utilizing a CUBE with a Meraki MX isn’t entirely straightforward.

What’s the big deal? Three letters, NAT

NAT has been known to cause havoc with SIP. Unlike many web-based protocols, SIP requires session establishment in both directions. This means that the SIP SDPs contain both public and private IP addresses. (see our previous article on SIP basics). Firewalls enabled with application-level gateway (ALG) capabilities, such as Cisco’s ASA, are able to open packets and rewrite public and private addresses. Unfortunately, Meraki MX units don’t support ALG.

What to do? Below is sample configuration highlighting one possible solution. Let us start by looking at a diagram of the sample network.

CUBE Config: (only showing relevant CUBE portions)

Depending on your dial-peer configuration, the inbound call may ring through, connect for a couple seconds, and then disconnect. If that is the case, you will see SIP messages similar to the one below repeating over and over.  As you can see, the contents of the SIP message contain the internal IP address and not our public IP. The SIP provider will reject these responses and the call will never properly setup.

debug ccsip messages output:

If inbound calls simply fail, you may see a similar message in your debug. The invite is addressed to: [email protected] Because is the public IP and not an address assigned to the CUBE router, the call is being rejected with an error of: SIP/2.0 400 Bad Request – ‘Invalid Host’.

The Fix

CUBE is able to modify the sip and sdp headers via sip profiles. This sip profile will replace the internal IP address ( with the Public IP address (

Once the sip profile has been created. Add it to voice service voip -> sip. It should look like this:

If you are receiving the ‘Invalid Host’ message, create a loopback interface with the the public IP address.

Since the router now has that IP address assigned to it, CUBE will accept the inbound sip message.

If you haven’t already done so, create a DMZ on the Meraki MX and assign it to one of the secondary LAN ports of the MX.  Click here for details on creating a DMZ:
meraki-dmzNext, create a 1:1 NAT entry:

I recommend being more specific on the allowed inbound connections. For testing, this was set to Any/Any.

Once these changes have been made, inbound and outbound calls should be working! The debug on working inbound call will now look like the below message. Notice, all of the IP references have been updated with the public IP addresses. The final message is an ACK from the provider.

With these changes in place, inbound and outbound calls should be working perfectly behind a Meraki MX!

If you have any questions or comments, please leave them below. I would love to hear how this config works in your deployment.