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 <dun...@e-simple.co.nz>:
On 9/09/2021, at 6:23 AM, Marek Greško <mgres...@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.st...@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 <mgres...@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
--
_____________________________________________________________________
-- 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
