Traceroute shows traffic stops at 66.185.29.250

I have a client using the AT&T network at three locations but a trace route shows no calls are coming in to our server, or from our end at 66.185.27.147 because as the trace route logs shows, as the leave their network and enters freepbx network, traffic halts. See following log:
1 12.33.62.81 1 msec 1 msec 1 msec
2 12.244.125.89 3 msec 3 msec 3 msec
3 12.122.99.94 8 msec 9 msec
12.122.99.102 4 msec
4 12.122.99.97 3 msec 3 msec
12.122.133.193 3 msec
5 12.246.90.174 5 msec 5 msec 5 msec
6 66.185.29.250 5 msec 5 msec 5 msec
7 * * *
8 * * *
9 * * *

Any idea how to proceed? I am thinking that the issue is in 66.185.29.250. Special not for the readers, 66.185.27.147 firewall already has the originating IP in the safe list so there is no reason for the connection not to be established other than the fault to reside solely at the 66.185.29.250 location.
This is our only incident while all other connections work just fine.

It’s not unusual for intermediate hosts to not respond to ICMP messages. Sub-optimal, to be sure, but not unusual.

Agreed. Here, in my situation, there is no end to end communication because the route stops at the 66.185.29.250 - there is no audio nor video feeds passing through. Not even a handshake that comes up on our log. I wonder if this box let traffic through at all, or if the firewall on that box is the issue, or else.
But there is no traffic coming or going through this IP address

Can you get through to any other ports on the remote server?

The issue I’m trying to get past is that ICMP is a different protocol than UDP, so the fact that one, the other, or both are getting blocked along the line somewhere is really hard to identify, especially on the UDP side.

Can you tcpdump the traffic at both ends and see if any traffic from one server to the other is making it through?

I am having that checked and will report back when confirmed. Stay tuned. Thanks for the input!

One other piece to keep in mind is that, as we use it, the SIP protocol uses a TON of addresses (typ. 5060, 10000-20000), so if AT&T is being “not cool”, they could be blocking port 5060 and it would make it appear that none of your SIP traffic is getting through (since the RTP stuff relies on the rest of the SIP protocol stuff to work).

If one port (like 5060) isn’t working but other are, we know how to fix that.

Voip doesnt use ICMP , try

netcat -zvu  66.185.27.147 5060  
netcat -zvu  66.185.27.147 5160 

(or whatever port/protocol you are useing)

1 Like

I’ll have them try netcat -zvu 66.185.27.147 5060
this is the port we use. I will report back the results.

As I wait the results from the affected locations, the following are the result from my location:

[email protected] ~
$ nc -z -v -u 66.185.27.147 5060
Connection to 66.185.27.147 5060 port [udp/*] succeeded!

[email protected] ~
$ nc -z -v -u 66.185.29.250 5060
Connection to 66.185.29.250 5060 port [udp/*] succeeded!

66.185.29.250 is Cyberlynk itself so will be open , You apparently 66.185.27.147 are open for SIP connections (and a lot of other ones like your user control panel ,TLS,xmpp (zulu?), Cyberlynk is not allowing tracing its route to you (no ping/ICMP being passed) but you should be good to go when you fix the voip disconnect with them

1 Like

Here is what has been reported from the netcat test:


I couldn’t paste the result so I turned it into a pix. I guess I am too new to the system… :slight_smile:

so , your good to go network wise, check with the provider how to set up your trunk .

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.