[asterisk-users] problems with natted phones

[Administrator]

Hi. Our rules:

Le 08/09/2021 à 22:43, Marek Greško a écrit :
> Hello,
>
> I did converted from iptables by automatical script and then rewritten
> myself, because not everything was rewritten successfully.
>
> Relevant parts:
>
> table ip filter {
>    ct helper sip {
>      type "sip" protocol udp
>      l3proto ip
>    }
>
>    chain PREROUTING {
>      type filter hook prerouting priority filter; policy accept;
>      udp port 5060 ct helper set "sip"
>    }
>
>    chain INPUT {
>      ...
>      ct state invalid drop
>      ct state related accept
>      ct state established accept
>      ...
>      iifname "ppp0" jump i-inet
>    }

set world_udp.eth0 {
                 type inet_service
                 flags interval
                 elements = { iax, sip, sip-tls, 10000-30000 }
         }

chain input {
                 type filter hook input priority 0; policy drop;
                 iif "eth0" ip daddr <ip address> udp dport 
@world_udp.eth0 counter packets 15394440 bytes 3738156190 accept
                 ....

As you see we take care on RTP port range defined in rtp,conf

>
>    chain OUTPUT {
>      type filter hook output priority filter; policy accept;
>      udp port 5060 ct helper set "sip"
>      ...
>    }
chain output {
                 type filter hook output priority 0; policy drop;
                 oif "eth0" ct state established,related,new counter 
packets 17542533 bytes 6033494909 accept

our default policy is to drop so we add new in ct state

>
>    chain i-inet {
>      ...
>      udp port 5060 jump r-sip
>      ...
>    }
>
>    chain r-sip {
>      ip saddr 192.0.2.0/24 accept
>    }
> }
>
> table ip mangle {
>    chain PREROUTING {
>      type filter hook prerouting priority mangle; policy accept;
>      ...
>      udp sport 5060 ip dscp set 0x04
>    }
>
>    chain OUTPUT {
>      type route hook output priority mangle; policy accept;
>      ...
>      udp dport 5060 ip dscp set 0x04
>      ...
>    }
> }
>
> table ip6 filter {
>    ct helper sip {
>      type "sip" protocol udp
>      l3proto ip6
>    }
>
>    ... pretty the same, but I have no ipv6 internet connectivity, so
> this should not match ...
>
> }
>
>
> Is there something incorrect?
>
> Thanks
>
> Marek
>
>
>
> 2021-09-08 21:17 GMT+02:00, Duncan Turnbull <duncan at e-simple.co.nz>:
>>
>>> On 9/09/2021, at 6:23 AM, Marek Greško <mgresko8 at gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> I confirm temporarily allowing all the udp communication from the nat
>>> ip address solved the problem, so the problem lies in the nftables.
>>> This is probably not the right forum to continue. Or is it? Does
>>> anybody have wide experience with nftables and sip?
>> If you publish your rule set then we could look. Did you write the rules?
>> What have you checked so far?
>>
>>> Thanks
>>>
>>> Marek
>>>
>>>
>>> 2021-09-07 10:40 GMT+02:00, Antony Stone
>>> <Antony.Stone at asterisk.open.source.it>:
>>>> On Monday 06 September 2021 at 23:05:27, Duncan Turnbull wrote:
>>>>
>>>>>>> On 7/09/2021, at 8:30 AM, Marek Greško <mgresko8 at gmail.com> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> it is only local nftables with nf_conntrack_sip on the asterisk
>>>>>>> server. Probably a kernel bug? It did not trigger with previous
>>>>>>> providers since they had working SIP ALG. Now I hear no audio in both
>>>>>>> directions because outgoing rtp stream from asterisk goes to private
>>>>>>> address space and incoming stream is blocked. So the outgoing rtp
>>>>>>> could not be learnt to send to nat addess.
>>>>> Maybe a bug but that’s less likely than a config error. Time to debug
>>>>> your
>>>>> nftables.
>>>> Try temporarily simply turning the firewall off - allow all traffic
>>>> through
>>>> (although leave in place any NAT rules).
>>>>
>>>> If you then find that RTP works, you know where the problem lies.
>>>>
>>>>
>>>> Antony.
Regards

-- 
Daniel