Expressway Configuration

[David Fitzgerald]

I'm in the process of setting up both an Expressway C and an Expressway E device to support my new Jabber implementation.

I'm running into one problem, so I thought I'd post it here.

First, I have both VMs configured, a traversal zone configured, as well as the NAT reflection for the Expressway E.

I went to create my SRV records, and I'm haing an issue with the records for the external DNS servers.

My company uses a private domain internally, and a public domain externally.  So, if the company is called Foo Inc, my external domain is FOO.COM, where my internal domain, which is all Active Directory, is called FOO.CORP.

This being the case, my internals DNS resembles:

HOST  expc.foo.corp  [private IP]

HOST expe.foo.com   [public IP]

SRV  _tcp._cuplogin  0 0 8443 expc.foo.corp

SRV  _tcp._cisco-uds 1 5 8443 cm1.foo.corp

SRV _tcp._cisco-uds 0 0 8443 cm2.foo.corp

SRV  _tcp._sips 10 10 5061 expe.foo.com

SRV  _collab-edge 10 10 8443 expe.foo.com

My external DNS reads

HOST expe.foo.com   [public IP]

SRV  _tcp._sips 10 10 5061 expe.foo.com

SRV  _collab-edge 10 10 8443 expe.foo.com

If I start up a Jabber client when I'm outside of my network, the client attempts to resolve the SRV records which point to the  EXP-E, The problem is that Wireshark tells me that the client is looking for expe.foo.corp, and not expe.foo.com, and as such, the queries are unresolved, as the public DNS server doesn't know about *.corp.

How do I force Jabber to look up on foo.com, and not foo.corp?  Given that the use of a private domain by Active Directory is a best practice, I can't believe I'm the first person to run into this.

[Ayodeji Okanlawon]

I hate to be the bearer of bad news, but unless your foo,corp can be resolved externally (from the internet) then you cant do Jabber MRA. We ran into this yesterday and had TAC engineer on the line and the response is you can only use multiple domains only if the internal domain and external domain are resolvable externally. Here is what TAC said..

"

Hi Ayodeji,

Essentially, you want to have an identical/seamless login process for endusers.  This means that they will need to use the same domain for service discovery externally and internally.  As I understand it, they currently use the ‘faduc.local’ (apologies if I misspelled the domain) domain for internal logins.  Since the .local domain cannot be resolved externally.. this means you need to use the external domain, ‘faduc.eu’, for both internal and external logins.  For both scenarios (internal/external) the jabber client will query the ‘faduc.eu’ domain for SRV records.  This means that the domain configured for sign-in (Ex: username@domain.com) must be resolvable on both the internal and external networks… hence the requirement for DNS resolution."

The problem is that the client will attempt to use the internal domain to login from outside as you have observed and that will fail unless of course it will routable from outside. Part of the reason for this is that when jabber first logs in, it download cache files and configuration parameters. One of the configuration parameters it downloads is called a service location (its a xml file) The domain to use for service discovery if stored in that file. If you check your jabber client (you will find the voice services domain is set to foo.corp)--This is auto-generated based on when the client first logs in.

[Ayodeji Okanlawon]

Hi,

The only solution to this in corroborating what I posted above is to use split DNS domain: This is detailed below:

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.

[Sadaseeven Saminaden]

Hello Mate. 

Thanks for this very useful post. 

Our own implementation is based on what you have explained and it works.

Cheers

Davi

[ev1205]

Hello Sadaseeven Saminaden !!

I have the same situation, I understand that manipulating jabber-config.xml file and internal DNS you can solve domain resolution from Internet.

But for proper MRA operation we must generate CA signed certificates on ExpresswayCore  including Subject Alternative Names of internal devices using internal domain.

Did you change them too?

I really appreciate your collaboration

Best Regards

Enrique

[stuart.pannell]

So according to your answer we would need to create a new forward lookup zone within the internal DNS for collabdomain.com, we have many other services outside of the network running in our external domain and would need to add all of our DNS records accordingly as our internal DNS server would now be authorative for collabdomain.com and stop forwarding requests out to the Internet DNS servers?

[Ayodeji Okanlawon]

Stuart,

I am not an expert on DNS but for MRA to work with multiple domain which this thread addresses, you will need to use split brain DNS. I am not sure if its exactly the same as what you have described. It may well be and if it is then yes you will need to. As explained when your jabber clients are provisioned with the external domain as the service domain, all jabber discovery will be done using this domain. Hence your internal DNS infrastructure needs to be able to locate services using this domain.

[David Fitzgerald]

This issue no longer affects me, as it was two jobs ago.  As I recall, we did figure it all out, but the one issue was a matter of timing.  If a external user connected to Expressway and then used the AnyConnect client to VPN in, some users complained about a temporary loss of connectivity while the unsecured connection was replaced by the secured connection.

When I said that makes perfect sense, they were not amused.  So, bring up VPN BEFORE you open Jabber is the workaround for that.