SIP proxying: siproxd vs. Netfilter SIP nat

SIP proxying: siproxd vs. Netfilter SIP nat

[Christoph Lameter]

It seems that the current sip nat module in the kernel has only limited
functionality. According to

http://people.netfilter.org/chentschel/docs/sip-conntrack-nat.html

one has to point the firewall at the target host for the SIP proxying to
work. Therefore the kernel will only support a single inside phone
connecting via SIP to the outside. For a network that has a series of
phones inside the NAT zones this means that the firewall sip nat is not
useful.

siproxd http://siproxd.sourceforge.net/ seems to be able to handle
multiple outgoing SIP connections but one needs to specify an outbound
proxy for each inside SIP phone.

Isnt there a way to make the kernel module work in the same way siproxd
works and able to support multiple phones? Right now configuring SIP
connectivity is a messy thing that is not easily setup. Can we fix this?

Re: SIP proxying: siproxd vs. Netfilter SIP nat

[Patrick McHardy]

Christoph Lameter wrote:
> It seems that the current sip nat module in the kernel has only limited
> functionality. According to
> 
> http://people.netfilter.org/chentschel/docs/sip-conntrack-nat.html
> 
> one has to point the firewall at the target host for the SIP proxying to
> work. Therefore the kernel will only support a single inside phone
> connecting via SIP to the outside. For a network that has a series of
> phones inside the NAT zones this means that the firewall sip nat is not
> useful.

That documentation is horribly outdated.

> siproxd http://siproxd.sourceforge.net/ seems to be able to handle
> multiple outgoing SIP connections but one needs to specify an outbound
> proxy for each inside SIP phone.
> 
> Isnt there a way to make the kernel module work in the same way siproxd
> works and able to support multiple phones? Right now configuring SIP
> connectivity is a messy thing that is not easily setup. Can we fix this?

It should work fine with multiple phones, it even recognizes calls
between two internal phones and makes the media stream go between
them directly. Depending on how your registrar/proxy works, you might
have to set one or both of these module options:

sip_direct_signalling: when set to zero, allows incoming signalling
 connections from other hosts than the registrar. Usually not needed.

sip_direct_media: when set to zero, allows incoming media streams
 from other hosts than the registrar. This one is often required,
 some providers use server farms for handling the media streams,
 some set up media streams to go directly between the endpoints.

Re: SIP proxying: siproxd vs. Netfilter SIP nat

[Christoph Lameter]

On Mon, 30 Nov 2009, Patrick McHardy wrote:

> > http://people.netfilter.org/chentschel/docs/sip-conntrack-nat.html
>
> That documentation is horribly outdated.

Where do I find more recent documentation?

> > Isnt there a way to make the kernel module work in the same way siproxd
> > works and able to support multiple phones? Right now configuring SIP
> > connectivity is a messy thing that is not easily setup. Can we fix this?
>
> It should work fine with multiple phones, it even recognizes calls
> between two internal phones and makes the media stream go between
> them directly. Depending on how your registrar/proxy works, you might
> have to set one or both of these module options:

Loaded both sip modules without specifying any parameters. Resulted in one
way audio problems which is what I also get without the modules.

> sip_direct_signalling: when set to zero, allows incoming signalling
>  connections from other hosts than the registrar. Usually not needed.
>
> sip_direct_media: when set to zero, allows incoming media streams
>  from other hosts than the registrar. This one is often required,
>  some providers use server farms for handling the media streams,
>  some set up media streams to go directly between the endpoints.

Ok will try setting that parameter to zero.

Re: SIP proxying: siproxd vs. Netfilter SIP nat

[Patrick McHardy]

Christoph Lameter wrote:
> On Mon, 30 Nov 2009, Patrick McHardy wrote:
> 
>>> http://people.netfilter.org/chentschel/docs/sip-conntrack-nat.html
>> That documentation is horribly outdated.
> 
> Where do I find more recent documentation?

Below :)

>>> Isnt there a way to make the kernel module work in the same way siproxd
>>> works and able to support multiple phones? Right now configuring SIP
>>> connectivity is a messy thing that is not easily setup. Can we fix this?
>> It should work fine with multiple phones, it even recognizes calls
>> between two internal phones and makes the media stream go between
>> them directly. Depending on how your registrar/proxy works, you might
>> have to set one or both of these module options:
> 
> Loaded both sip modules without specifying any parameters. Resulted in one
> way audio problems which is what I also get without the modules.
> 
>> sip_direct_signalling: when set to zero, allows incoming signalling
>>  connections from other hosts than the registrar. Usually not needed.
>>
>> sip_direct_media: when set to zero, allows incoming media streams
>>  from other hosts than the registrar. This one is often required,
>>  some providers use server farms for handling the media streams,
>>  some set up media streams to go directly between the endpoints.
> 
> Ok will try setting that parameter to zero.

You of course also need to accept the packets marked RELATED by
the helper. If this is missing it might result in one-way audio.

Re: SIP proxying: siproxd vs. Netfilter SIP nat

[Christoph Lameter]

On Mon, 30 Nov 2009, Patrick McHardy wrote:

> > Where do I find more recent documentation?
>
> Below :)

I found http://lwn.net/Articles/271597/ which mentions that those two
values may be set too strictly. Can they default to zero?

> You of course also need to accept the packets marked RELATED by
> the helper. If this is missing it might result in one-way audio.

Firewall is configured to accept all udp traffic. Will that do it?

The "helper" is the conntrack module?

Re: SIP proxying: siproxd vs. Netfilter SIP nat

[Patrick McHardy]

Christoph Lameter wrote:
> On Mon, 30 Nov 2009, Patrick McHardy wrote:
> 
>>> Where do I find more recent documentation?
>> Below :)
> 
> I found http://lwn.net/Articles/271597/ which mentions that those two
> values may be set too strictly. Can they default to zero?

No, this is deliberate since it diverges from the behaviour of other
helpers. Usually they only allow to create RELATED connections between
the two hosts communicating. If you set either of these module options
to zero, they will allow completely foreign addresses to establish
connections when those addresses appear in the SDP payload. You should
usually use additional filters to f.i. only allow source addresses of
your registrar:

iptables -A FORWARD -m state --state RELATED \
		    -m helper --helper "sip" \
		    -s registrar-network/X -j ACCEPT

>> You of course also need to accept the packets marked RELATED by
>> the helper. If this is missing it might result in one-way audio.
> 
> Firewall is configured to accept all udp traffic. Will that do it?

That should be fine, but you can restrict it to just accept
-m state --state RELATED packets.

> The "helper" is the conntrack module?

Yes.

Re: SIP proxying: siproxd vs. Netfilter SIP nat

[Christoph Lameter]

On Mon, 30 Nov 2009, Patrick McHardy wrote:

> No, this is deliberate since it diverges from the behaviour of other
> helpers. Usually they only allow to create RELATED connections between
> the two hosts communicating. If you set either of these module options
> to zero, they will allow completely foreign addresses to establish
> connections when those addresses appear in the SDP payload. You should
> usually use additional filters to f.i. only allow source addresses of
> your registrar:
>
> iptables -A FORWARD -m state --state RELATED \
> 		    -m helper --helper "sip" \
> 		    -s registrar-network/X -j ACCEPT

Please put documentation with all these tricks somewhere where people
looking for SIP NAT can find it. I see multiple threads where people have
struggled with setting up SIP proxying and have failed.