All of lore.kernel.org
 help / color / mirror / Atom feed
* Strange behavior of conntrack helper sip: rules do not always match as expected
@ 2016-05-18 18:21 Jürgen Schmidt
  0 siblings, 0 replies; only message in thread
From: Jürgen Schmidt @ 2016-05-18 18:21 UTC (permalink / raw)
  To: netfilter

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2016-05-18 18:21 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-05-18 18:21 Strange behavior of conntrack helper sip: rules do not always match as expected Jürgen Schmidt

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.