I've had a few users tell me in the last few days that they are having trouble connecting to our Exchange Server (2003) with Outlook (2007) over the VPN. I suspect this is a Windows issue involving a more recent security update or something, but cannot narrow this down because while this is news to me, the users tell me it has been happening for at least a month if not more.

The issue is that when users are traveling they need to be able to connect via VPN to Exchange so they can maintain the e-mail and move messages into .pst storage. Obviously just using OWA is not a solution.

What happens is:

- Connecting via VPN over a wired connection = no problems. Outlook can connect to Exchange

- Connecting via VPN using a 3G Aircard = no problems. Outlook can connect to Exchange

- Connecting via VPN throw a Wifi access point, ANY Wifi access point, = Outlook tries but cannot connect to Exchange. I can see all network resources, I can even resolve the Exchange server by FQDN or IP, but Outlook will not connect.

Featured Links*

I worked on this a bit more last night and found some strange things that definitely poitn away from Exchange as the issue. To start, my internal domain, which is protected behind ISA 2006, has a domain name that also exists in the public network, though I do not own the public domain name. It has been like this for 10 years or so without any issues. However, for some reason over Wifi something is allowing the communication to cross over. When I run netstat -n over when connecting over wifi I see Outlook trying to resolve the FQDN of my Exchange server to a public IP that I do not own. When I tracert this IP it winds up stopping at an XO Comm name server in Virginia USA. And when I nslookup the internal domain name it also turns up the same IP. However, when I do all of this over a wired connection, or using a cellular connection I do not get the internal/external crossover. SO it seems to me a Windows update maybe? But now how to trace it back to a particular update.

The only reason I threw out the update idea is because this didn't used to be an issue. This only, as far as I can tell, started to happen over the last 2 to 6 months.

As to how my users connect to Exchange while outside the network, the connect to the internet by some means obviously, and then connect to our network via PPTP VPN. The VPN dialer is configured to use DHCP to get an internal IP, which it appears to do correctly, and to statically use one of our internal DNS servers, which I also think is working. However, when users make this connection over wifi there appears to be a DNS leak that is causing the name resolution of our Exchange server, server2.internalname.com, to resolve to an external domain on a public IP.

What is particularly troubling is that if while on a public connection, not connected in any way to my network, I tracert the FQDN of my mail server it results in that weird public IP. And even more troubling is that I can traceroute ANY word plus the domain name and it turns up the same IP. It's like that domain is set up out on the internet as a rogue.

Another bit of info is that some of my users have found that if they attempt to connect via wifi through their home router they have the described problem. However, if they plug in their computer using a network cable into a port on the same router and make a wired connection VPN->Exchange, they succeed. So the DNS leak is occuring on wifi only as far as I can tell.

Just to make sure it's not the obvious... Did you check the HOSTS file?

If you had an infection of a virus or something, or a piece of spyware, it could've added something to the HOSTS file, and then toss your whole DNS entries on the 2nd row...

Ah, forgot about HOSTS. I'll have to check that.

But that still doesn't explain why I am only seeing leaking over wifi and not over wired (outside of my network) connections. Or does it?

EDIT

I checked HOSTS on a computer that has a fresh install of XP Pro on it and on one of the computers that has displayed the leaks and both are clean. I installed Office 2007 on the fresh computer and configured an existing users profile in Outlook. I then set up the VPN and established a connection over wifi and ran netstat -n and this is what I get:

The 209.50.243.18 is the odd external IP that also turns up when I nslookup outside the network the domain name we use inside the network. I guess the 'State' is indicating the handshake fails, which is good I guess.

I do also see that my internal DNS servers' addresses listed on the first and second line and my VPN addess on the last line.

This will force the computer to ask the DNS server for the info on the Exchange server. If it does this wired properly, but wrong for WiFi connected PC's, I'm again suspecting the WiFi router for maintaining some sort of own DNS or something... Chugging through it's configuration would be my next step...

Hello Neko,

Thank you for all of your replies. Yes, it looks as though the wifi routers are maintaining some sort of DNS of their own. I tested a wired VPN connection again just to verify what I had seen before and everything looks normal as shown below. So for whatever reason on wifi connection the connection tries to resolve the server name out on the public domain instead of being isolated to our private net

I'm not sure this is merely router side, since this is happening when going out through more than just my wifi router. A handful of my associates have commented that this happens at their homes, at customer sites and at hotels. Perhaps something client side that has to do with the broadcom wifi built into the company assigned computers?

I do need to note again also that this was not an issue until maybe 6 months ago. So, perhaps the DNS leak was happening all along, but the public FQDN that matches my internal protected FQDN is now interfering due to some changes on their server???

Well, again, there is a public domain that I don't own that is the same as the name our former administrator chose for our internal network. The intent was to eventually buy that name since it is the name of our company, but somebody in Russia is squating on it and wants an unreasonable amount for it. Our public domain name is different. So for the sake of this discussion:

Our Internal (private) domain could be

Tweetie.com

Our External (public) domain, including MX, could be

FATweetie.com

There also exists a public domain name that is Tweetie.com, but it is not registered to me.

So because of the apparent leaking over wifi, when a client VPNs into our network there is enough of a leak that Outlook, etc. tries to resolve the FQDN for servers and it goes out onto the Internet and obviously fails because I don't own that public domain. I have the VPN client connected to only use our internal DNS, but that doesn't seem to stop the leaking.

Everything inside the firewall appears to be sound. ipconfig /all on all servers and clients is correct, netdiag and dcdiag are correct and internal names all resolve to the correct private IPs.

I just need to figure out how to get the client-side wifi connection to stop leaking.

As a test: hardcode the domain you don't own to your Exchange IP address in a HOSTS file.

If that laptop does connect at that point, you have found your culprit. It's then only a question of how to resolve that.

All of our company assigned computers are domain members, so they all resolve on our netwrok as computer.mydomain.com. I noticed in netstat -n that as soon as I make a connection over wifi outside the firewall, DNS tries to resolve the internal FQDN to that public IP name server.

I added that public IP for the domain (I don't own the public domain name) into HOSTS.

I also noticed that when I nslookup the domain name on the public side of the firewall as domain.com it resolves as mydomain.com.mydomain.com, so I also added that to HOSTS.

Now, as a member of the private mydomain.com, as soon as I make a public network connection the computer will try to communicate with that public NS. But when I establish a VPN connection back to our private network that stops and the computer only communicates with our internal DNS servers, and Outlook successfully connects to Exchange.

Thanks again. I'm still working on this, but I think you have helped me find the right path.

I edited HOSTS to point mydomain.com to the nonroutable internal IP for my PDC, and I also added mailserver.mydomain.com to point to its internal IP. I took out the earlier entries.

Domain member computers still try to connect to the phantom server when I have them outside our network, but as soon as I VPN into our network they only communicate with my internal network servers and stop trying to communicate with the phantom.

Now I just need to figure out how to get the PCs to stop trying to resolve to the phantom server at all.

EDIT

I found this thread on another forum. The OP was running into the same issue: