locked
Mobile phone Exchange access from inside LAN RRS feed

  • Question

  • Users configure their Exchange accounts on their cell phones to get their e-mail via SSL at gateway.mycompany.com. That URL is my office router/firewall, and I have HTTPS forwarded through it to my Exchange server. So far, so good.

    But then the user brings the cell phone into the office, connects to WiFi on the LAN, and expects it to function the same. It does not, presumably because routers have a problem routing traffic out from the LAN to the WAN, then back in on the same port. That is, the cell phone cannot connect to the Exchange server from inside the office unless they explicitly change their server to be the local name of the server (i.e. ExchangeServer.mycompany.local or even just ExchangeServer, as it exists on the internal DNS).

    So cell phone users just want to get their e-mail from inside the LAN the same as from outside, and I assume there is some general (i.e. not model-specific) firewall-related configuration required--but over my head at the moment.

    I know this is not, technically speaking, an Exchange issue, but a router/firewall issue; however, it is directly Exchange-related and must be a common question for Exchange mobile users and administrators, and I already posted the question (rather fruitlessly) in a couple of routing forums, so I hope someone here has some pointers.


    Thursday, June 18, 2015 12:20 AM

Answers

  • If your external domain name is different to your internal one, then creating internal DNS records for the external domain name (including internal MX records) would be the most usual thing to do in any case, since it helps in many other situations too.

    https://en.wikipedia.org/wiki/Split-horizon_DNS

    Even if you have the loopback thing working, I would still suggest doing it, because it's much more efficient than having things reflected back in from your router.


    OWA For SmartPhone


    Friday, June 19, 2015 11:23 AM

All replies

  • Well. had I searched for "loopback", I would have had my answer. On another forum, someone brought up the term "loopback", which makes perfect sense but which I had not thought of regarding this issue.

    Armed with that one word, I was able to find and use this explicit set of instructions from Dell/SonicWall:

    https://support.software.dell.com/kb/sw8612

    with the one modification that I used an already-set-up service group for services going to my server rather than using a specific service.

    At the same time, others suggested creating an internal DNS forward zone on my Windows server for the external domain, then adding an A host entry for the gateway, but using internal IP addresses in place of the public gateway address. That works also, but I like the simplicity of the loopback better.

    Thursday, June 18, 2015 3:35 PM
  • If your external domain name is different to your internal one, then creating internal DNS records for the external domain name (including internal MX records) would be the most usual thing to do in any case, since it helps in many other situations too.

    https://en.wikipedia.org/wiki/Split-horizon_DNS

    Even if you have the loopback thing working, I would still suggest doing it, because it's much more efficient than having things reflected back in from your router.


    OWA For SmartPhone


    Friday, June 19, 2015 11:23 AM
  • Lee,

    That was actually the first solution someone came up with. My AD domain is mycompany.local.  Cell phones are configure to connect to Exchange server gateway.mycompany.com. So I created a forward lookup zone for mycompany.com on my Windows DNS server, and then created the necessary gateway.mycompany.com A record pointing to the LAN address of the Exchange server. On the WAN, DNS for gateway.mycompany.com points to the IP address of my SonicWall gateway that forwards the appropriate ports (HTTP & HTTPS) through to the Exchange server.

    The problem is that, as soon as I created the forward lookup zone, nobody can reach any other subdomain under mycompany.com (of which there are several, for such things as gateways at this client's remote locations) by public DNS name unless I add an A record matching its public IP address to the new forward lookup zone on my internal DNS server.

    I think that your comments add something to the preponderance of evidence is in favor of maintaining two copies of the A records despite the extra effort, if only so that packets on the LAN have no need to be processed by the router on the way from the cell phone to the Exchange server.

    But can you suggest a configuration that will allow LAN clients to get DNS information for all mycompany.com subdomains except the explitly-definded internal Exchange-related host automatically from the public mycompany.com domain? The DNS split-horizon link is rather general and does not really provide sufficient information on how to do this part or if it is even possible. This would significantly reduce the possibility of error down the road, as there would be no need to replicate public IP DNS records internally--only those required for access to actual LAN-based resources.

    For example, is it possible to create the internal forward lookup zone as a secondary zone having the public zone as the primary but the ability to override the specific one or two A hosts required for access to LAN resources?
    Friday, June 19, 2015 1:56 PM
  • I see no other way than to create lookup zones for the subdomains, I'm afraid. Although you maybe able to create a single zone for *.yourdomain.com , and put the records in there. Can't hurt to try. DNS isn't really my speciality, and you may find a simpler answer by asking in a networking forum regarding this particular detail. I think the effort will still be worth it, though.

    OWA For SmartPhone

    Friday, June 19, 2015 2:48 PM
  • Thank you, Lee. DNS is obviously not my specialty, either. I did post in a MS networking forum also to see if there is a way to do this. Still, the relatively small amount of extra effort is undoubtedly worth it; the biggest issue is remembering to replicate those public DNS records to the internal DNS server if/when they change two years down the road!
    Friday, June 19, 2015 3:33 PM
  • Remembering such things is always the hardest part :-)

    OWA For SmartPhone

    Friday, June 19, 2015 3:48 PM