Solved

Outlook not connecting through VPN

Posted on 2008-06-24
42
1,416 Views
Last Modified: 2013-11-16
We have several remote workers who connect to our site through a PPTP VPN which terminates on a firebox. They then connect to out exchange server. however today there is an issue where none of the remote workers are able to use outlook. when the load it it says requesting data from the server.

I am able to ping the server, telnet on the server but not able to connect using outlook. I have deleted the profile and re created it but the name does not resolve. There are no problems internally as everyone else is fine. just externally. Nothing has changed in our system.  

also the users are not able to use OWA through the VPN by typing the server IP.  
0
Comment
Question by:HousingSolutions
  • 21
  • 19
  • 2
42 Comments
 
LVL 10

Expert Comment

by:uid94130
Comment Utility
Connect to a client that has this issue and check with TCPView from sysinternals.com to see which connections are blocked.

Seems there are some connections blocked between the clients and the server.
0
 
LVL 10

Expert Comment

by:uid94130
Comment Utility
If you can't connect to an affected client, ask one of the users (that has a bit more IT knowledge) to perform the checks locally while starting the Outlook client and report the SYN_SENT marked connections.
0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
So, when connected via the VPN, you indicate that you are unable to resolve the name of the server?  Where exactly are you attempting the resolve, and are you talking about the name of the server or the name of the user?

Before getting into the mail profile configuration, verify that you can resolve the server's name to an IP address.  You mentioned that you can PING the server, are you pinging by name or by direct IP address?  You'll need to be able to PING by the name if you're using a NAME within a mail profile.

If you cannot ping by name, you'll want to provide a method of name resolution.  When the PPTP client connects, are they getting a good DNS server entry for that connection?  Usually, you'll want to make sure the client can use a fully qualified DNS name, something like exchangeserver.internaldomain.local or exchangeserver.corp.mydomain.com.  For quick testing to determine name resolution, you could manually enter, on one of your remote test systems, a HOSTS file with the name to IP and also, an LMHOSTS file with the netbios name to IP entries.  While the HOSTS/LMHOSTS aren't typically what you want to do for all your remote users, this is just a quick and dirty test.  If using the HOSTS/LMHOSTS works, you'll have to decide if maybe you will simply distribute hosts/lmhosts to the PCs, or if you want to properly fix up a resolution method for your VPN users.  While hosts/lmhosts isn't ideal, and often recommended against, sometimes, it's the quick way to a solution that ISN"T SOOO bad...

I believe the Outlook client with MAPI uses an RPC connection to reach the exchange server.  You should be able to RPCPING (resource kit or support tool tool) the exchange server.  If you cannot, and you do have name resolution ability, perhaps you're not passing RPC protocol through that VPN connection.  The RPC Endpoint mapper is sitting at port 135.  You could use PORTQRY (from Microsoft) to 'scan' for RPC connectivity too.  I think it'd be :  "Portqry -n servername(or IP) -e 135 -p both"   (this would check a host at the IP, selecting port 135 and using both TCP and UDP.) Portqry has a few native dissectors that will interpret a few different protocols, including RPC.

If you cannot pass RPC over the VPN, you'll want to check on the firebox to see if there are rules preventing RPC, or maybe you have to specifically enable RPC.
Bob in the Noc
0
 

Author Comment

by:HousingSolutions
Comment Utility
Please see below the output from TCPView.


OUTLOOK.EXE:516      TCP      a000220:1529      a000220:0      LISTENING      
OUTLOOK.EXE:516      TCP      a000220.mdha.local:1529      mdha01:1026      ESTABLISHED      
OUTLOOK.EXE:516      TCP      a000220:1530      a000220:0      LISTENING      
OUTLOOK.EXE:516      TCP      a000220.mdha.local:1530      mdha01:1026      ESTABLISHED
0
 

Author Comment

by:HousingSolutions
Comment Utility
I can ping both hostname of the server and IP address. It resolves the hostname to the IP no problems.  so i know DNS resolution is ok.
0
 

Author Comment

by:HousingSolutions
Comment Utility
The thing that is puzzling me is nothing has changed on our system but yet 10 remote workers are unable to connect to exchange. we has a new firebox put in 4 weeks ago and everything has been working fine since then. We had a company come in and change all the settings over from the old box.
0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
Is this correct:

the client is named a000220, with a dns suffix of mdha.local
the server is mdha01

This looks like a MS-DS connection, to a netbios named mdha01, which suggests that you've got some connectivity.  What does the mdha01 resolve to?  Can we verify that mdha01 resolves to the IP address of the server?
In your mail profile, are you specifying the name of mdha01 only or mdha01.mdha.local?

0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
FYI, the name mdha01 only suggests that it's a netbios resolution, not necessarily a DNS resolution.

I'm checking a connection set on another server and client right now to verify the port connectivity.  On my main rig, I'm running RPC over HTTP without the need for a VPN client--which is something I might suggest you also consider doing if you don't need VPN for other functions.  RPC over HTTP certainly has made my life easier in not having to support VPNs for our users anymore ;)

0
 

Author Comment

by:HousingSolutions
Comment Utility
That is correct the client is named a000220 and yes when i do a ping it resolves the FQDN

mdha01 is the hostname of the exchange server.

Pinging mdha01.mdha.local [192.9.100.100] with 32 bytes of data:

Reply from 192.9.100.100: bytes=32 time=80ms TTL=127
Reply from 192.9.100.100: bytes=32 time=90ms TTL=127
Reply from 192.9.100.100: bytes=32 time=81ms TTL=127
Reply from 192.9.100.100: bytes=32 time=80ms TTL=127



0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
Over a typical LAN connection, I'm watching an outlook client connect to an exchange server, on the same subnet, and RPC is definitely in play, over port 135 (endpoint mapper).  The connections I show:
OUTLOOK.EXE:11808 TCP hc-ts01.hc.in:1097 hc-exch.hc.in:1227      ESTABLISHED      
OUTLOOK.EXE:11808 TCP hc-ts01.hc.in:1091 hc-fp01.hc.in:1025      ESTABLISHED      
OUTLOOK.EXE:11808 UDP hc-ts01:1093 *:*            
OUTLOOK.EXE:19056 TCP hc-ts01.hc.in:2748 hc-exch.hc.in:1227      ESTABLISHED      
OUTLOOK.EXE:19056 TCP hc-ts01.hc.in:2657 hc-fp01.hc.in:1025      ESTABLISHED      
OUTLOOK.EXE:19056 UDP hc-ts01:2659 *:*            

This is a successful connection, actively connected.
0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
Oh, btw, the initial RPC EPMAP connection dropped after I established the connection.  I'm assuming that the succeeding connection, to port 1025 is the RPC connection.

I'm a little fuzzy on the 1026, I know I see it all the time, but not, at the moment positive of it's nature.
0
 

Author Comment

by:HousingSolutions
Comment Utility
So where it says listening on the tcp view output it should say established.
0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
Do you have RPCPING or Portqry? Definitely check to verify that you can connect to the endpoint RPC mapper of the exchange server.  I'm watching  1/2 dozen different users connecting, and they all start out with the port 135 epmap connection then move to the 1025 port.
0
 

Author Comment

by:HousingSolutions
Comment Utility
should i install this on the server or on the client?
0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
On the client, you'll run them from the client to see if you can reach the server.
0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
do you have them handily available?  If not, I can send them your way:
rpctools.zip
0
 

Author Comment

by:HousingSolutions
Comment Utility
well i downloaded it from the Windows Server 2003 Resource Kit Tools webpage and installed it on my machine just to test before i copy it over to the client machine but am a bit stuck on the commands i need to run as on http://support.microsoft.com/kb/167260 it shows a server side and client side.
0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
for portqry:

portqry -n mdha01 -e 135 -p both
portqry -n mhda01 -e 1026 -p both
portqry -n mhda01 -e 1025 -p both

for RPCPING
rpcping -s mdha01 -v 3 -e 135
with -e 1025
then -e 1026

0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
I've not used RPCPing too much, and haven't tried the server side piece, rather, I just use it to validate that RPC communications works at all.  That article does look like it's got good info for specific Exchange to Client tests, although I've not ever done it that way.

At this point, we're just verifying that RPC is even functional.
0
 

Author Comment

by:HousingSolutions
Comment Utility
please see error generated.

I renamed the files with a .exe extension copied them to the client and typed in the location of the folder ie. c: then fillowed the rpcping command you posted. what have i missed. im not fantastic in dos but i must have missed something.
capture5.jpg
0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
Hmmmm.....  It'd appear that remote procedure calls, if I'm not mistaken, are not fully available on that system.  Can you verify that the Remote Procedure Call service is running on your system.  Services.msc
0
The curse of the end user strikes again      

You’ve updated all your end user’s email signatures. Hooray! But guess what? They’re playing around with the HTML, adding stupid taglines and ruining the imagery. Find out how you can save your signatures from end users today.

 
LVL 7

Accepted Solution

by:
BobintheNoc earned 500 total points
Comment Utility
Here's an informative MS KB article, http://support.microsoft.com/kb/325930/en-us
describing errors or corruption in RPC on a client, especially in relation to Outlook-Exchange connectivity.   I'm pretty positive that the problems you're having stem from RPC failure, not necessarily that the vpn is not passing rpc, but perhaps, for who knows why yet, these particular clients can excecute RPC properly.

0
 

Author Comment

by:HousingSolutions
Comment Utility
ok finally

C:\TcpView>portqry -n mdha01 -e 1026 -p both

Querying target system called:

 mdha01

Attempting to resolve name to IP address...

Name resolved to 192.9.100.100


TCP port 1026 (unknown service): LISTENING

UDP port 1026 (unknown service): NOT LISTENING

-----------------------------------------------------------------------------------------
C:\TcpView>portqry -n mdha01 -e 1026 -p both

Querying target system called:

 mdha01

Attempting to resolve name to IP address...

Name resolved to 192.9.100.100


TCP port 1026 (unknown service): LISTENING

UDP port 1026 (unknown service): NOT LISTENING
0
 

Author Comment

by:HousingSolutions
Comment Utility
sorry second one was incorrect.

C:\TcpView>portqry -n mdha01 -e 1025 -p both

Querying target system called:

 mdha01

Attempting to resolve name to IP address...

Name resolved to 192.9.100.100


TCP port 1025 (unknown service): NOT LISTENING

UDP port 1025 (unknown service): NOT LISTENING
0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
and port 135?
So far, looks like either RPC is hosed on the client, or that the vpn IS dropping RPC.
0
 

Author Comment

by:HousingSolutions
Comment Utility
The RPC service is started on the client.

Would you put this down to an exchange related issue?
0
 

Author Comment

by:HousingSolutions
Comment Utility
sorry i meant that the server is just not reponding to rpc requests from remote users.
0
 
LVL 7

Assisted Solution

by:BobintheNoc
BobintheNoc earned 500 total points
Comment Utility
If you've got local LAN clients that can connect to the Exchange server without trouble, then I'd offer that Exchange is not likely the culprit.

If it's ONLY the VPN clients then, and you can confirm that their RPC configs are OK, it'd certainly all point to the VPN connection not passing it.

If RPC were down on the exchange server, it'd be pretty obvious--especially if you're users are like most users :)  That helpdesk phone would look like a Christmas tree.

0
 

Author Comment

by:HousingSolutions
Comment Utility
output from 135 was large so have posted as a text file.
output3.txt
0
 

Author Comment

by:HousingSolutions
Comment Utility
LOL.

ok so can we say that it is a connectivity issue with the vpn not passing RPC.
0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
To confirm that the client is pushing RPC packets out, as suggested back at the top, look for SYN_SENT without acknowledgements from TCPVIEW.  Personally, I'd use a packet capture tool, Wireshark or Netmon to view the traffic, but TCPView should do the simple trick too.

If the client intiates and sends the SYN packet and you don't see the ACK packets coming back, that'd be strong indication that the SYN isn't making it to the destination, either because of a firewalling function in the Firebox (or in general, whatever network device/medium that's being used)

If you've got to prove this to a set of attorneys, do the full bit and validate the RPC functionality, otherwise, if it's a reasonable network person, they should see the simple logic tests of portqry/tcpview as valid enough to warrant further investigation.

If you've got access to the Firebox,  (I'm not familiar with this device), find a way to log the traffic, and I'd bet heavily that it's dropping the RPC packets.  RPC is potentially a large vulnerability in many people's minds, and NOT uncommon to TRY to block.  Eventually, though, those who try to block it, usually turn it back on when they have had enough of things not working.  MS is heavy into RPC.
0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
Another long pause and a Hmmmm..  That output for 135 looks good.    That's what you'd expect to see from an exchange server, and that if you got any epmaps at all, it'd suggest that at least on 135, epmap/RPC is working.  Could be a problem with the way UDP works, being connectionless, that's fouling the firebox--  since it's sessionless, you frequently need a 'fixup' that knows how that particular UDP conversation works--starting with the initial connection then the somewhat unrelated jump to another session.    Unlike a TCP connection, you can't simply rely on following a packet sequence from one packet to the next--there's little way for anything to know where a UDP stream will pick up again unless there's specific code that's familiar with specific UDP conversations.  Does that make sense?  
0
 

Author Comment

by:HousingSolutions
Comment Utility
It sort of does. we also tested this with a 3g card on a laptop and had the same result.

were just bouncing the firebox and will check the result shortly.
0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
Run through the kb article http://support.microsoft.com/kb/325930/en-us and also back it up with a packet capture or tcpview to see if SYNs are going unack'd.  
0
 
LVL 7

Assisted Solution

by:BobintheNoc
BobintheNoc earned 500 total points
Comment Utility
For the record, I have been seeing ALOT of remotely connected problems with Outlook lately (for the past 2-3 weeks) and we've not been able to fully identify the source (nor has Microsoft when we've called it in to Product Support Services (My group is a MS Gold Partner member))

Not saying that this is the same issue, but I'm having fits with Outlook connectivity in many locations, as well as some of our other engineers---and we're pretty stong on our Outlook-->exchange and general networking---we've all been pulling our hair out.  Some of us are thinking we've got some sort of infection lurking that we've not detected yet---just really wierd.  It's not often that we can't quickly identify a culprit, but I've got 6 high end engineers who are having troubles as if we were receptionists somewhere, and we haven't had luck at finding empirical evidence to hand to MS.  Maybe we just need a vacation :)
0
 

Author Comment

by:HousingSolutions
Comment Utility
ok, restarting the firewall was no help.  After looking in the log i have found this deny request in it.

2008-06-24 14:54:10 Deny 192.9.100.33 255.255.255.255 netbios-ns/udp 137 137 PPTP Firebox denied 78 128 (Unhandled External Packet-00)  src_user="vpnuser13@Firebox-DB" rc="101"       Traffic

any ideas if this could be the problem?
0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
That's a full broadcast packet, likely the pc telling everyone else that it's alive and on the network.  Routers typically won't pass that one anyways.  Not the magic bullet.  Is that the only one?
0
 

Author Comment

by:HousingSolutions
Comment Utility
i was only given an hour of logs and they dont have a great deal of the remote users entries. my last thought was to reboot the server.
0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
Restarting server is always an option, however not much to suggest that it'll help.  Are you able to remotely control one of the pcs while it's connected into the VPN?  As in, can you install and run a capture or watch a live TCPVIEW session to see if packets are making their way?

Are any of these PCs Laptops?  If so, what happens, if possible, when you place one of them inside the main network, with a direct lan connection---do they work?
0
 

Author Comment

by:HousingSolutions
Comment Utility
Ok the server restart worked. I have had one headbashing day. but thanks for all your help. you guys are a great support.
0
 
LVL 7

Expert Comment

by:BobintheNoc
Comment Utility
Doh!!!
0
 

Author Closing Comment

by:HousingSolutions
Comment Utility
Thank you very much for your help having you guys makes up for the lack of a supporting team.
0

Featured Post

What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

Join & Write a Comment

I recently attended Cisco Live! in Las Vegas, a conference that boasted over 28,000 techies in attendance, and a week of hands-on learning hosted by a solid partner with which Concerto goes to market.  Every year, Cisco displays cutting-edge technol…
This article explains in simple steps how to renew expiring Exchange Server Internal Transport Certificate.
The basic steps you have just learned will be implemented in this video. The basic steps are shown to configure an Exchange DAG in a live working Exchange Server Environment and manage the same (Exchange Server 2010 Software is used in a Windows Ser…
how to add IIS SMTP to handle application/Scanner relays into office 365.

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now