Overview

Recently had a customer which wanted to connect to a public ITSP (Flowroute). Their network design required a dual-interface CUBE deployment model, with an “inside” private address, and an “outside” DMZ zone. The DMZ zone was also private, with a static NAT configured on their Meraki Firewall.

Meraki firewalls don’t support SIP ALG. This creates a well-known problem with SIP for mapping addresses in SIP headers as well as in SDP and inevitably results in one-way audio problems. These mandate SIP Normalization techniques. In this case, as the CUBE is doing the re-writing, we are forced to usee use IOS-based SIP profiles.

IOS Config

The sip profiles requires rewriting key sip headers and SDP attribues to replace the private IPs with the SNAT IP:

!
voice class sip-profiles 2
request ANY sip-header From modify "192.168.100.100" "99.99.99.99"
request ANY sip-header Via modify "192.168.100.100" "99.99.99.99"
request ANY sip-header Remote-Party-ID modify "192.168.100.100" "99.99.99.99"
request ANY sip-header Contact modify "192.168.100.100" "99.99.99.99"
response ANY sip-header Contact modify "192.168.100.100" "99.99.99.99"
response ANY sip-header Remote-Party-ID modify "192.168.100.100" "99.99.99.99"
request ANY sip-header Call-Info modify "192.168.100.100" "99.99.99.99"
request ANY sip-header P-Asserted-Identity modify "192.168.100.100" "99.99.99.99"
request ANY sdp-header Audio-Connection-Info modify "192.168.100.100" "99.99.99.99"
request ANY sdp-header Connection-Info modify "192.168.100.100" "99.99.99.99"
request ANY sdp-header Session-Owner modify "192.168.100.100" "99.99.99.99"
response ANY sdp-header Session-Owner modify "192.168.100.100" "99.99.99.99"
response ANY sdp-header Connection-Info modify "192.168.100.100" "99.99.99.99"
response ANY sdp-header Audio-Connection-Info modify "192.168.100.100" "99.99.99.99"
!

Notes

In my testing I found that the Diversion and Call-Id headers also showed private IPs. I overwrote these, and CUBE suddently stopped replying to 407s – it just sent new INVITEs without including authorization. I have seen this before, but never got deeper into troubleshooting. Sounds like a bug.

This is then applied to the ITSP-facing dial-peers to manipulate bi-directional RTP flows:

!
dial-peer voice 200 voip
description *** ITSP ***
session protocol sipv2
session target sip-server
destination e164-pattern-map 2
incoming called-number .
voice-class codec 1
voice-class sip profiles 2
voice-class sip bind control source-interface GigabitEthernet0/0/1
voice-class sip bind media source-interface GigabitEthernet0/0/1
dtmf-relay rtp-nte sip-kpml
no vad
!

To avoid errors with CUBE not trusting inbound messages (4XX Invalid Host messages), we cacn implement a workaround by adding a loopback address with our SNAT IP directly the CUBE:

!
interface Loopback0
 ip address 99.99.99.99 255.255.255.255
!

Yes, hacky. But effective.

The top-level voip and sip config is trivial:

!
voice service voip
 ip address trusted list
  ipv4 99.99.99.99
  ipv4 xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx
 address-hiding
 mode border-element license capacity 100
 allow-connections sip to sip
 sip
  early-offer forced
  midcall-signaling passthru
!

A nice config. Easy to implement, and quite fun to configure.

References:

https://bmcallister.com/cisco/meraki-mx-%E2%9D%A4%EF%B8%8F-cisco-cube

https://justinvoip.com/2014/09/24/configuration-example-cisco-cube-with-flowroute/

https://www.collabarchitects.co/single-post/2018/02/06/Meraki-MX-E29DA4EFB88F-Cisco-CUBE