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
}
chain OUTPUT {
type filter hook output priority filter; policy accept;
udp port 5060 ct helper set "sip"
...
}
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.
>>>
>>> --
>>> Perfection in design is achieved not when there is nothing left to
add,
>>> but
>>> rather when there is nothing left to take away.
>>>
>>> - Antoine de Saint-Exupery
>>>
>>> Please reply to
the
>>> list;
>>> please
*don't* CC
>>> me.
>>>
>>> --
>>>
_____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com
--
>>>
>>> Check out the new Asterisk community forum at:
>>> https://community.asterisk.org/
>>>
>>> New to Asterisk? Start here:
>>> https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> Check out the new Asterisk community forum at:
>> https://community.asterisk.org/
>>
>> New to Asterisk? Start here:
>> https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-users
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
> https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
Sorry did convert, not did converted :) 2021-09-08 22:43 GMT+02:00, Marek Greško <mgresko8 at gmail.com>:> 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 > } > > chain OUTPUT { > type filter hook output priority filter; policy accept; > udp port 5060 ct helper set "sip" > ... > } > > 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. >>>> >>>> -- >>>> Perfection in design is achieved not when there is nothing left to add, >>>> but >>>> rather when there is nothing left to take away. >>>> >>>> - Antoine de Saint-Exupery >>>> >>>> Please reply to the >>>> list; >>>> please *don't* >>>> CC >>>> me. >>>> >>>> -- >>>> _____________________________________________________________________ >>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>>> >>>> Check out the new Asterisk community forum at: >>>> https://community.asterisk.org/ >>>> >>>> New to Asterisk? Start here: >>>> https://wiki.asterisk.org/wiki/display/AST/Getting+Started >>>> >>>> asterisk-users mailing list >>>> To UNSUBSCRIBE or update options visit: >>>> http://lists.digium.com/mailman/listinfo/asterisk-users >>> >>> -- >>> _____________________________________________________________________ >>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>> >>> Check out the new Asterisk community forum at: >>> https://community.asterisk.org/ >>> >>> New to Asterisk? Start here: >>> https://wiki.asterisk.org/wiki/display/AST/Getting+Started >>> >>> asterisk-users mailing list >>> To UNSUBSCRIBE or update options visit: >>> http://lists.digium.com/mailman/listinfo/asterisk-users >> >> -- >> _____________________________________________________________________ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> Check out the new Asterisk community forum at: >> https://community.asterisk.org/ >> >> New to Asterisk? Start here: >> https://wiki.asterisk.org/wiki/display/AST/Getting+Started >> >> asterisk-users mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-users >
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