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 -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
