Strange behavior of conntrack helper sip: rules do not always match as expected
Hello!
Given is an Asterisk server running on a Linux 3.10.101 machine with a global IP address (-> no NAT).
The following rules are given:
INPUT
=====
# SIP
iptables \
-A INPUT -i ppp0 -p udp -s 217.0.18.0/23 \
-d 217.232.238.65 --sport 5060 --dport 5060 -m conntrack \
--ctstate RELATED,ESTABLISHED -j ACCEPT
# RTP
iptables \
-A INPUT -i ppp0 -p udp -s 217.0.0.0/13 -d 217.232.238.65 \
--dport 11500:12000 -m conntrack --ctstate RELATED,ESTABLISHED \
-m helper --helper sip -j ACCEPT
OUTPUT
======
# SIP
iptables -A OUTPUT -p udp -o ppp0 -s 217.232.238.65 -d 217.0.18.0/23 \
--dport 5060 --sport 5060 -j ACCEPT
# RTP
iptables -A OUTPUT -p udp -o ppp0 -s 217.232.238.65 -d 217.0.0.0/13 --sport 11500:12000 -m conntrack --ctstate RELATED,ESTABLISHED \
-m helper --helper sip -j ACCEPT
This configuration works pretty fine as long as there is no ringgroup defined in Asterisk / FreePBX, which contains an *outbound* phone number. If the ringgroup contains an outbound phone number, the following problem happens, if the incoming call is accepted *locally*:
- Asterisk stops the signaling to the outbound phone through the trunk.
- Asterisk gives the call to the local phone.
Now the problem:
===============
All RTP packages between provider and Asterisk trunk are now blocked in both directions by netfilter.
To get it working again, these two additional rules are necessary for RTP handling *without* sip helper (but otherwise mostly the same as the RTP rules above besides slightly different states):
iptables -I INPUT -i ppp0 -p udp -s 217.0.0.0/13 -d 217.232.238.65 --dport 11500:12000 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp -o ppp0 -s 217.232.238.65 -d 217.0.0.0/13 \
--sport 11500:12000 -m conntrack --ctstate ESTABLISHED -j ACCEPT
Analyzing w/ conntrack -E didn't show any abnormality - the relevant and correct rules have been generated - but obviously aren't matched by the standard rules w/ helper sip any more although the rules would have been completely suited. I too tested the sip helper rules using all states NEW,RELATED,ESTABLISHED - this doesn't match, too.
Do you have any idea about what's going on there?
Thanks for any hint,
kind regards,
Jürgen