beausoleil
Beta member
- Messages
- 1
This is my first post to ComputerForums - I found it while trying to solve my wife's laptop DNS problems, and hopefully someone here can help.
The IT group at her company is, in my opinion, very weak when it comes to networking issues, and cannot (won't?) resolve her issue, because she's the only employee who routinely remotes into their network using a Verizon broadband cellular modem.
Let me give a little background information:
Her company uses MS Sever 2003 and Exchange to provide both Outlook Web Access externally through their firewall, and standard Exchange RPC access for Outlook clients internally and also via a VPN connection. They run a split DNS system, so their Exchange server has different internal and external IP addresses. And their firewall blocks Outlook/Exchange RPC protocol directed to their external IP address for Exchange, allowing only OWA via http/https from external users. The only exception, naturally, is for external clients using VPN access.
The problem is as follows:
When using a direct wifi connection via the laptop's internal wifi card, or an external wifi router via ethernet, her Sonicwall SSL/VPN client works fine - the VPN connection comes up, and she gets new per-connection DNS server addresses to use (from her work's internal network).
When she fires up her Verizon broadband connection, her Verizon broadband dial-up network connection gets a Verizon DHCP IP address and two DNS server addresses to use. It works correctly - she can access the Internet normally.
The problem is when she fires up her Sonicwall VPN client, running over the Verizon broadband connection. The connection comes up, and she can pass traffic to her company's internal file servers and intranet web servers, but her Outlook client can't connect to their Exchange mail server.
Inspection using NSLOOKUP shows that when Outlook does a DNS lookup for her Exchange server IP address, the XP client DNS resolver will only check with the Verizon DNS servers on the original connection, and not with the server addresses defined by the VPN connection. Hence, the ip address Outlook finds in the XP DNS resolver cache is the external IP address of their Exchange server - which doesn't allow RPC access. It seems that the XP DNS resolver is not checking for connection-specific DNS servers - it's only checking the servers defined in the original broadband dialup connection.
I have a temporary workaround in place by disabling DNS via DHCP on her broadband connection and explicitly defining her company's DNS server addresses there. Of course, for general Internet use, she has to still bring up her VPN connection so she can actually get to a DNS server.
I haven't yet tried disabling DNS caching yet, as I don't thing that would work, since the IP address of her Exchange server shouldn't even be cached yet. I can try it, though.
I'm not a Windows networking expert - I'm more of an infrastructure/routing/switching kinda guy, with some detailed Linux experience, but it's been years since I've dug into Windows internals.
It seems like a bug, since you'd think that Outlook is looking for the IP address of a connection-specific DNS host, and since the Verizon connection doesn't register her PC's domain name in DNS, when given a "hostname.workname.com" name to resolve, it would first check the DNS servers defined on the connection with that same "workname.com" defined - in her case, the Sonicwall VPN connection...
Any ideas for a permanent fix?
The IT group at her company is, in my opinion, very weak when it comes to networking issues, and cannot (won't?) resolve her issue, because she's the only employee who routinely remotes into their network using a Verizon broadband cellular modem.
Let me give a little background information:
Her company uses MS Sever 2003 and Exchange to provide both Outlook Web Access externally through their firewall, and standard Exchange RPC access for Outlook clients internally and also via a VPN connection. They run a split DNS system, so their Exchange server has different internal and external IP addresses. And their firewall blocks Outlook/Exchange RPC protocol directed to their external IP address for Exchange, allowing only OWA via http/https from external users. The only exception, naturally, is for external clients using VPN access.
The problem is as follows:
When using a direct wifi connection via the laptop's internal wifi card, or an external wifi router via ethernet, her Sonicwall SSL/VPN client works fine - the VPN connection comes up, and she gets new per-connection DNS server addresses to use (from her work's internal network).
When she fires up her Verizon broadband connection, her Verizon broadband dial-up network connection gets a Verizon DHCP IP address and two DNS server addresses to use. It works correctly - she can access the Internet normally.
The problem is when she fires up her Sonicwall VPN client, running over the Verizon broadband connection. The connection comes up, and she can pass traffic to her company's internal file servers and intranet web servers, but her Outlook client can't connect to their Exchange mail server.
Inspection using NSLOOKUP shows that when Outlook does a DNS lookup for her Exchange server IP address, the XP client DNS resolver will only check with the Verizon DNS servers on the original connection, and not with the server addresses defined by the VPN connection. Hence, the ip address Outlook finds in the XP DNS resolver cache is the external IP address of their Exchange server - which doesn't allow RPC access. It seems that the XP DNS resolver is not checking for connection-specific DNS servers - it's only checking the servers defined in the original broadband dialup connection.
I have a temporary workaround in place by disabling DNS via DHCP on her broadband connection and explicitly defining her company's DNS server addresses there. Of course, for general Internet use, she has to still bring up her VPN connection so she can actually get to a DNS server.
I haven't yet tried disabling DNS caching yet, as I don't thing that would work, since the IP address of her Exchange server shouldn't even be cached yet. I can try it, though.
I'm not a Windows networking expert - I'm more of an infrastructure/routing/switching kinda guy, with some detailed Linux experience, but it's been years since I've dug into Windows internals.
It seems like a bug, since you'd think that Outlook is looking for the IP address of a connection-specific DNS host, and since the Verizon connection doesn't register her PC's domain name in DNS, when given a "hostname.workname.com" name to resolve, it would first check the DNS servers defined on the connection with that same "workname.com" defined - in her case, the Sonicwall VPN connection...
Any ideas for a permanent fix?