?
Solved

Trouble Shooting TCP/IP Across the Internet

Posted on 2012-08-29
8
Medium Priority
?
606 Views
Last Modified: 2012-08-29
I'm trying to connect to an exchange server in a remote location. From my local PC I'm unsuccessful but everything is fine when trying from another, remote, PC. I have established it's a TCP/IP issue and I reckon it's an ISP issue but my ISP is denying so.

Running a tracert from the local and remote PCs I get two different results. As you can see the remote PC is not using the same ISP as my local one.

tracert exchange.outitgoes.com

Tracing route to exchange.outitgoes.com [79.170.40.198]
over a maximum of 30 hops:
 1    10 ms    10 ms    15 ms  cpc6-stav13-2-0-gw.aztw.cable.virginmedia.com [xx.xxx.xxx.x]
 2    29 ms    14 ms    15 ms  aztw-core-2b-ae7-714.network.virginmedia.net [80.1.243.213]
 3    22 ms    15 ms    15 ms  brhm-bb-1b-ae4-0.network.virginmedia.net [80.1.240.177]
 4    18 ms    18 ms    19 ms  nrth-bb-1a-as4-0.network.virginmedia.net [62.253.185.105]
 5    26 ms    27 ms    15 ms  glfd-bb-1b-as2-0.network.virginmedia.net [212.43.163.181]
 6    33 ms    18 ms    19 ms  glfd-tmr-1-ae5-0.network.virginmedia.net [213.105.159.46]
 7    21 ms    18 ms    19 ms  tcl5-ic-1-as0-0.network.virginmedia.net [62.253.185.78]
 8    27 ms    18 ms    22 ms  ge-0-1.linx.lon.nodefour.net [195.66.224.135]
 9    21 ms    27 ms    19 ms  83.166.164.85
10    18 ms    23 ms    19 ms  mx01-xe2.0.0-lon.gs.nodefour.net [83.166.164.34]
11    29 ms    23 ms    25 ms  mx02-xe1.2.0-dry.dc2.nodefour.net [83.166.164.38]
12    29 ms    30 ms    23 ms  83.166.164.54
13    exchange.outitgoes.com [79.170.40.198]  reports: Destination protocol unreachable.

Trace complete.

Remote PC:-

tracert exchange.outitgoes.com

Tracing route to exchange.outitgoes.com [79.170.40.198]
over a maximum of 30 hops:

 1     3 ms     1 ms     2 ms  xxx.xx.xxx.x
 2    14 ms    <1 ms    <1 ms  gi1-7.cr1-sdn.uk.6dg.co.uk [217.10.157.25]
 3     8 ms     8 ms     8 ms  vl8-te2-1.cr1-the.uk.6dg.co.uk [217.10.157.146]
 4     8 ms     8 ms     8 ms  te2-2.cr1-sov.uk.6dg.co.uk [217.10.157.137]
 5     8 ms     8 ms     8 ms  ge-0-1.linx.lon.nodefour.net [195.66.224.135]
 6    25 ms     8 ms     8 ms  83.166.164.85
 7    10 ms     8 ms     8 ms  mx01-xe2.0.0-lon.gs.nodefour.net [83.166.164.34]
 8    11 ms    11 ms    11 ms  mx02-xe1.2.0-dry.dc2.nodefour.net [83.166.164.38]
 9    12 ms    17 ms    12 ms  83.166.164.54
10    11 ms    11 ms    11 ms  exchange.outitgoes.com [79.170.40.198]

Trace complete.

Open in new window


Can anyone help by suggesting any tests/steps I could take to establish exactly what the problem is as I'm at the edge of my skill in this area.
0
Comment
Question by:cescentman
  • 4
  • 3
8 Comments
 
LVL 26

Expert Comment

by:pony10us
ID: 38347656
Both PC's are arriving at:  83.166.164.54 through the tracert. This would indicate that it is the stopping point.  Is this a router/switch that the exchange server is connected to? If so then I would look at the ACL's on it if you have access.
0
 
LVL 1

Author Comment

by:cescentman
ID: 38347684
Thanks for responding so quickly.

I don't have any access to 83.166.164.54 it is as you say a router/switch at the exchange end. Support at that facility are saying that this is not a problem of theirs as the device is returning a response to the remote PC. They say that this is an ISP issue blocking the response from 83.166.164.54 to the local PC.

ISP say this is not true that this is a problem with 83.166.164.54. Tearing my hair out or what :>( I just have no idea of how to break the deadlock.
0
 
LVL 26

Expert Comment

by:pony10us
ID: 38347777
Destination protocol unreachable - this means the host responding doesn't know how to get to the destination IP address in the traceroute packets. This would indicate it is the router. Also, the ISP should not be a factor because it makes it all the way to the destination and just can't make the final hop.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
LVL 1

Author Comment

by:cescentman
ID: 38347852
But why is the host 83.166.164.54 able to get to the destination address in one case and not the other?
0
 
LVL 26

Accepted Solution

by:
pony10us earned 2000 total points
ID: 38347880
I would say there is an ACL in place on the router.

Example:

access-list 102 permit ip 10.1.1.0 0.0.0.255 79.170.40.198 0.0.0.255
access-list 102 deny ip any any


Where

10.1.1.0 = PC #2

This would prevent anyone else access
0
 
LVL 1

Author Comment

by:cescentman
ID: 38347924
OK thanks, strange thing is that this was working earlier today. I guess there's no way of progressing this more?
0
 
LVL 26

Expert Comment

by:pony10us
ID: 38347942
That fact that it was working earlier could indicate that your home PC may have changed it's IP address through your ISP.  The new IP address is not allowed.
0
 
LVL 3

Expert Comment

by:mtsdemo
ID: 38348162
I can access outlook owa from that url.
0

Featured Post

Fill in the form and get your FREE NFR key NOW!

Veeam is happy to provide a FREE NFR server license to certified engineers, trainers, and bloggers.  It allows for the non‑production use of Veeam Agent for Microsoft Windows. This license is valid for five workstations and two servers.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article explains the fundamentals of industrial networking which ultimately is the backbone network which is providing communications for process devices like robots and other not so interesting stuff.
This article will show how Aten was able to supply easy management and control for Artear's video walls and wide range display configurations of their newsroom.
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
Monitoring a network: how to monitor network services and why? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the philosophy behind service monitoring and why a handshake validation is critical in network monitoring. Software utilized …

862 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