[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 792
  • Last Modified:

Outlook on remote clients cannot connect to Exchange Server over VPN

We've been using Outlook 2003 to access our corp Exchange server over a VPN for years. Yesterday, all of our remote clients began having the same problem: On starting Outlook it takes a LONG time before the program splash screen goes away, then they get the message in the lower right status bar area: Trying to connect... and it never does.

The Exchange Server is fine and so are the email accounts. I know this because I can remote desktop into my office PC, start the same version of Outlook on that PC and it all works fine. No one on the internal LAN is having any trouble. I can also ping the Exchange Server over the VPN by its network name and it resolves to its IP address and responds just fine. When I thought this was simply a one-client problem, I recreated my Outlook profile because I know these get corrupted from time to time but that didn't fix it of course. I also tried an Office repair using the installer and that didn't help either.

More about our configuration: We have a single domain in a small office environment running a single Windows 2003 Server. This same server is also the domain controller, Exchange Server, and remote access server. The office LAN is connected to the Internet over a DSL Router, which has the appropriate service pass throughs to allow the VPNs to connect to the remote access server. The ISP for the office and for all remote clients is ATT, but in totally different geographical locations. I have tried swapping the DSL Router (we have two spares configured and ready to go), but that had no effect on the problem. Ideas???
0
tcianflone
Asked:
tcianflone
  • 11
  • 10
1 Solution
 
tcianfloneAuthor Commented:
Also want to add that NEITHER the server NOR the clients are set to install MS updates automatically, so I'm doubtful it's the result of an update of that sort.
0
 
Antonio VargasMicrosoft Senior Cloud ConsultantCommented:
does it ping by netbios and dns names? ping servername and ping servername.domainame.local and report the result.

regards
António Vargas
0
 
tcianfloneAuthor Commented:
Ping results below. The ping results to VSDC06 are expected, returning the IP address of that server on over the VPN. The ping results to VSDC06.vsoffice.com are NOT expected. I have NO idea where the 216.36.248.128 comes from and it is not at all familiar to me.
D:\Documents and Settings\tomc>ping vsdc06
Pinging vsdc06 [192.168.1.17] with 32 bytes of data:
Reply from 192.168.1.17: bytes=32 time=60ms TTL=128
Reply from 192.168.1.17: bytes=32 time=59ms TTL=128
Reply from 192.168.1.17: bytes=32 time=60ms TTL=128
Reply from 192.168.1.17: bytes=32 time=60ms TTL=128
 
Ping statistics for 192.168.1.17:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 59ms, Maximum = 60ms, Average = 59ms
 
D:\Documents and Settings\tomc>ping vsdc06.vsoffice.com
Pinging vsdc06.vsoffice.com [216.36.248.128] with 32 bytes of data:
Reply from 216.36.248.128: bytes=32 time=56ms TTL=54
Reply from 216.36.248.128: bytes=32 time=57ms TTL=54
Reply from 216.36.248.128: bytes=32 time=57ms TTL=54
Reply from 216.36.248.128: bytes=32 time=56ms TTL=54
 
Ping statistics for 216.36.248.128:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 56ms, Maximum = 57ms, Average = 56ms
 
D:\Documents and Settings\tomc>

Open in new window

0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
Antonio VargasMicrosoft Senior Cloud ConsultantCommented:
Problem identified. The fully qualified domain name of the server is returning one external ip address. Check what dns server you use when connected by VPN (i assume that those pings were made by vpn). If your using your dns server (expected) go to the dns server console and check the entry for the server name. change the ip address of that entry to the internal ip address, do one ipconfig /flushdns (even if the entry was correct, always do this step) and then try to ping the server by fqdn again.

hope it helps
0
 
tcianfloneAuthor Commented:
See attached PIX of our DNS manager. The IP address for vsdc06 appears to be correct. I did a flush dns on both the server and my client and no joy. What next?
dns.JPG
0
 
Antonio VargasMicrosoft Senior Cloud ConsultantCommented:
you need to check the host(A) entry. if you dont have one, create it. also be sure that the dns server used by vpn clients is that one. connect vpn and do ipconfig /all to check.

hope it helps
0
 
tcianfloneAuthor Commented:
Here is the ipconfig /all from my client connect via VPN. The DNS server on the local LAN is the DSL router at 192.168.8.254. The DNS server on the PPP (vpn) adapter is 192.168.1.6, which is correct for the internal office DNS/Domain server. Is this OK? As for the host(A) entry, there are two, one pointing to 192.168.1.1 and that appears at the top of the list (see pix). Don't know why that's there; may have been an old secondary domain server in days gone by. The second host(A) entry is for the current DNS server at 192.168.1.6. That is there and looks correct. What next?
D:\Documents and Settings\tomc>ipconfig /all
Windows IP Configuration
        Host Name . . . . . . . . . . . . : lab1
        Primary Dns Suffix  . . . . . . . :
        Node Type . . . . . . . . . . . . : Hybrid
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No
Ethernet adapter VSFTL:
        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : 3Com 3C920 Integrated Fast Ethernet
Controller (3C905C-TX Compatible)
        Physical Address. . . . . . . . . : 00-06-5B-60-C8-C2
        Dhcp Enabled. . . . . . . . . . . : Yes
        Autoconfiguration Enabled . . . . : Yes
        IP Address. . . . . . . . . . . . : 192.168.8.2
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.8.254
        DHCP Server . . . . . . . . . . . : 192.168.8.254
        DNS Servers . . . . . . . . . . . : 192.168.8.254
        Lease Obtained. . . . . . . . . . : Thursday, October 16, 2008 11:02:54
AM
        Lease Expires . . . . . . . . . . : Thursday, October 16, 2008 12:02:54
PM
 
Ethernet adapter DELTA:
 
        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : IBM Netfinity 10/100 Ethernet Adapte
r
        Physical Address. . . . . . . . . : 00-04-AC-58-B3-9B
        Dhcp Enabled. . . . . . . . . . . : No
        IP Address. . . . . . . . . . . . : 192.168.254.254
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . :
 
PPP adapter VSKANSAS:
 
        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
        Physical Address. . . . . . . . . : 00-53-45-00-00-00
        Dhcp Enabled. . . . . . . . . . . : No
        IP Address. . . . . . . . . . . . : 192.168.1.15
        Subnet Mask . . . . . . . . . . . : 255.255.255.255
        Default Gateway . . . . . . . . . :
        DNS Servers . . . . . . . . . . . : 192.168.1.6
                                            192.168.1.6
        Primary WINS Server . . . . . . . : 192.168.1.6
        Secondary WINS Server . . . . . . : 192.168.1.6
 
D:\Documents and Settings\tomc>

Open in new window

0
 
Antonio VargasMicrosoft Senior Cloud ConsultantCommented:
Go to the server (i suppose that has rras configured). see whats the dns server configured in tpc properties in the server, ping by fqdn name the server itself. do this by rdp. tell me the result. the dns server internalty should also be the server and not the router but i dont think the the cause is that. the problem is on the dns server in the box and not in the router.
show results
0
 
tcianfloneAuthor Commented:
TCP properties of the server show the DNS server to be itself: 192.168.1.6. Ping of fqdn at the server remoted in from RDP:

C:\Documents and Settings\Administrator.VSOFFICE>ping vsdc06.vsoffice.com
Pinging vsdc06.vsoffice.com [192.168.1.6] with 32 bytes of data:
Reply from 192.168.1.6: bytes=32 time<1ms TTL=128
Reply from 192.168.1.6: bytes=32 time<1ms TTL=128
Reply from 192.168.1.6: bytes=32 time<1ms TTL=128
Reply from 192.168.1.6: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.6:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
0
 
Antonio VargasMicrosoft Senior Cloud ConsultantCommented:
this is very strange. what vpn server do you have?
let's try something. on the vpn client edit the hosts file in c:\windows\system32\drivers\etc folder and put an entry with the fqdn and ip of your server. do a flushdns and ping by name after that. if it returns the correct ip test outlook. just want to make sure that this is a dns server issue.
also consult this host file in the server and see if there is an entry equal to the one you are going to create there.
is strange because everything points to be a dns server problem but the server itself is using this dns and it's pinging ok.
report the result
0
 
tcianfloneAuthor Commented:
About the etc\hosts file, I decided to try that for myself just before I saw your post here and putting the appropriate entries in there cures the problem, which is to say, that now when I ping vsdc06.vsoffice.com, I get the IP address I edited into the etc\hosts file. So, yes, that works. The etc\hosts file on the server has just the default loopback entry in it; nothing else. The VPN Server we use is Windows 2003 Server remote access.

One question: The VPN connectoid, in the TCP/IP properties, Advanced, I have it set NOT to use the default gateway on the remote network, which is how all of our clients have always been set up. Does this have anything to do with it? Thanks for hanging with me on this issue.
0
 
tcianfloneAuthor Commented:
A tech acquaintance of mine has suggested renaming the office domain to vsoffice.local so that it never resolves to a public IP address. What do you think of that? I'm betting that could turn into a nightmare of its own.
0
 
Antonio VargasMicrosoft Senior Cloud ConsultantCommented:
If you set to use the default gateway on the remote network, all your traffic when vpn is connected will go trough your company router and not trough your house router for example. It's more secure to use the remote default gateway but i dont see how can this be causing the problem. anyway you can set this and test. be aware that using that option you cannot be for example working trough vpn and using a peer to peer download software. i know that this is not a proper behaviour but you may have clients used to it.

regards
António Vargas
0
 
Antonio VargasMicrosoft Senior Cloud ConsultantCommented:
You cannot rename the domain. you have to create a new one. But yes. it's a very good idea. internal domains should always be local and never .com or whatever.
how many vpn clients do you have?
beeing a domain .com can be causing this. forcing with hosts file solves but can give lots of work
0
 
tcianfloneAuthor Commented:
OK, I tested that. No change. Should I just leave the etc\hosts with the hard coded addresses and leave it at that? We worked for years without having to do that. Seems like it should be able to work like that again...
0
 
Antonio VargasMicrosoft Senior Cloud ConsultantCommented:
yes, it should. something is very wrong when you solve names trough vpn. you are trying to solve a .com name and somehow the router in your house goes directly to the internet to solve that name. it only goes trough the vpn if you use gateway in destiny. disconect the vpn and try and ping the fqdn. it's a good test to do. but first flushdns
0
 
tcianfloneAuthor Commented:
We have only 3 remote clients, and they access one or two servers tops from the outside. So maintenance I don't think will be an issue. So I think for now we'll have to do that. Any idea why all of a sudden this is an issue where it has not been for the past few years? I set up that internal domain probably four years ago under a Win2000 Server topology, then migrated to Win2003 and AD in 2006 and it has never resolved to an outside address until yesterday. Very bizarre...
0
 
Antonio VargasMicrosoft Senior Cloud ConsultantCommented:
Yes.. very bizarre.. like i said try to ping the fqdn wih flushdns first and with vpn disconnected.. then send me the result.
0
 
tcianfloneAuthor Commented:
Here is the ping results with VPN disconnected. I had to use another server name because VSDC06 is being forced by etc\hosts, but the results are the same. Also, same results pinging just vsoffice.com. There in fact a domain for sale out there by that name with a placeholder web page on it.
D:\Documents and Settings\tomc>ping appsrv1.vsoffice.com
Pinging appsrv1.vsoffice.com [216.36.248.128] with 32 bytes of data:
Reply from 216.36.248.128: bytes=32 time=57ms TTL=54
Reply from 216.36.248.128: bytes=32 time=56ms TTL=54
Reply from 216.36.248.128: bytes=32 time=57ms TTL=54
Reply from 216.36.248.128: bytes=32 time=56ms TTL=54
 
Ping statistics for 216.36.248.128:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 56ms, Maximum = 57ms, Average = 56ms
 
D:\Documents and Settings\tomc>ping vsoffice.com
Pinging vsoffice.com [216.36.248.128] with 32 bytes of data:
Reply from 216.36.248.128: bytes=32 time=56ms TTL=54
Reply from 216.36.248.128: bytes=32 time=57ms TTL=54
Reply from 216.36.248.128: bytes=32 time=56ms TTL=54
Reply from 216.36.248.128: bytes=32 time=56ms TTL=54
 
Ping statistics for 216.36.248.128:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 56ms, Maximum = 57ms, Average = 56ms

Open in new window

0
 
Antonio VargasMicrosoft Senior Cloud ConsultantCommented:
that address is beeing routed trough the Internet. someone bought that domain name. your only option is to use the hosts file or only on the internal net will function. that's for sure the final veredict. by vpn the hosts file is the only option. locally there should be no problem unless you want to access some resource of the guy who bought the domain name.

best regards

António Vargas
0
 
tcianfloneAuthor Commented:
Very knowledgable and thorough responder. Thanks!
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 11
  • 10
Tackle projects and never again get stuck behind a technical roadblock.
Join Now