CUBE SIP NAT Puzzel

[DrVoIP]

I have a CUBE configuration that is also acting as an internet gateway.  Unfortunately applying a NAT to the interface destroys SIP and the gateway fails.  Remove NAT and all is well.   This is in a rural community in which they cant really afford multiple devices, so we need to figure out how to best configure the interface so that it can  support both internet traffic and SIP traffic.     The carrier uses the public IP address to authenticate.   We considered using a subinterface but there is not equipment to front end the trunk creation.   Is it possible to set a static NAT and bind to a loop back interface for the SIP traffic?

Open to recommendations on how best to make this work! 

[Spooster IT Services]

Hi Peter Buswell,

Yes you can achieve this. You need to use policy based NAT. Can you post or attach the router's configuration so that i can help with sample config.

[DrVoIP]

Configuration deleted to protect client privacy. 

[Spooster IT Services · Accepted solution]

Hi try the following configuration:-

no ip access-list extended nonat
!
ip access-list extended nonat
deny ip  10.11.2.0 0.0.0.255 10.0.0.0 0.255.255.255
deny ip 10.11.6.0 0.0.0.255 10.0.0.0 0.255.255.255
deny ip 10.11.102.0 0.0.0.255 10.0.0.0 0.255.255.255
deny ip 10.10.7.8 0.0.0.7 10.0.0.0 0.255.255.255
permit ip  10.11.2.0 0.0.0.255 any
permit ip 10.11.6.0 0.0.0.255 any
permit ip 10.11.102.0 0.0.0.255 any
permit ip 10.10.7.8 0.0.0.7 any

no ip nat service sip udp port 5060
ip nat inside source list nonat interface GigabitEthernet0/0/0 overload

I see there are two default routes is the following one in use?

"ip route 0.0.0.0 0.0.0.0 166.130.171.112"

[DrVoIP]

The NAT policy was the correct strategy however, we ran into an issue making it work.  We ultimately contacted TAC and received the following: 

The problem details you have provided suggests that you have run into a known limitation with configuring an IOS-XE based router with a single IP address being used for both SIP and NAT. An enhancement request has been opened to provide this functionality, but it has not yet been implemented. See:

CSCuy82008    Support NAT and UC (CUBE) on same ASR1k                                        

You may be able to workaround the issue as documented in the link above, by first removing all NAT configuration, reloading the router, and configuring SIP first. I have seen this workaround unsuccessful at times or the issue return after reloading the router. So, it is not a viable workaround in some circumstances.

I would instead recommend to configuring an additional interface, either a physical or a loopback, with a different public IP address than what is used for NAT.

Thanks for you recommendation as it was correct.   I hope we all learned something here!  Regards, - DrVoIP

[KEVIN DELANEY]

Hi,

I may be facing the same thing soon. Let me ask (since the config has been deleted) are you using the cube with one side with a Private IP, the other with a Public and using the Public side to reach a SIP provider on the Internet?

If so how are you reaching the SIP Provider without NAT? My config would look like:

CUCM -> [g0/0 - CUBE - g0/1] -> Internet/SIP Provider

So if you see what Im saying here in order for the CUCM communication to reach the service provider on the Internet, it would have to be NATed on the g0/1 (right???)

Or is the cube performing a media termination at g0/0 and re-originating the traffic from g0/1 and thats why you don't need NAT and it works?

Sorry I know thats just a basic CUBE question. But that leads me to the real question. If its the latter and (cube is performing a media termination at g0/0 and re-originating the traffic from g0/1) then are you saying when you try to do a NAT overload on the public side interface, so the router can simultaneously be an Internet gateway (for browsing and whatnot) it breaks the CUBE functionality? Because this was the exact idea I was going to try to do.

Thanks.

[DrVoIP]

Kevin your config was exactly the same as ours.  Ultimately the solution was to use a new public ip to NAT Internet traffic on Gig interface and move the sip traffic  and public ip via static NAT to loopback0.  Given the amount of time wasted on this unsported configuration (NAT in CUBE) we will now make this a standard practice in these config issues. - DrVoIP.com

[DrVoIP]

Kevin (and interest others) - I spoke to soon! (play on words?).  So moving sip to the loopback had the effect of enabling internet access and SIP to work.  There is however a major issue - ONE WAY AUDIO.   I have tried all combinations of NAT or NO NAT but I cant get the audio working from INSIDE to OUTSIDE.   So an inbound call, does NOT hear audio, but the caller hears the INSIDE person!    The running configuration, along with debug ccsip messages and ccapi inout and - as an additional bonus - output of the show voip rtp connections is also in the file.

Anybody have  an idea, I am game to try it!

[Dennis Mink]

Can you ping the phone FROM your loopback's IP address?

Please rate if useful

[DrVoIP]

Yes, using extended ping shows no connectivity issues between devices.  The configuration looks like this.

PSTN_IP=>(G0/0=>STATIC-NAT L0=>G0/1)=>LAN

Internet_IP=>(G0/0=>NAT Overload =>G0/1)=>LAN

Again SIP messages are exchanged in both directions; Audio is NOT heard by Caller but Inside Device hears Caller. No firewall is involved.  The SIP Trunk from CUCM is pointing at G0/1.  If I change it to point at L0, SIP breaks, so it is currently pointing at G0/1.

[DrVoIP]

The issue with one way audio was easier to figure out after setting up a packet capture.  The captured showed that the carrier was seeing the outbound audio RTP stream as coming from the IP of the loopback0 address and not the public ip of the WAN interface.  You will remember that we statically NATed the public IP of the GiG0/0/0 interface to the loopback0, which fixed sip messages, but breaks on audio.   I think we will now see if we can get a trunk from the carrier and reconfigure around a subinterface strategy and see how that works!

At the end of the day, SIP and NAT just do not work will together!