Traceroute shows traffic stops at

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 because as the trace route logs shows, as the leave their network and enters freepbx network, traffic halts. See following log:
1 1 msec 1 msec 1 msec
2 3 msec 3 msec 3 msec
3 8 msec 9 msec 4 msec
4 3 msec 3 msec 3 msec
5 5 msec 5 msec 5 msec
6 5 msec 5 msec 5 msec
7 * * *
8 * * *
9 * * *

Any idea how to proceed? I am thinking that the issue is in Special not for the readers, 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 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 - 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 5060  
netcat -zvu 5160 

(or whatever port/protocol you are useing)

1 Like

I’ll have them try netcat -zvu 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 5060
Connection to 5060 port [udp/*] succeeded!

[email protected] ~
$ nc -z -v -u 5060
Connection to 5060 port [udp/*] succeeded! is Cyberlynk itself so will be open , You apparently 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.