Several months after going launching our BYOD scheme, we started getting reports from people that their iOS devices would fail to connect to our Exchange servers for company email.
They would fail with an error like that shown in the image above.
See below for more details on this issue.
Frustratingly, this only seemed to affect people sporadically, with reports coming in from locations such as;
- London
- Hong Kong
- Bangkok
- Greece
- A Caribbean Island
Even more frustrating, was that whilst it affected one location one day, the following it may not or a site that previously was connecting fine would fail at some other time.
One test we managed to perform was connecting to the Exchange Web Services (EWS) URL on those devices that were having an issue with iOS Mail. This URL will often be known as your Outlook Web Access or OWA URL. With Exchange (well version 2010 at least) the 1st part of this URL is used as the base URL for all EWS.
For example (not these are illustrative & your Exchange admin should be able to supply your correct URLs);
- https://server.fqdn/EWS/xxx
- https://server.fqdn/OAB/xxx
- https://server.fqdn/ActiveSync/xxx
This would invariably work, which showed that the clients could contact our mail server from their location. & over the correct ports.
The break came when one of our Senior Managers was in a location & was affected by the the issue. We ran some lookups from his PC & the reverse lookup for our OWA URL. It appeared to return a DNS entry for the ISP that they were connect to & not our servers Public FQDN as expected.
That was odd, so checking some DNS propagation services showed that the entry for the Public FQDN had not propagated correctly to all DNS severs. This lead to some having forward & not reverse entries.
After doing some more research, it appeared that some ISP’s perform something called “Forward-confirmed reverse DNS” (FCrDNS) as a kind of SPAM or network protection.
The theory for us was that these sites that were being affected, were looking at a DNS server that didn’t have the forward & reverse entries for our Public FQDN & so were blocking the connection. As it seemed to only affect Hotels we also assumed that FCrDNS was part of a security suite from ISP or network hardware manufacturer that primarily supplies that industry.
Getting our External DNS partner to repush the entry & to later liaise with any of their partners whom DNS’s hadn’t updated meant that we past the previous DNS propagation tests… & around a year later this issue has disappeared for us.