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@xxxxxxxx
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@xxxxxxxx
From:caller@domain_name
To:callee@domain_name
contact: caller@xxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxx> escribió:
rebeca.martinez-garcia@xxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxx
From: sip:caller@xxxxxxxxxxxxx
To: sip:callee@xxxxxxxxxxxxx
Contact: sip:caller@xxxxxxxxxxx:5061
2. INVITE sip:callee@xxxxxxxxxxxxx
From: sip:caller@xxxxxxxxxxxxx
To: sip:callee@xxxxxxxxxxxxx
Contact: sip:caller@xxxxxxxx:5061
3. INVITE sip:callee@xxxxxxxx:5060
From: sip:caller@xxxxxxxxxxxxx
To: sip:callee@xxxxxxxxxxxxx
Contact: sip:caller@xxxxxxxx:5061
4. INVITE sip:callee@xxxxxxxx:5061
From: sip:caller@xxxxxxxxxxxxx
To: sip:callee@xxxxxxxxxxxxx
Contact: sip:caller@xxxxxxxx: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.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
