LARTC - Nov 2006 - Re: iptables rule not matching after stream begins

Trying again, after re-subscribing:

On 11/20/06, Bob Beers <bob.beers@gmail.com>
wrote:
> Hello,
>
> I want to dynamically create DNAT rules for
>  RTP streams (port-mapping for a SIP proxy).
>
> If my proxy adds the rule before the first packet
>  of the RTP stream hits the port, all is well.  But, if
>  the stream begins arriving before my rule is in
>  place, it never matches.  I cannot always be
>  sure that the info for setting up the rule
>  arrives sufficiently ahead of the stream.
>
> I suspect if there is a simple resolution to my
>  problem.  Does anyone else see this behavior,
>  and will share with me the solution?
>
> Apologies if there is a better place to seek an
>  answer to this question, please redirect me as
>  necessary.
>
> I am using kernel 2.6.15.4, and iptables 1.3.3.
>
> My rules are similar to this:
> iptables -I PREROUTING -t nat -p UDP \
>   -d<public_ip> --dport <public_port> \
>    -j DNAT --to-destination <private_ip:port>
> iptables -I FORWARD -p UDP \
>    -d <private_ip> --dport <private_port>
>
-- 
-Bob

On Mon, 20 Nov 2006, Bob Beers wrote:
>>  I want to dynamically create DNAT rules for
>>   RTP streams (port-mapping for a SIP proxy).
Have you considered testing any of the patches from netfilter''s
patch-o-matic?

There are two patches that seem promising.  Quoting from the netfilter
website:

http://www.netfilter.org/patch-o-matic/pom-extra.html#pom-extra-rtsp-conntrack
  rtsp-conntrack - RTSP connection tracking and nat helper
  Author: Tom Marshall <tmarshall@real.com>
  Status: Beta - needs some testing and porting to 2.6.x
  This patch adds CONFIG_IP_NF_RTSP: support for the RTSP protocol.
  This allows UDP transports to be setup properly, including RTP and RDT.

http://www.netfilter.org/patch-o-matic/pom-extra.html#pom-extra-sip-conntrack-nat
  ip-conntrack-nat - SIP connection tracking and NAT helper
  Author: Christian Hentschel <chentschel@arnet.com.ar>
  Status: Alpha
  This adds CONFIG_IP_NF_SIP: SIP support module for netfilter
  connection tracking and NAT.
  The SIP conntrack/NAT modules support the connection tracking/NATing of
  the data streams requested on the dynamic RTP/RTCP ports, as well as
  mangling
  of SIP requests/responses.

Joe

Thank you, Joe, for your response

On 11/20/06, Flophouse Joe <flophousejoe-lartc-zvbbfzu@halibutdepot.org>
wrote:
> Have you considered testing any of the patches from netfilter''s
> patch-o-matic?
I will consider doing just that.
>
> There are two patches that seem promising.  Quoting from the netfilter
> website:
>
>
http://www.netfilter.org/patch-o-matic/pom-extra.html#pom-extra-rtsp-conntrack
...
>
http://www.netfilter.org/patch-o-matic/pom-extra.html#pom-extra-sip-conntrack-nat
...

Thanks for the pointers.

But, I think my problem is really more basic.  I only mentioned
 that it was SIP related for background.

Let me try to restate my question:

Is it a common problem that inserting a rule after a (UDP) stream is
 established does not match the rule, even though the exact same
 rule for the exact same stream does match, as long as it is inserted
 before the first packet of the stream arrives?

If so, (that it is a common, or at least known, problem), how does
 one overcome this problem?  Is there a way to "disconnect" the
 stream, once the rule is installed, so that can match?  Like I said
 in the original post, everything works right, as long as my rule
 wins the race with the first packet.

Any other hints most welcome, meanwhile I will examine the two
 patches mentioned. Thanks,
>
> Joe
>
Bob

On Tue, 21 Nov 2006, Bob Beers wrote:
> Let me try to restate my question:
>
> Is it a common problem that inserting a rule after a (UDP) stream is
> established does not match the rule, even though the exact same
> rule for the exact same stream does match, as long as it is inserted
> before the first packet of the stream arrives?
This is the way it is designed: PREROUTING rules in the nat table are only 
checked for packets that haven''t already been assigned to a connection.
If
you want, you can use the conntrack tool to flush the connection states 
after you add a new rule.

 			Alexey

On 11/21/06, Alexey Toptygin <alexeyt@freeshell.org>
wrote:
> On Tue, 21 Nov 2006, Bob Beers wrote:
>
> > Let me try to restate my question:
> >
> > Is it a common problem that inserting a rule after a (UDP) stream is
> > established does not match the rule, even though the exact same
> > rule for the exact same stream does match, as long as it is inserted
> > before the first packet of the stream arrives?
>
> This is the way it is designed: PREROUTING rules in the nat table are only
> checked for packets that haven''t already been assigned to a
connection. If
> you want, you can use the conntrack tool to flush the connection states
> after you add a new rule.
Ah, yes, this sounds like what I need.  Please excuse my ignorance, but
 how does one "use the conntrack tool to flush the connection states
 after you add a new rule"?  I have read through several tutorials and
 the iptables man pages, but did not yet find this particular gem.  In
 my ideal solution, I would flush only the connection in question, to
 avoid any perturbance of other connections.

<after a little googling ...>

I guess you mean this:
<http://www.netfilter.org/projects/conntrack/index.html>
and/or this:
<http://www.netfilter.org/projects/libnetfilter_conntrack/index.html>

I will RTF documentation, now that I see it ...

But, I wonder, is there a shortcut to the behavior I want
 through iptables --ctstatus and friends?
>
>                         Alexey
>
Thank you all very much for the hints so far.

Bob

On Tue, 21 Nov 2006, Bob Beers wrote:
> <after a little googling ...>
>
> I guess you mean this:
> <http://www.netfilter.org/projects/conntrack/index.html>
> and/or this:
> <http://www.netfilter.org/projects/libnetfilter_conntrack/index.html>
Yep.
> But, I wonder, is there a shortcut to the behavior I want
> through iptables --ctstatus and friends?
Not really. Even if you match the packet with --ctstate, I don''t
believe
there is any iptables target that would delete the connection of the 
current packet (and presumably drop the packet?). Even if you could,
you''d
still have to wait for the next packet to come along and set up a new 
connection entry, so there''s no advantage over deleting the connection 
with a userspace tool, and it would be a terrible hack.

 			Alexey