Collaboration Edge (MRA) with Split DNS Domains

I recently helped one of our customers work through a split DNS domain Collab Edge MRA deployment that was quite educational.  Here are a few tidbits that I picked up.

Scenario:

Customer’s external (internet facing) DNS domain is:  collabdomain.com
Customer’s internal domain is:  internaldomain.local  (not resolvable externally, only served by the internal DNS server)

Expressway-E lives on the internet so it’s hostname would be vcse.collabdomain.com

Expressway-C, CUCM, IM&P (CUP) and Unity Connection live on the internal domain, so they would be called ucm1.internaldomain.local, cup1.internaldomain.local, ucxn.internaldomain.local.

The users accounts would live in internaldomain.local (presumably the LDAP user would be user@internaldomain.local, etc.)

The external DNS server would serve the public collabdomain.com zone.

The internal DNS server would serve internaldomain.local, as well as an internal version of the collabdomain.com zone.

The challenge with these separate domain names is that when a user goes to login to Jabber via MRA, the service discovery process is going to fail because they are going to type in their IM address as user@internaldomain.local, and there is no _collab-edge._tls.internaldomain.local SRV record availble on the itnernet (nor could there be).

To get around this, the jabber-config.xml file can be modified to include the external domain name that Jabber should try to do service discovery against. 

<Policies>
<VoiceServicesDomain>collabdomain.com</VoiceServicesDomain>
</Policies>

Jabber must first login internally (directly on your corporate network) to pull down the jabber-config.xml that includes this policy.

With this configuration now loaded in Jabber, when the user attempts to login from outside via MRA they will still use their user@internaldomain.local credentials, but Jabber will use the specified VoiceServicesDomain — in this case — collabdomain.com.  It will do the SRV record lookup on _collab-edge._tls.collabdomain.com and now be able to resolve Expressway-E and login.

In addition to the the normal _cisco-uds._tcp.internaldomain.local SRV record, Jabber needs another _cisco-uds._tcp.collabdomain.com SRV record (on the internal DNS server) pointing to ucm1.internaldomain.local for MRA to work with the split domains.The one criticism to this method is requiring the Jabber client to login internally first, which isn’t an ideal scenario for large distributed organizations.  One method that is supposed to work around this is to prime Jabber by installing it generically and launching it from an URL:ciscojabber://provision?ServicesDomain=internaldomain.local&VoiceServicesDomain=collabdomain.com

This could be provided in an email and will supposedly launch Jabber so that it tries the external domain without having to ever login internally first.

 

 

32 thoughts on “Collaboration Edge (MRA) with Split DNS Domains

  1. Great information as I`m setting this scenario up as we speak. The one thing is can I test Jabber from the outside without the external dns setup to do proof of concept? Didn`t know if there was a way to included the external ip in jabber-config or other file.

    • Jabber always uses the SRV records to determine if it is inside or outside the network, so you’ll have to setup a DNS server that can at least have the SRV record and an A record for the Expressway-E server. This shouldn’t be that hard to do to just set up a zone with those records and have it forward the rest of the requests upstream.

      • Testing is going well except that Jabber won`t register with Call Manager. Using Nat on a stick in DMZ.

  2. Hello, you promised to give us some more info for the new feature where Jabber is not required to login inside the network first to get the certificate🙂 How does Jabber authenticate in that case? does it not use the cert? does it use the username/password? does it download the cert from the expressway????? Im dying with curiosity!!🙂

    • Jabber always tries to authenticate the certificates. You can hit continue on Jabber which will accept the invalid cert and keep processing the login. As far as not having Jabber login inside first, this doesn’t have anything to do with certificates. It’s about Jabber needing to get the jabber-config.xml which specifies the external voice services domain. The URL in the post at the bottom is supposed to prime Jabber with the so that it doesn’t need to login internally first.

      • Ah right, i completely got it wrong then. i thought that the expressway would first query the jabber client for the certificate for authentication purposes before offering the authentication option using credentials.

        In the case of a completely new Jabber client (end user downloaded it from play store while outside the network), does the Jabber client get referred to the CUCM for authentication or does the expressway E (or C) authenticate the client before referring the conversation to the CUCM?

  3. Hi,
    How will the added line below effect older versions of Jabber? Any experience? I know 9.7 is required for windows client for MRA.

    collabdomain.com

    Thanks,

    Randall

    • I’m guessing you are talking about the policy section in jabber-config.xml. I am guessing it would just be ignored by previous versions as they wouldn’t know what to do with it. I’ve not tried myself.

  4. Is there a way to make a split DNS setup work when using the IPhone and Jabber. We have a different external domain then what we are using for internal.

    With the Expressway Core and Edge setup, is there a way to have this work?

  5. Hi Mike,
    I have a problem when deploying MRA with different domains . we have different external and internal domains , abc.com and abc.internal . To work MRA we need to add _cisco-uds._tcp.solasmarine.com in internal dns server. The issue is we cant add solasmarine.com zone in internal domain since it will unsettle existing internal DNS setup .Is there any workaround for this ?

    Thanks,
    Aneesh

  6. Hi Mike

    As the jabber client needs to verify the certificates of the Expressway-E, CUCM, UCCX, CUPS, etc we need to install certs on these systems that are signed by a CA the client trusts. I’ve found that if using an Internal CA with public domain name for Expressway-E and internal domain names for the rest this is easy enough to get going.

    However when required to use a Public CA (in situations where mobile Jabber clients don’t know about the Internal CA, or an Internal CA doesn’t exist) we’re facing some issues. We could in theory get the same certs signed as above, however as of November 2015 Public CA’s aren’t allowed to sign certificates for internal hostnames anymore, and from October 2016 all publicly signed certificates for internal hostnames will be revoked (see https://www.digicert.com/internal-names.htm).

    Does this mean in these situations we need sign certs for CUCM, UCCX, CUPS, etc using public domain names, and utilise Split DNS on the internal network? And as a result do the local hostnames of these systems need to change as well to match the cert names etc? Would love to hear your thoughts on this issue.

    Cheers
    Peter

  7. Hello there,
    Your post was a great assistance in my jabber deployment however only way I could get jabber to connect from outside was by hardcoding the public domain during Jabber install:

    msiexec /i CiscoJabberSetup.msi VOICE_SERVICES_DOMAIN=publicdomain.com CLEAR=1

    http://www.cisco.com/c/en/us/support/docs/unified-communications/expressway-series/117811-configure-vcs-00.html

    Works fine with Jabber for Windows of course but how do I hardcode this into Jabber for Android or iPhone ?

  8. Got it working actually … had to put URL like the one below on public web site then launch it from Android (make sure to reset your Jabber via Android OS Settings > Application Manager > Jabber then clear data

    ciscojabber://provision?servicesdomain=localdomain.local&VoiceServicesDomain=publicdomain.com

    • Great tip.

      Normally I launch Jabber iOS/Android on the inside of the network first (internal wireless or VPN) so that it can download the jabber-config.xml that has the services domain specified. Then when you go outside the network it knows it. But in the case of a device that can’t get inside the network initially, priming it how you did is a great idea!

  9. Hi Mike, thanks for the great post.

    I deployed MRA with split DNS like in your post.
    It’s working fine with Jabber for Windows, but it doesn’t with Jabber for Android/Iphone. Connection with mobile clients works from internal but not from external. In the Jabber log you see

    csf.config: [UcmConfigQueryImpl.cpp(243)] [fetchXmlFileSet] – Returning: FAILED_TO_AUTHENTICATE_WITH_HOME_UDS

    but I can’t find any reason.
    In Expressway the log says

    SIP/2.0 401 Unauthorised

    but again I can’t find the reason. Any ideas?

  10. I am trying to use the priming option to set the “VoiceServiceDomain” using the ciscojabber:// string.

    Unfortunately it doesn’t look like the Cisco Jabber install registers this protocol (URL:ciscojabber) with windows, so Windows7 has no clue what to the with the URL string when you click on it in an email, or paste it into a run window.

    Has anyone gotten this to work??

  11. Does anyone know if there is a way we can have a CUCM deployment with users on multiple domains i.e. external facing is example.com whereas users may be on abc.com and xyz.com internally?

  12. I have an interesting setup I am attempting to configure. The client has 3 domans.
    Internet facing Domain: company.com
    Internal facing Domain: local.company.com
    DMZ/extranet Domain: local.ext

    The CUCM, IM&P and (VCS C or Expressway C) sit on the local domain. For example CUCM.local.company.com, IM&P.local.company.com, and VCSC.local.company.com.

    The VCS E or Expressway E sits in the extranet domain. For example VCSE.local.ext.

    I don’t know how this scenario is going to work. I am currently in the process of setting it up. From the end user end on the outside the jabber client does an SRV lookup of _collab-edge._tls.company.com. There is a public SRV record which has one A record for the public address of the VCS E.
    Question are:
    1. is the A record pointing at VCSE.company.com even though the real FQDN of the server is VCSE.firm.ext?
    2. Also does anyone think this will work?
    3. If it will work how will the certs be affected with three different domains?
    4. If this will not work should I have the client extend the company.com domain into the extranet? I apologize if it is a stupid question, I am not a DNS expert.

  13. One customer is using this scenario and is able to login, but the Phone Services do not register. Under Edge and Core logs we can see the Core rejecting the REGISTER attempt due to Unknow Domain and this is because the Jabber for Windows 10.6 is sending is SIP AOR as DN@CUCM_IP and of course the CUCM_IP is not a MRA domain.

    The CUCM is uing mixed mode 0 (TCP btw Core and CUCM) and the CUCM is configured with IP (instead hostname or FQDN).
    This doc inform that to use IP is supported (http://www.cisco.com/c/en/us/support/docs/unified-communications/expressway-series/117811-configure-vcs-00.html)

    Question:
    Does anyone know from which field/place the Jabber for Windows (i´m using 10.6) get its domain to construct its AOR for SIP comunications?

    *I taught that it took from servicesdomain or VoiceServicesDomain, but it is not. Any ideas?
    Thanks

    • Sam, I’m not sure if you’re still having issues with this, but I’ve gotten it to work under similar circumstances by setting everything to use the fqdn of CUCM, and all the servers under User Management-> User Settings -> UC Services… basically I reset all the UC Service Profile entries to the FQDN of all servers, especially CUCM for CTI.

      Once everything is set as the dns name instead of the IP address, the client should try to register with @fqdn-of-cucm which the Core will permit since it should have a matching domain.

      btw as far as I know setting the fqdn’s here would also be needed for Jabber to not complain about the certificates if you had signed tomcat and xmpp certs for CUCM/IM&P/CUCXN, etc.

      Mike, thanks for all the tips, keep them coming, good stuff!

  14. Hello, I have this same problem as Aneesh:
    “I have a problem when deploying MRA with different domains . we have different external and internal domains , abc.com and abc.internal . To work MRA we need to add _cisco-uds._tcp.solasmarine.com in internal dns server. The issue is we cant add solasmarine.com zone in internal domain since it will unsettle existing internal DNS setup .Is there any workaround for this ?”

    Any help please Mike.
    Thanks

    • This is where you’ll use the VoiceServicesDomain parameter in the jabber-config.xml file so that it knows what domain to use internally. (Since it is different than the external domain.) The limitation here is that Jabber needs to login at least once on the inside of the network to pull the jabber-config.xml file. Then it will work externally. I do see mention that you can build a custom URL for people to hit from the outside if it isn’t possible for all of your users to login internally first.

      See this page for more information – http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/CJAB_BK_C606D8A9_00_cisco-jabber-dns-configuration-guide.html

      • Hi Mike,
        The problem with this is that Jabber will then only log in via expressway even when inside the organization.
        Whenever you change the voice services domain that is the domain that will be used for service discovery. both cisco-uds and collab-edge.

  15. Hello everyone;

    I am implementing a MRA Exp C, Unity, CUCM, PUB with an internal domain, the Exp-E is an external domain. And internally generated CA certificates for internal services, but the Exp-E should go with a RapidSSL certificate. The problem that I have is to create the traverse area as the rapid SSL does not recognize a SAN with a different domain. Any solution for this. Thank you!!!

    • I getting exactly the same issue with split internal/external domains and can’t see a way around it using the RapidSSL certificate with Exp-E. I can’t get the _cuplogin and _cisco-uds SRV for my external .com domain to be resolved by the Exp-C as I can’t put these SRV records on the internal DNS server without ruining the all SRV records for the external domain.

  16. Hi,
    I’m surprised I can’t find more information on the following issue, given that many people/companies use split DNS.
    I’m also deploying Collab Edge with internal and external domains, along with B2B.
    Of course, the Jabber clients register with internal domain (i.e user@internal.local). External domain is external.com.
    Issue is that when a Jabber client calls another company’s endpoint (i.e, vts@xcompany.com) the Jabber client provides a CLID or call back address of user@internal.local which the other company endpoint can not call. Been looking around in CUCM and the Expressways to see if there’s any way to change that, something like the External Number Transformation Mask, but this field in the Jabber device only allows numeric transforms and not being able to come up with the solution. Any ideas will be greatly appreciated.

    Thanks
    Oskar

  17. If a got the scenario with a .local and a .com Domain, cant i avoid the problem if i use the email = CUCM Username instead of samaccountname?

  18. Hi mark,

    Great post thanks! Could you please detail the required MRA configuration in case of a multiple IM&P domains? I am using CUCM 10.5, IM&P 10.5.
    We are using flexible JID with JID = Directory URI = @mail.

    How Expressway Edge will be able to handle several presence domains?
    Thanks

    I

Leave a Reply

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

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s