• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1464
  • Last Modified:

Outlook not connecting through VPN

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
HousingSolutions
Asked:
HousingSolutions
  • 21
  • 19
  • 2
3 Solutions
 
uid94130Commented:
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
 
uid94130Commented:
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
 
BobintheNocCommented:
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
 [eBook] Windows Nano Server

Download this FREE eBook and learn all you need to get started with Windows Nano Server, including deployment options, remote management
and troubleshooting tips and tricks

 
HousingSolutionsAuthor Commented:
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
 
HousingSolutionsAuthor Commented:
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
 
HousingSolutionsAuthor Commented:
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
 
BobintheNocCommented:
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
 
BobintheNocCommented:
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
 
HousingSolutionsAuthor Commented:
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
 
BobintheNocCommented:
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
 
BobintheNocCommented:
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
 
HousingSolutionsAuthor Commented:
So where it says listening on the tcp view output it should say established.
0
 
BobintheNocCommented:
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
 
HousingSolutionsAuthor Commented:
should i install this on the server or on the client?
0
 
BobintheNocCommented:
On the client, you'll run them from the client to see if you can reach the server.
0
 
BobintheNocCommented:
do you have them handily available?  If not, I can send them your way:
rpctools.zip
0
 
HousingSolutionsAuthor Commented:
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
 
BobintheNocCommented:
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
 
BobintheNocCommented:
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
 
HousingSolutionsAuthor Commented:
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
 
BobintheNocCommented:
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
 
BobintheNocCommented:
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
 
HousingSolutionsAuthor Commented:
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
 
HousingSolutionsAuthor Commented:
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
 
BobintheNocCommented:
and port 135?
So far, looks like either RPC is hosed on the client, or that the vpn IS dropping RPC.
0
 
HousingSolutionsAuthor Commented:
The RPC service is started on the client.

Would you put this down to an exchange related issue?
0
 
HousingSolutionsAuthor Commented:
sorry i meant that the server is just not reponding to rpc requests from remote users.
0
 
BobintheNocCommented:
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
 
HousingSolutionsAuthor Commented:
output from 135 was large so have posted as a text file.
output3.txt
0
 
HousingSolutionsAuthor Commented:
LOL.

ok so can we say that it is a connectivity issue with the vpn not passing RPC.
0
 
BobintheNocCommented:
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
 
BobintheNocCommented:
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
 
HousingSolutionsAuthor Commented:
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
 
BobintheNocCommented:
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
 
BobintheNocCommented:
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
 
HousingSolutionsAuthor Commented:
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
 
BobintheNocCommented:
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
 
HousingSolutionsAuthor Commented:
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
 
BobintheNocCommented:
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
 
HousingSolutionsAuthor Commented:
Ok the server restart worked. I have had one headbashing day. but thanks for all your help. you guys are a great support.
0
 
BobintheNocCommented:
Doh!!!
0
 
HousingSolutionsAuthor Commented:
Thank you very much for your help having you guys makes up for the lack of a supporting team.
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 21
  • 19
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now