Re: [PATCH] netfilter: nf_nat_sip: fix RTP/RTCP source port translations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Pablo,

On Tue, Nov 27, 2018 at 12:57 AM Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
>
> Hi Alin,
>
> On Mon, Nov 05, 2018 at 02:54:53PM +0100, Alin Nastac wrote:
> > Perform the same SNAT translation on RTP/RTCP conntracks regardless of
> > who sends the first datagram.
> >
> > Prior to this change, RTP packets send by the peer who required source
> > port translation were forwarded with unmodified source port when this
> > peer started its voice/video stream first.
>
> Do you have more detailed description, eg. scenario triggering this
> problem to understand better what this is fixing.

The scenario fixed by this patch involves a regular SIP call, but one
that requires port
translation for the RTP conntrack. For instance, suppose you have 2
SIP agents in the
LAN, both connected to the same SIP proxy:
  - agent S1  starts first and its REGISTER phase will create a
permanent expected
conntrack on dport 5060 for allowing SIP packets to be forwarded to S1
regardless of
their source IP address or port
  - on agent S2  registration, its permanent expected conntrack will
confict with the S1
signalling expected conntrack, so it will be translated to port 1024

When S1 initiates a call using RTP/RTCP port range 1024-1025, SIP
helper will find
that port 1024 is taken over by S2's signalling expected conntrack, so
it translates it
to port range 1026-1027. All goes well if the RTP conntrack is
initiated by a packet
originated from the SIP proxy, but when the first RTP packet is sent
by S1 (usually
the peer that initiates the call is the one that sends the first RTP
packet), it is sent
towards SIP proxy with unmodified source port (1024 iso 1026).

> Not telling that this is not fixing anything, but this fix looks
> slightly hairy.

I tried to find a less hairy solution, but the information necessary
to fix RTP SNAT is not
stored in the expected conntrack created by the S1 INVITE, it is
available in the paired
expected conntrack created by the SIP proxy reply.

> BTW, I need a Signed-off-by: tag here.

Ah, I keep forgetting this, sorry! I will send it signed in a couple of hours.



[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux