Problems With Natted Phones

Home » Asterisk Users » Problems With Natted Phones
Asterisk Users 54 Comments

Hello,

I have an asterisk setup using pjsip. Everything used to work correctly until one remote site changed internet provider and thier router does not support sip protocol algorithms.

It works for some time, but then suddenly audio stops working both directions. When this happens I see RTP responses going out to the local address of the natted phone, not to the natted address. The problem appears for the phones independently.

The asterisk is connected to the internet with public static IP address.

The pjsip config contains:

[aor]
type=aor qualify_frequency = 60
max_contacts=1
remove_existing = yes

[endpoint]
type = endpoint context = internal dtmf_mode = rfc4733
disallow = all allow = alaw allow = ilbc allow = g729
allow = gsm allow = g723
direct_media = no allow_subscribe = yes subscribe_context = blf rewrite_contact = yes rtp_symmetric = yes force_rport = yes

Am I missing something? Why the communication breaks suddenly?

Thanks

Marek

—

54 thoughts on - Problems With Natted Phones

  • I very much doubt it’s a bug, but that’s your choice to pursue that

    You ask for help but perhaps you are not wanting to listen

    If you open your asterisk rtp ports in your firewall then you are following pretty much what everyone else does. Otherwise you are letting another device interfere with your Sip transactions and we have already shown that’s a bad idea. Makes no difference whether it’s open source or not.

    But up to you

    —

  • Hello,

    thanks you very much for your effort. Without your help I would never realize the problem lies in the firewall.

    But what do you mean by the doubt that it is bug? You mean it should be configured another way? I do not claim my configuration is correct. I am also new to nftables. But I do not think opening the wide port range is a solution. The nftables runs on the asterisk server itself.

    Marek

    2021-09-10 1:19 GMT+02:00, Duncan Turnbull :

    —

  • The reason I don’t use sip algs is because they have a have a function that isn’t required. And a complexity that messes things up. No exploit has yet been found for rtp for 20 years and it has been open to the world. For whatever reason you can’t get your head around this being a valid option so then you are jumping to a bug when you freely admit your lack of familiarity

    This may be your scenario

    https://unix.stackexchange.com/questions/461320/nf-conntrack-sip-does-not-work-sometimes-restarting-iptables-usually-fixes-it

    You are adding a dependency on the firewall that you don’t need using configuration you are not sure of. That is never a reliable situation to be in.

    Why would nftables have a bug? Many people use it around the world and it works well. What is the likelihood of a bug in this scenario

    The alternative is a misconfiguration, and you are not very familiar with the configuration and new to nftables. Which one is more likely?

    The above issue sounds like yours but it could be something else

    You can research and find the config error, or somehow you can prove a bug or you can remove the issue by just allowing rtp through

    All of these are your choices. To me the config error is most likely as I have very rarely found a bug. It’s almost always config

  • Hello,

    I already read the scenario you pointed to. It is not really the same. as you can see in my rules I sent before I have CT in both directions.

    Related to configuration error I am 99% sure the configuration is correct. It was generated by automatic tool and then slightly edited and reviewed by nftables guru. I just admit the there could be some configuration error. Maybe some race condition in systemd – wrong dependencies or something like that. I do not know. But I am sure once I will find it (or suffer longer).

    The reason many people use it and they will notice is invalid. I hit a bug in PMTU dicovery several moths ago. And no one was complaining at all. The bug is now fixed, so it is pretty probable it is a bug.

    The reasoning that no expliot has been found in rtp for 20 year is invalid. We are not talking about bugs in rtp. We are talking about open ports and application local to asterisk server could use. So many backdoors can be open. Believe me. It is not secure. Maybe it is acceptable on a dedicated asterisk box, but not on a multi purpose server.

    Marek

    2021-09-10 23:28 GMT+02:00, Duncan Turnbull :
    —

1 2