Supporting CUBE NAT Integrations without Firewall ALG


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 "" ""
request ANY sip-header Via modify "" ""
request ANY sip-header Remote-Party-ID modify "" ""
request ANY sip-header Contact modify "" ""
response ANY sip-header Contact modify "" ""
response ANY sip-header Remote-Party-ID modify "" ""
request ANY sip-header Call-Info modify "" ""
request ANY sip-header P-Asserted-Identity modify "" ""
request ANY sdp-header Audio-Connection-Info modify "" ""
request ANY sdp-header Connection-Info modify "" ""
request ANY sdp-header Session-Owner modify "" ""
response ANY sdp-header Session-Owner modify "" ""
response ANY sdp-header Connection-Info modify "" ""
response ANY sdp-header Audio-Connection-Info modify "" ""


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

Yes, hacky. But effective.

The top-level voip and sip config is trivial:

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

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



2 thoughts on “Supporting CUBE NAT Integrations without Firewall ALG

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.