nf_conntrack_sip and nf_nat_sip not working

nf_conntrack_sip and nf_nat_sip not working

[rebeca.martinez-garcia]

Hi all,

I am tired of googling and try all the options I have found.
I have loaded moduls nf_conntrack_sip and nf_nat_sip:

cng@cng:~$ lsmod | grep nf
nf_nat_sip              6300  0
nf_conntrack_sip       17872  1 nf_nat_sip
nf_nat                 17808  2 nf_nat_sip,iptable_nat
nf_conntrack_ipv4      13352  7 iptable_nat,nf_nat
nf_conntrack           67608  7  
xt_helper,xt_state,nf_nat_sip,nf_conntrack_sip,iptable_nat,nf_nat,nf_conntrack_ipv4
nf_defrag_ipv4          1756  1 nf_conntrack_ipv4
binfmt_misc             8356  1

but they are not working.
I am facing oneway audio problem due to NAT because it does not change  
the private IP of the client in its Contact Field of the SIP message  
although that modules are loaded.
Maybe it is because of my iptables configuration (Am I forgetting to  
include some rules?):

#! /bin/bash

# The script is saved in /etc/firewall.bash

# Load modules:
/sbin/modprobe ip_tables
/sbin/modprobe iptable_nat
/sbin/modprobe iptable_filter
/sbin/modprobe nf_conntrack
/sbin/modprobe nf_conntrack_sip sip_direct_signalling=0 sip_direct_media=0
/sbin/modprobe nf_nat_sip

# Remove all rules and chains:
iptables -F
iptables -X

# Accept input connections:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p udp -m multiport --dport 1025:60000 -j ACCEPT

# Forward:
iptables -A FORWARD -o eth0 -p udp -m multiport --dport 1025:60000 -j ACCEPT
iptables -A FORWARD -p udp -m multiport --dport 1025:60000 -d  
192.168.50.0/24 -j ACCEPT
iptables -t mangle -A FORWARD -m helper --helper sip -j CLASSIFY  
--set-class 1:1

# MASQUERADE:
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 10.1.3.207

# End message:
echo " [End iptables rules setting]"

Please, I really need help.

Thanks in advance,
Rebeca Martinez

nf_conntrack_sip and nf_nat_sip can do this??

[rebeca.martinez-garcia]

Hi all,

I have been working with nf_conntrack_sip and nf_nat_sip for a while  
to permit SIP clients in a private LAN can connect to servers outside  
without problems.

However, in the case of an internal call, I was wondering if it is  
possible that these two modules detect that the incoming INVITE from  
the LAN is to another client of the same LAN and so not routing it  
outside.

Is it possible??

Thanks in advance,
Rebeca Martinez

Re: nf_conntrack_sip and nf_nat_sip can do this??

[Patrick McHardy]

rebeca.martinez-garcia@estudiant.upc.edu wrote:
> 
> Hi all,
> 
> I have been working with nf_conntrack_sip and nf_nat_sip for a while to
> permit SIP clients in a private LAN can connect to servers outside
> without problems.
> 
> However, in the case of an internal call, I was wondering if it is
> possible that these two modules detect that the incoming INVITE from the
> LAN is to another client of the same LAN and so not routing it outside.
> 
> Is it possible??

Yes, the module does exactly that when the NAT module is loaded.

Re: nf_conntrack_sip and nf_nat_sip can do this??

[rebeca.martinez-garcia]

Hi all,

I think it is better to explain the complete situation.

I have 2 SIP clients in a private LAN that connect to a public  
Server/Proxy by means of a gateway. Actually, this Server/Proxy is not  
one machine but 4: one of them is a Proxy (the first contact point of  
the SIP clients to this "platform") and another one is the Server  
where the register and authentication procedures are done.

This means that when a "private" client wants to register in this  
"platform", its REGISTER message is directed to the Proxy via the  
gateway. To make it simple, let's assume that in the "platform" the  
Proxy directly redirects the REGISTER message to the Server (it is in  
fact a little more complicated but at the end the message reaches that  
Server). However, as there is no authentication information on the  
message, it sends back to the client a 401 Unauthorized error.

The client incorporates the authentication information needed to the  
REGISTER message and sends it again to the Proxy and now the Server  
accepts the registration (it sends a 200 OK). Now this client can call  
other users registered in this "platform".

But, as the gateway NATs all incoming messages from the LAN, I faced  
problems of one-way audio and non-routing IP addresses. That was  
solved by incorporating to the CNG's iptables the nf_conntrack_sip and  
nf_nat_sip modules.

If a client wants to call another client (it does not matter if it is  
private or public, it redirects the INVITE message to the "platform"  
because it knows the callee location). So a call between two private  
clients is as I have shown in a previous e-mail (I skip the  
communication inside the platform):

Caller -------1.INVITE------>             ----------2.INVITE-------->
                             Gateway (NAT)                          Proxy
                       nf_conntrack_sip+nf_nat_sip
Callee <-----4.INVITE-------              <---------3.INVITE--------

1: INVITE sip:callee@open-ims.test
      From: sip:caller@open-ims.test
      To: sip:callee@open-ims.test
      Contact: sip:caller@192.168.x.x:5061
2. INVITE sip:callee@open-ims.test
      From: sip:caller@open-ims.test
      To: sip:callee@open-ims.test
      Contact: sip:caller@10.1.y.y:5061
3. INVITE sip:callee@10.1.y.y:5060
      From: sip:caller@open-ims.test
      To: sip:callee@open-ims.test
      Contact: sip:caller@10.1.y.y:5061
4. INVITE sip:callee@10.1.y.y:5061
      From: sip:caller@open-ims.test
      To: sip:callee@open-ims.test
      Contact: sip:caller@10.1.y.y:5061

And is in the 4.INVITE where I have realised there is a problem: it  
does not change the public IP of the callee to the private one,  
neither change the Contact IP of the caller.

So when they start to send their RTP streams, they send them to the  
public IP of my gateway on the corresponding port. The caller sends  
the stream to the 127.1.y.y.5060 and my gateway redirects it to the  
192.168.x.x:5060.
So I guess that the gateway has a table in which it indicates for each  
private_ip:port the corresponding public_ip:port.

Then, if the gateway has this table (that in fact is like a local  
location information), is it possible to configure "something" in  
iptables to, knowing that the requested callee is inside the LAN,  
route the message directly to it?

I only want to enable internal calls.

I also tried configuring SER but it is very problematic with the  
authentication during the register process.

I will appreciate any help and sorry for the long explanation.

Thanks in advance,
Rebeca Martinez





"Patrick McHardy" <kaber@trash.net> escribió:

> rebeca.martinez-garcia@estudiant.upc.edu wrote:
>>
>> Hi all,
>>
>> I have been working with nf_conntrack_sip and nf_nat_sip for a while to
>> permit SIP clients in a private LAN can connect to servers outside
>> without problems.
>>
>> However, in the case of an internal call, I was wondering if it is
>> possible that these two modules detect that the incoming INVITE from the
>> LAN is to another client of the same LAN and so not routing it outside.
>>
>> Is it possible??
>
> Yes, the module does exactly that when the NAT module is loaded.
>

Re: nf_conntrack_sip and nf_nat_sip can do this??

[Patrick McHardy]

rebeca.martinez-garcia@estudiant.upc.edu wrote:
> Hi all,
> 
> I think it is better to explain the complete situation.
> 
> I have 2 SIP clients in a private LAN that connect to a public
> Server/Proxy by means of a gateway. Actually, this Server/Proxy is not
> one machine but 4: one of them is a Proxy (the first contact point of
> the SIP clients to this "platform") and another one is the Server where
> the register and authentication procedures are done.
> 
> This means that when a "private" client wants to register in this
> "platform", its REGISTER message is directed to the Proxy via the
> gateway. To make it simple, let's assume that in the "platform" the
> Proxy directly redirects the REGISTER message to the Server (it is in
> fact a little more complicated but at the end the message reaches that
> Server). However, as there is no authentication information on the
> message, it sends back to the client a 401 Unauthorized error.
> 
> The client incorporates the authentication information needed to the
> REGISTER message and sends it again to the Proxy and now the Server
> accepts the registration (it sends a 200 OK). Now this client can call
> other users registered in this "platform".
> 
> But, as the gateway NATs all incoming messages from the LAN, I faced
> problems of one-way audio and non-routing IP addresses. That was solved
> by incorporating to the CNG's iptables the nf_conntrack_sip and
> nf_nat_sip modules.
> 
> If a client wants to call another client (it does not matter if it is
> private or public, it redirects the INVITE message to the "platform"
> because it knows the callee location). So a call between two private
> clients is as I have shown in a previous e-mail (I skip the
> communication inside the platform):
> 
> Caller -------1.INVITE------>             ----------2.INVITE-------->
>                             Gateway (NAT)                          Proxy
>                       nf_conntrack_sip+nf_nat_sip
> Callee <-----4.INVITE-------              <---------3.INVITE--------
> 
> 1: INVITE sip:callee@open-ims.test
>      From: sip:caller@open-ims.test
>      To: sip:callee@open-ims.test
>      Contact: sip:caller@192.168.x.x:5061
> 2. INVITE sip:callee@open-ims.test
>      From: sip:caller@open-ims.test
>      To: sip:callee@open-ims.test
>      Contact: sip:caller@10.1.y.y:5061
> 3. INVITE sip:callee@10.1.y.y:5060
>      From: sip:caller@open-ims.test
>      To: sip:callee@open-ims.test
>      Contact: sip:caller@10.1.y.y:5061
> 4. INVITE sip:callee@10.1.y.y:5061
>      From: sip:caller@open-ims.test
>      To: sip:callee@open-ims.test
>      Contact: sip:caller@10.1.y.y:5061
> 
> And is in the 4.INVITE where I have realised there is a problem: it does
> not change the public IP of the callee to the private one, neither
> change the Contact IP of the caller.

Well, that seems to be the problem. The conntrack helper can only
recognize that the call is internal if a) the addresses have been
properly rewritten on their way out and b) the proxy keeps the
original SDP addresses and doesn't decide to relay RTP itself.

> So when they start to send their RTP streams, they send them to the
> public IP of my gateway on the corresponding port. The caller sends the
> stream to the 127.1.y.y.5060 and my gateway redirects it to the
> 192.168.x.x:5060.
> So I guess that the gateway has a table in which it indicates for each
> private_ip:port the corresponding public_ip:port.

Something like that. You can see parts of the mapping in
/proc/net/nf_conntrack_expect after registration or invitations.

> Then, if the gateway has this table (that in fact is like a local
> location information), is it possible to configure "something" in
> iptables to, knowing that the requested callee is inside the LAN, route
> the message directly to it?

No, this should work automatically. You need to figure out
why the address is not translated back, most likely there's
a mismatch between the addresses or ports in the packet
and the expectation.

Re: nf_conntrack_sip and nf_nat_sip can do this??

[rebeca.martinez-garcia]

I have been investigating and the registration process is done correctly:
a private user inside the LAN sends the REGISTER to the Proxy via the  
gateway and it changes the private IP for the public IP. When the  
Proxy answers it, the gateway does the same but in the other way round.

It is during the INVITE that I have seen some problems.

When a private client sends an INVITE directed to a client outside the  
LAN (a public client) again it works ok. However, when a public client  
sends an INVITE to call a private client there is an error:

Public Client to my Proxy:
INVITE sip:private_client@domain_name
        From:caller@domain_name
        To:callee@domain_name
        contact: caller@10.1.x.x

The proxy talks with my server to know the location of the callee and  
it answers with the public IP of my gateway in a determined port. So  
the Proxy sends the invite to it:
INVITE sip:private_client@10.1.x.y
        From:caller@domain_name
        To:callee@domain_name
        contact: caller@10.1.x.x

And now the gateway redirects the invite to my private client but it  
DOES NOT change the R-URI. However, when the invite reaches the  
client, it answers with a "183 Session progress" and then it puts its  
correct contact:
183 SESSION PROGRESS
        From:caller@domain_name
        To:callee@domain_name
        contact: callee@192.168.x.x

And now, in the following messages between the caller and the callee,  
it changes correctly the private address for the public one and in the  
other way round.
It is as the gateway only starts to work correctly if the message  
comes from the LAN.

I have checked the /proc/net/nf_conntrack_expect and it contains this:

598000 l3proto = 2 proto=17 src=0.0.0.0 dst=10.1.x.x sport=0  
dport=1061 PERMANENT
597394 l3proto = 2 proto=17 src=0.0.0.0 dst=10.1.x.x sport=0  
dport=1081 PERMANENT

Is it correct that the source is 0.0.0.0 in both cases?

By the way, my iptables configuration is the following one (Am I  
missing something?):

#! /bin/bash

# The script is saved in /etc/firewall.bash

# Load modules:
/sbin/modprobe ip_tables
/sbin/modprobe iptable_nat
/sbin/modprobe iptable_filter
/sbin/modprobe nf_conntrack
/sbin/modprobe nf_nat
/sbin/modprobe -r nf_nat_sip
/sbin/modprobe -r nf_conntrack_sip
/sbin/modprobe nf_conntrack_sip ports=5060,4060  
sip_direct_signalling=0 sip_direct_media=0
/sbin/modprobe nf_nat_sip

# Remove all rules and chains:
iptables -F
iptables -X

# Forward:
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p udp --dport 5060 -j ACCEPT
iptables -A FORWARD -p udp --dport 4060 -j ACCEPT

# MASQUERADE:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# End message:
echo " [End iptables rules setting]"

Thanks in advance,
Rebeca Martinez

"Patrick McHardy" <kaber@trash.net> escribió:

> rebeca.martinez-garcia@estudiant.upc.edu wrote:
>> Hi all,
>>
>> I think it is better to explain the complete situation.
>>
>> I have 2 SIP clients in a private LAN that connect to a public
>> Server/Proxy by means of a gateway. Actually, this Server/Proxy is not
>> one machine but 4: one of them is a Proxy (the first contact point of
>> the SIP clients to this "platform") and another one is the Server where
>> the register and authentication procedures are done.
>>
>> This means that when a "private" client wants to register in this
>> "platform", its REGISTER message is directed to the Proxy via the
>> gateway. To make it simple, let's assume that in the "platform" the
>> Proxy directly redirects the REGISTER message to the Server (it is in
>> fact a little more complicated but at the end the message reaches that
>> Server). However, as there is no authentication information on the
>> message, it sends back to the client a 401 Unauthorized error.
>>
>> The client incorporates the authentication information needed to the
>> REGISTER message and sends it again to the Proxy and now the Server
>> accepts the registration (it sends a 200 OK). Now this client can call
>> other users registered in this "platform".
>>
>> But, as the gateway NATs all incoming messages from the LAN, I faced
>> problems of one-way audio and non-routing IP addresses. That was solved
>> by incorporating to the CNG's iptables the nf_conntrack_sip and
>> nf_nat_sip modules.
>>
>> If a client wants to call another client (it does not matter if it is
>> private or public, it redirects the INVITE message to the "platform"
>> because it knows the callee location). So a call between two private
>> clients is as I have shown in a previous e-mail (I skip the
>> communication inside the platform):
>>
>> Caller -------1.INVITE------>             ----------2.INVITE-------->
>>                             Gateway (NAT)                          Proxy
>>                       nf_conntrack_sip+nf_nat_sip
>> Callee <-----4.INVITE-------              <---------3.INVITE--------
>>
>> 1: INVITE sip:callee@open-ims.test
>>      From: sip:caller@open-ims.test
>>      To: sip:callee@open-ims.test
>>      Contact: sip:caller@192.168.x.x:5061
>> 2. INVITE sip:callee@open-ims.test
>>      From: sip:caller@open-ims.test
>>      To: sip:callee@open-ims.test
>>      Contact: sip:caller@10.1.y.y:5061
>> 3. INVITE sip:callee@10.1.y.y:5060
>>      From: sip:caller@open-ims.test
>>      To: sip:callee@open-ims.test
>>      Contact: sip:caller@10.1.y.y:5061
>> 4. INVITE sip:callee@10.1.y.y:5061
>>      From: sip:caller@open-ims.test
>>      To: sip:callee@open-ims.test
>>      Contact: sip:caller@10.1.y.y:5061
>>
>> And is in the 4.INVITE where I have realised there is a problem: it does
>> not change the public IP of the callee to the private one, neither
>> change the Contact IP of the caller.
>
> Well, that seems to be the problem. The conntrack helper can only
> recognize that the call is internal if a) the addresses have been
> properly rewritten on their way out and b) the proxy keeps the
> original SDP addresses and doesn't decide to relay RTP itself.
>
>> So when they start to send their RTP streams, they send them to the
>> public IP of my gateway on the corresponding port. The caller sends the
>> stream to the 127.1.y.y.5060 and my gateway redirects it to the
>> 192.168.x.x:5060.
>> So I guess that the gateway has a table in which it indicates for each
>> private_ip:port the corresponding public_ip:port.
>
> Something like that. You can see parts of the mapping in
> /proc/net/nf_conntrack_expect after registration or invitations.
>
>> Then, if the gateway has this table (that in fact is like a local
>> location information), is it possible to configure "something" in
>> iptables to, knowing that the requested callee is inside the LAN, route
>> the message directly to it?
>
> No, this should work automatically. You need to figure out
> why the address is not translated back, most likely there's
> a mismatch between the addresses or ports in the packet
> and the expectation.
>

Re: nf_conntrack_sip and nf_nat_sip can do this??

[Patrick McHardy]

rebeca.martinez-garcia@estudiant.upc.edu wrote:
> I have been investigating and the registration process is done correctly:
> a private user inside the LAN sends the REGISTER to the Proxy via the
> gateway and it changes the private IP for the public IP. When the Proxy
> answers it, the gateway does the same but in the other way round.
> 
> It is during the INVITE that I have seen some problems.
> 
> When a private client sends an INVITE directed to a client outside the
> LAN (a public client) again it works ok. However, when a public client
> sends an INVITE to call a private client there is an error:
> 
> Public Client to my Proxy:
> INVITE sip:private_client@domain_name
>        From:caller@domain_name
>        To:callee@domain_name
>        contact: caller@10.1.x.x
> 
> The proxy talks with my server to know the location of the callee and it
> answers with the public IP of my gateway in a determined port. So the
> Proxy sends the invite to it:
> INVITE sip:private_client@10.1.x.y
>        From:caller@domain_name
>        To:callee@domain_name
>        contact: caller@10.1.x.x
> 
> And now the gateway redirects the invite to my private client but it
> DOES NOT change the R-URI. However, when the invite reaches the client,
> it answers with a "183 Session progress" and then it puts its correct
> contact:
> 183 SESSION PROGRESS
>        From:caller@domain_name
>        To:callee@domain_name
>        contact: callee@192.168.x.x
> 
> And now, in the following messages between the caller and the callee, it
> changes correctly the private address for the public one and in the
> other way round.
> It is as the gateway only starts to work correctly if the message comes
> from the LAN.

Please send me a binary tcpdump (-w file -s0) containing the
traffic of both the incoming and outgoing interface of the
NAT GW.

> I have checked the /proc/net/nf_conntrack_expect and it contains this:
> 
> 598000 l3proto = 2 proto=17 src=0.0.0.0 dst=10.1.x.x sport=0 dport=1061
> PERMANENT
> 597394 l3proto = 2 proto=17 src=0.0.0.0 dst=10.1.x.x sport=0 dport=1081
> PERMANENT
> 
> Is it correct that the source is 0.0.0.0 in both cases?

Yes, that's correct since you specified sip_direct_signalling=0.

Re: nf_conntrack_sip and nf_nat_sip can do this??

[Patrick McHardy]

rebeca.martinez-garcia@estudiant.upc.edu wrote:
> 
> Hello,
> 
> I have attached the network traces you told me to do.

I can't properly save this since it uses text/plain as content-type.
Please resend as proper attachment. If your client insists on using
text/plain, gzip'ing it might help.

Re: nf_conntrack_sip and nf_nat_sip can do this??

[Patrick McHardy]

rebeca.martinez-garcia@estudiant.upc.edu wrote:
> 
> Hello,
> 
> I have gzip'ed them.
> I hope this time you do not have problems while saving.

Works fine, thanks, I'll have a closer look.

Re: nf_conntrack_sip and nf_nat_sip can do this??

[rebeca.martinez-garcia]

Hello,

I have detected in my scenario that during an internal communication  
between two Eyebeam terminals, nf_conntrack_sip and nf_nat_sip work  
fine in the SDP part although not in the SIP header. The result is  
that RTP streams go between them and not to my gateway as before.
However, just substituting one Eyebeam terminal by the IMS one I am  
using (Mercuro IMS client) the problem again appears.

Which is the difference between using one or the other type of  
terminal in this case?

Thanks in advance,
Rebeca

"Patrick McHardy" <kaber@trash.net> escribió:

> rebeca.martinez-garcia@estudiant.upc.edu wrote:
>>
>> Hello,
>>
>> I have gzip'ed them.
>> I hope this time you do not have problems while saving.
>
> Works fine, thanks, I'll have a closer look.
>