Tracetcp reaches host but does not complete

[Sonu Upadhyay]

Hi,

Hope someone can help here, i have a weird issue wherein trace to a destination host on port1494 goes all the way to the destination but does not complete, could someone help me answer what the issue may be:-

C:\>tracetcp 10.249.59.74:1494

Tracing route to 10.249.59.74 on port 1494
Over a maximum of 30 hops.
1       2 ms    1 ms    1 ms    10.204.141.2
2       3 ms    1 ms    1 ms    10.204.144.35
3       162 ms  161 ms  161 ms  10.250.0.109
4       163 ms  163 ms  165 ms  10.249.59.74
5       168 ms  165 ms  167 ms  10.249.59.74
6       *       *       *       Request timed out.
7       *       *       *       Request timed out.
8       *       *       *       Request timed out.
9       *       *       *       Request timed out.
10      *       *       *       Request timed out.
11      *       *       *       Request timed out.
12      *       *       *       Request timed out.
13      *       *       *       Request timed out.
14      *       *       *       Request timed out.
15      *       *       *       Request timed out.
16      *       *       *       Request timed out.
17      *       *       *       Request timed out.
18      *       *       *       Request timed out.
19      *       *       *       Request timed out.
20      *       *       *       Request timed out.
21      *       *       *       Request timed out.
22      *       *       *       Request timed out.
23      *       *       *       Request timed out.
24      *       *       *       Request timed out.
25      *       *       *       Request timed out.
26      *       *       *       Request timed out.
27      *       *       *       Request timed out.
28      *       *       *       Request timed out.
29      *       *       *       Request timed out.
30      *       *       *       Request timed out.
Trace Complete.

[johnlloyd_13]

Hi,

The port is blocked. Check for ACL or FW rule on host 10.249.59.74.

Sent from Cisco Technical Support iPad App

[Sonu Upadhyay]

Just to give a bit of overview of it, this server (10.249.59.74) is physically located in UK and i am sitting in india, a leased line terminating on a checkpoint fw provides this connectivity.  I've checked logs on the fw and traffic is going through it fine as per rules defined in the fw.

I wish the above answer was correct but from another location here, trace completes on the same port, it doesn't work from where i am, do you think it'd be worth checking server's routing table to see if the server has a back route, any other thoughts on this would also be highly appreciated.

C:\>tracetcp.exe 10.249.59.74:1494 -n

Tracing route to 10.249.59.74 on port 1494

Over a maximum of 30 hops.

1       1 ms    1 ms    1 ms    10.209.225.130

2       2 ms    2 ms    9 ms    10.209.199.3

3       347 ms  170 ms  170 ms  10.137.132.110

4       171 ms  184 ms  170 ms  10.249.59.74

5       173 ms  175 ms  198 ms  10.249.59.74

6       *       *       *       Request timed out.

7       *       *       *       Request timed out.

8       *       *       *       Request timed out.

9       *       *       *       Request timed out.

10      *       *       *       Request timed out.

11      *       *       *       Request timed out.

12      Destination Reached in 184 ms. Connection established to 10.249.59.74

Trace Complete.

[Richard Burts]

From the fact that in the original post there is a response from 10.249.59.74 I believe that we can deduce that the request packets are getting through the firewall and to the server. So it is not a routing or IP connectivity issue. From the fact that tracetcp continues to send requests up to 30 hops I believe that we can deduce that the TCP ACK response from the server does not get back to the requestor in the original post. From the fact that the server does send the TCP ACK in the follow up post I believe that we can deduce that the server does not have any policy that prevents the appropriate reply. And I note that the tracetcp that does work does not appear to go through this firewall.

If we believe that the original requester is sending the trace packets, that the trace packets do arrive at the server, that the server is generating the correct response, and that the trace response does not get back to the original requestor, then I believe that this points to something in the firewall interfering with the response packets.

I believe that you checked the firewall rules and see that the request is permitted and the logs show this. But did you also check the firewall rules and logs to see if response packets are permitted and if the response if observed at the firewall?

HTH

Rick

[Sonu Upadhyay]

Thanks for your response  Richard, i really appreciate your time here.

Both the traces go via the same firewall, i've got access to the firewall and i can see request from both the sources getting through the firewall in log.

Rule is there to allow reverse traffic but we can eliminate that fact because the return traffic would pass via connections table (statefull table) in the firewall so what i am assuming is that reverse traffic is unable to get to the firewall, there is no way i can check the reverse traffic coz i haven't got access to the command line and can't check tcp dumps have only got access to GUI.  Another thing, firewall has this server natt'd to another private address but that looks fine, can't see any as far as natting goes.