Daryl Hunter – Hubby, Daddy, Mentor, Friend

UPDATE 8/24/09: I have adjusted some of the IOS stuff below – the "firewall/pinhole" is not necessary and I have my "proxy-server" going to the wrong interface.  The way this was setup originally was bypassing "proxy" and just using the directory directly via the "firewall/pinhole" – very bad.  So, the info below is correct now – yikes!

Welcome back!  If you recall, the last time I posted about UC Proxy, I ran into a few random "gotchas" along the way.  Go back and read that – there's some good stuff there.

Turns out there were two more things that didn't work – or at least two more that I'm aware of – and we've got those resolved now.  Let's walk through that.

One Way Audio
This is one I stumbled upon last week.  UC Proxy phones could make and receive phone calls from our "central" campuses.  Those are the ones that sit behind the Cisco ASA cluster.  That was just fine.  However, the "remote" campuses – those that are IPSec/VPN into the Cisco ASA cluster – those were getting one-way audio.  The caller on the "other" end could hear the UC Proxy caller – but the UC Proxy caller just got dead air.  It didn't matter who initiated the call.

Like most one-way audio problems, this one turned out to be a routing problem – but a little different than you may expect.

My UC Proxy MTA was set to 12.x.x.95 – the Public IP address set aside for UC Proxy on my Cisco ASA cluster.  This was set correctly as per the documentation (see my last UC Proxy blog for documentation links).  No problems there.  However, the remote sites had a problem.  When a call to/from a UC Proxy phone was initiated, that phone call traversed the IPSec/VPN tunnel.  My routing only had PRIVATE IPs traversing the tunnel (10.x, 192.168.x, etc).  I use split-tunnel on those IPSec/VPN and any "internet bound" traffic goes out either via NAT overload, or through a secondary ISP.

Why is this bad?  This is bad because the UC Proxy call "stream destination" is 12.x.x.95 – and I wasn't routing it toward the ASA Cluster.  All that it required was a simple route added on each IPSec/VPN router.

        route(config)#ip route 12.x.x.95 255.255.255.255 10.5.1.18

Why that?  10.5.1.18 is the "inside" address of my Cisco ASA cluster.  I just needed to route the UC Proxy phone stream "THIS" way instead of "THAT" way.  Make sense?  Any traffic going to the UC Proxy MTA (12.x.x.95) needed to traverse the IPSec/VPN tunnel rather than follow the normal public routing tables.

Directories / Services URLs
Another annoyance for UC Proxy users was the lost ability to use Corporate/Personal Directories and any publishes services from the CIsco CallManagers.  Why?  Well, you see… we were pointing those to an "internal only" IP Address of 172.x.x.10.  There's no way a Cisco UC Proxy phone could route traffic to an internal (non internet routable) address.  How do you fix that?  Via Proxy.

There are two things to do here… one, adjust the CUCM Administration website and two, adjust the Cisco ASA config.

First of all, here's the CUCM Administration -> System -> Enterprise Parameters

 

See the URL Directories, URL Information, and URL Services entries?  Instead of those pointing to the INTERNAL (172.x.x.10) IP Address of the CUCM Publisher, I'm now pointing those to the EXTERNAL (12.x) IP Address of the CUCM Publisher/proxy.  I'm doing so via a DNS name.  I made a DNS "A" Record pointing to the EXTERNAL/PUBLIC IP.  That's easy stuff.

The next step take place on the Cisco ASA Cluster.  You need to:

• Open a firewall/pinhole on port 8080 from the CUCM Publisher/proxy EXTERNAL IP (NOT NEEDED)
  
• NAT the EXTERNAL IP to the INTERNAL IP (with the dns attribute)
• these are easy, no need to really talk about these in details.  Simple firewall stuff.

The final step is one that confused me.  Let's review our previous phone-proxy config:

media-termination asdm_media_termination
 address 12.x.x.95
!
phone-proxy asdm_phone-proxy
 media-termination asdm_media_termination
 tftp-server address 172.x.x.10 interface Inside
 tftp-server address 172.x.x.11 interface Inside
 tls-proxy Rem_Emp_TLS
 ctl-file lc_remote_employee_ctl
 no disable service-settings
!

No big deal there.  That all looks right.  Except, there's a command missing… We've got the MTA setup (12.x.x.95) and we've got that assigned to the phone-proxy config.  The problem is that <snip> the Cisco ASA doesn't know how to rewrite the proxy commands for the directories.  Inside the phone-proxy command we need to add:

        ASA(config-phone-proxy)#proxy-server address 12.x.x.10 interface Outside

        ASA(config-phone-proxy)#proxy-server address 12.x.x.10 interface Inside

Why?  12.x.x.10 is the EXTERNAL/PUBLIC IP address of my CUCM Publisher. <snip> Without this command, the ASA doesn't know how to handle the proxy / rewrite for the various URLs.

Anyway, that's that.  Everything works.  I'll take time to note the "dns attribute" from above.  Since I'm presenting the URLs to all phones as "cisco-ccm-pub.lifechurch.tv" – that's DNS… and, that resolves to the external 12.x IP.  My internal/behind the ASA campuses cannot go out the ASA and back in.  So, I need a way for those to resolve back to the INTERNAL IP of the publisher.  That's where DNS Doctoring comes into play.  To be verbose, here's my Cisco ASA Static NAT command

        static (Inside,Outside) 12.x.x.10 172.x.x.10 netmask 255.255.255.255 dns

The purpose of the "dns" there is so INTERNAL machines ping "cisco-ccm-pub.lifechurch.tv" and instead of getting the 12.x address, they instead receive ping replies to the 172.x address.  Anyway, just a way to rewrite expected traffic rules.  DNS Doctoring.  It's just what the doctor ordered.  Your mileage may vary here.  I personally need DNS Doctoring – I don't do "internal" DNS for the "lifechurch.tv" zone… you may be using split brain DNS.  Make your configuration accordingly.

Enough of that.  I hope this helps someone.  And, @pilotmike, thank you again for being a great resource to bounce UC Proxy stuff off of.  It's really funny how our two organizations have experienced the same/similar "gotchas" along the way.