After completing an upgrade to Expressway 8.8.1, it was noticed that Mobile and Remote Access (MRA) suddenly stopped working.  After some searching and log files, it was found to be a DNS PTR record issue.  The  implemented “feature” that required the Expressway-E DNS PTR resolution had only been implemented as a requirement in version 8.8.1.

First, the issue was noticed on my iPhone when attempting to login (image below).  In addition, my system failed to query external XMPP contacts.

With the login successful internally and the Expressways just being upgraded, off to the logs.  Upon digging around, I found the error text below.

2016-09-14T22:50:59.171-04:00 expressway-c XCP_JABBERD[19085]: UTCTime="2016-09-15 02:50:59,171" ThreadID="140012303779584" Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:399" Detail="Certificate verification failed for host=192.168.2.98, additional info: Invalid Hostname expressway-e.destephen.c"
2016-09-14T22:50:59.172-04:00 expressway-c XCP_JABBERD[19085]: UTCTime="2016-09-15 02:50:59,172" ThreadID="140012303779584" Module="Jabber" Level="WARN " CodeLocation="ssl.c:505" Detail="The SSL Handshake failed for fd (19). SSL Error code: 1"

With this text, I knew nothing had changed with my certificates.  Off to Google DuckDuckGo lead me to this site that commented about the release notes.  Sure enough, in the release notes, it says that DNS reverse query records are required.

With this, I knew that I had all my DNS configured previously.  I attempted to dig the Expressway record for my deployment, expressway-e.destephen.com that should have resolved to 192.168.2.98.  As expected, it was not working properly.

With the original configuration, there was no DNS record that was configured within my internal domian, destephen.local, that resolved to the expressway-e.destephen.com.  I simply had a stub zone configuration within the Microsoft DNS servers that pointed to my destephen.com dns server.  The fix was to add a new reverse lookup zone and a PTR record for the expressway-e.destephen.com address of 192.168.2.98.

First, the existing DNS configuration for my destephen.local DNS environment.  There is no reverse lookup zone for the 192.168.2 range.

First step is to add the new Zone.

Click Next to begin.

We want to select a Primary Zone to support our needs.

We want to enable the replication of this DNS Zone to other DNS servers, at least for my environment. This should be replicated to any DNS server that the Expressway-C is configured to query.

IPv4 for the zone.

Selecting the Network ID for the reverse lookup zone

Selection of Secure Updates only for Microsoft DNS server only type environments, such as my own.

Confirmation of the setup of the new Zone.

With the new zone defined, we now need to create the new PTR address for expressway-e.destephen.com at 192.168.2.98.  Note that 192.168.2.98 is my “inside” interface for the Expressway-E server.

Insert the applicable details for your environment.

Final configuration of the new Zone and the PTR entry.

A dig -x from a destephen.local machine now successfully queries the expressway-e.destephen.com address.

Last but not least, a clearing of the DNS cache or restart of the Expressway-C server will allow the login of your MRA hosts and register XMPP contacts.

Thanks for reading!