Strange behavior of conntrack helper sip: rules do not always match as expected

["Jürgen Schmidt" <abcdmail@freenet.de>]

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