10 May
2009
10 May
'09
10:22 a.m.
Hi all,
I just tried a setup like
[UA] --> [pub][Firewall][priv] --> [priv][Kam]
where the Firewall maps the public IP reachable by UAs to a private IP
where Kamailio is listening. If I run sipsak on the Kamailio-machine, I
can register fine, but as soon as the request goes via Firewall,
authentication stops working.
So how does the IP of Kamailio actually influence authentication? Do I
have to set something special on Kamailio to make this work?
Here's the Register after a 401 and the resulting 401 again, and it
looks pretty well to me (1.2.3.4 is the public Firewall IP, which is
configured as outbound proxy on the UA, 172.17.10.50 is the private
Kamailio-IP and is also used as domain for user sipwise1, which is
trying to register). Trace is taken on client-side, but looks the same
on the Kamailio server (NAT seems to be handled fine):
U 192.168.123.150:50600 -> 1.2.3.4:5060
REGISTER sip:1.2.3.4 SIP/2.0.
Via: SIP/2.0/UDP 192.168.123.150:50600;rport;branch=z9hG4bK906580090.
From: <sip:sipwise1@172.17.10.50>;tag=1631756043.
To: <sip:sipwise1@172.17.10.50>.
Call-ID: 1235449552.
CSeq: 4 REGISTER.
Contact: <sip:sipwise1@192.168.123.150:50600;line=e779ddd40d3251b>.
Authorization: Digest username="sipwise1", realm="172.17.10.50",
nonce="4a06e2820000000a80c173db2d166fedb7d8d1e933c97855",
uri="sip:1.2.3.4", response="de645a701a7c507c47a5278923bce54b",
algorithm=MD5.
Max-Forwards: 70.
User-Agent: Linphone/2.1.1 (eXosip2/3.1.0).
Expires: 900.
Content-Length: 0.
U 1.2.3.4:5060 -> 192.168.123.150:50600
SIP/2.0 401 Unauthorized.
Via: SIP/2.0/UDP
192.168.123.150:50600;rport=50600;branch=z9hG4bK906580090;received=213.47.175.165.
From: <sip:sipwise1@172.17.10.50>;tag=1631756043.
To: <sip:sipwise1@172.17.10.50>;tag=a49efde55ae28efd11dc5969af09c5db.b607.
Call-ID: 1235449552.
CSeq: 4 REGISTER.
WWW-Authenticate: Digest realm="172.17.10.50",
nonce="4a06e2820000000b2bd307dd3e71c80e3d6549ccc2b28269".
Server: Sipwise registrar.
Content-Length: 0.
So the only thing referring to the public Firewall IP is in the R-Uri of
the registration and in the Authorization-uri-token. Is this token also
used to calculate the auth hashes somehow?
Username looks fine in the Authorization header, and so does Realm. Any
ideas?
Andreas
10 May
10 May
11:02 a.m.
New subject: [Kamailio-Users] Firewall and auth
Andreas Granig writes:
So how does the IP of Kamailio actually influence
authentication? Do I
have to set something special on Kamailio to make this work?
i don't think ip addresses have anything to do with authentication. in
your example, request uri should have the domain the registration is
for, i.e., 172.17.10.50, but that should not affect authentication.
Authorization: Digest username="sipwise1",
realm="172.17.10.50",
nonce="4a06e2820000000a80c173db2d166fedb7d8d1e933c97855",
uri="sip:1.2.3.4", response="de645a701a7c507c47a5278923bce54b",
algorithm=MD5.
compare this to a working register from sipsak.
-- juha
11 May
11 May
3:53 a.m.
Juha,
Seems you're right, I managed to register with sipsak using -p for
outbound proxy, and also with Qutecom, if uri is set to the 172.17.10.50
ip. Funny thing is that linphone refuses to register (error code for
"wrong password" in Kamailio) although the Authorization header looks
the same regarding uri/realm/username tokens.
Well, gonna look deeper, but it makes me wonder a little...
Andreas
Juha Heinanen wrote:
Andreas Granig writes:
So how does the IP of Kamailio actually influence
authentication? Do I
have to set something special on Kamailio to make this work?
i don't think ip addresses have anything to do with authentication. in
your example, request uri should have the domain the registration is
for, i.e., 172.17.10.50, but that should not affect authentication.
Authorization: Digest
username="sipwise1", realm="172.17.10.50",
nonce="4a06e2820000000a80c173db2d166fedb7d8d1e933c97855",
uri="sip:1.2.3.4", response="de645a701a7c507c47a5278923bce54b",
algorithm=MD5.
compare this to a working register from sipsak.
-- juha 
10 May
10 May
11:10 a.m.
El Domingo, 10 de Mayo de 2009, Andreas Granig escribió:
So the only thing referring to the public Firewall IP
is in the R-Uri of
the registration and in the Authorization-uri-token. Is this token also
used to calculate the auth hashes somehow?
Username looks fine in the Authorization header, and so does Realm. Any
ideas?
I see nothing wrong in this trace, all seems correct. So I expect some
error in client authentication algorithm and so.
You could log the "www_authorize()" return code in Kamailio, which would
be a negative value. I do the following:
if (!www_authorize("","subscriber")) {
if $rc == -1
xlog("L_WARN", "REGISTER _WARN_ www_authorize(): -1 (invalid user)
[$tu from $si:$sp]\n");
else if $rc == -2
xlog("L_WARN", "REGISTER _WARN_ www_authorize(): -2 (invalid password)
[$tu from $si:$sp]\n");
else if $rc == -3
xlog("L_INFO", "REGISTER www_authorize(): -3 (stale nonce) [$tu from
$si:$sp]\n");
else if $rc == -5
xlog("L_WARN", "REGISTER _WARN_ www_authorize(): -5 (generic error)
[$tu from $si:$sp]\n");
www_challenge("","1");
exit;
}
--
Iñaki Baz Castillo <ibc(a)aliax.net>
11 May
11 May
3:45 a.m.
Hello,
running in debug mode should reveal also more details about where the
issue actually resides.
Cheers,
Daniel
On 05/10/2009 06:10 PM, Iñaki Baz Castillo wrote:
El Domingo, 10 de Mayo de 2009, Andreas Granig
escribió:
--
Daniel-Constantin Mierla
http://www.asipto.com/
So the only thing referring to the public
Firewall IP is in the R-Uri of
the registration and in the Authorization-uri-token. Is this token also
used to calculate the auth hashes somehow?
Username looks fine in the Authorization header, and so does Realm. Any
ideas?
I see nothing wrong in this trace, all seems correct. So I expect some
error in client authentication algorithm and so.
You could log the "www_authorize()" return code in Kamailio, which would
be a negative value. I do the following:
if (!www_authorize("","subscriber")) {
if $rc == -1
xlog("L_WARN", "REGISTER _WARN_ www_authorize(): -1 (invalid user)
[$tu from $si:$sp]\n");
else if $rc == -2
xlog("L_WARN", "REGISTER _WARN_ www_authorize(): -2 (invalid password)
[$tu from $si:$sp]\n");
else if $rc == -3
xlog("L_INFO", "REGISTER www_authorize(): -3 (stale nonce) [$tu from
$si:$sp]\n");
else if $rc == -5
xlog("L_WARN", "REGISTER _WARN_ www_authorize(): -5 (generic error)
[$tu from $si:$sp]\n");
www_challenge("","1");
exit;
}
5:54 a.m.
Inaki, Daniel,
In debug mode, it only shows that in auth/api.c:check_response the
result doesn't match.
Since I managed to authenticate sipsak and qutecom, but not linphone, I
also guess there must be something wrong with the implementation.
Strange thing is that it works in a setup without FW, but not with FW
(same for kphone).
Andreas
Daniel-Constantin Mierla wrote:
Hello,
running in debug mode should reveal also more details about where the
issue actually resides.
Cheers,
Daniel
On 05/10/2009 06:10 PM, Iñaki Baz Castillo wrote:
El Domingo, 10 de Mayo de 2009, Andreas Granig
escribió:
So the only thing referring to the public
Firewall IP is in the R-Uri of
the registration and in the Authorization-uri-token. Is this token also
used to calculate the auth hashes somehow?
Username looks fine in the Authorization header, and so does Realm. Any
ideas?
I see nothing wrong in this trace, all seems correct. So I expect some
error in client authentication algorithm and so.
You could log the "www_authorize()" return code in Kamailio, which would
be a negative value. I do the following:
if (!www_authorize("","subscriber")) {
if $rc == -1
xlog("L_WARN", "REGISTER _WARN_ www_authorize(): -1 (invalid user)
[$tu from $si:$sp]\n");
else if $rc == -2
xlog("L_WARN", "REGISTER _WARN_ www_authorize(): -2 (invalid password)
[$tu from $si:$sp]\n");
else if $rc == -3
xlog("L_INFO", "REGISTER www_authorize(): -3 (stale nonce) [$tu from
$si:$sp]\n");
else if $rc == -5
xlog("L_WARN", "REGISTER _WARN_ www_authorize(): -5 (generic error)
[$tu from $si:$sp]\n");
www_challenge("","1");
exit;
}
11:37 a.m.
Hello,
On 05/11/2009 12:54 PM, Andreas Granig wrote:
Inaki, Daniel,
In debug mode, it only shows that in auth/api.c:check_response the
result doesn't match.
Since I managed to authenticate sipsak and qutecom, but not linphone, I
also guess there must be something wrong with the implementation.
Strange thing is that it works in a setup without FW, but not with FW
(same for kphone).
so you get same behavior with kphone as well (no auth when behind fw)?
Never used linphone, but kphone was ok in all test i've been using...
Some of the phones use the domain, some don't, when computing
credentials, this could be a reason if the domain is taken from
different sources. Checking the source code could reveal the issue.
Cheers,
Daniel
Andreas
Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com/
Hello,
running in debug mode should reveal also more details about where the
issue actually resides.
Cheers,
Daniel
On 05/10/2009 06:10 PM, Iñaki Baz Castillo wrote:
> El Domingo, 10 de Mayo de 2009, Andreas Granig escribió:
>
>
>> So the only thing referring to the public Firewall IP is in the R-Uri of
>> the registration and in the Authorization-uri-token. Is this token also
>> used to calculate the auth hashes somehow?
>> Username looks fine in the Authorization header, and so does Realm. Any
>> ideas?
>>
>>
> I see nothing wrong in this trace, all seems correct. So I expect some
> error in client authentication algorithm and so.
>
> You could log the "www_authorize()" return code in Kamailio, which would
> be a negative value. I do the following:
>
> if (!www_authorize("","subscriber")) {
> if $rc == -1
> xlog("L_WARN", "REGISTER _WARN_ www_authorize(): -1 (invalid user)
[$tu from $si:$sp]\n");
> else if $rc == -2
> xlog("L_WARN", "REGISTER _WARN_ www_authorize(): -2 (invalid
password) [$tu from $si:$sp]\n");
> else if $rc == -3
> xlog("L_INFO", "REGISTER www_authorize(): -3 (stale nonce) [$tu
from $si:$sp]\n");
> else if $rc == -5
> xlog("L_WARN", "REGISTER _WARN_ www_authorize(): -5 (generic
error) [$tu from $si:$sp]\n");
> www_challenge("","1");
> exit;
> }
>
>
>
>
>
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
15 Jun
15 Jun
9:55 a.m.
Andreas Granig schrieb:
Hi all,
I just tried a setup like
[UA] --> [pub][Firewall][priv] --> [priv][Kam]
where the Firewall maps the public IP reachable by UAs to a private IP
where Kamailio is listening. If I run sipsak on the Kamailio-machine, I
can register fine, but as soon as the request goes via Firewall,
authentication stops working.
So how does the IP of Kamailio actually influence authentication? Do I
have to set something special on Kamailio to make this work?
Here's the Register after a 401 and the resulting 401 again, and it
looks pretty well to me (1.2.3.4 is the public Firewall IP, which is
configured as outbound proxy on the UA, 172.17.10.50 is the private
Kamailio-IP and is also used as domain for user sipwise1, which is
trying to register). Trace is taken on client-side, but looks the same
on the Kamailio server (NAT seems to be handled fine):
U 192.168.123.150:50600 -> 1.2.3.4:5060
REGISTER sip:1.2.3.4 SIP/2.0.
Via: SIP/2.0/UDP 192.168.123.150:50600;rport;branch=z9hG4bK906580090.
From: <sip:sipwise1@172.17.10.50>;tag=1631756043.
To: <sip:sipwise1@172.17.10.50>.
Call-ID: 1235449552.
CSeq: 4 REGISTER.
Contact: <sip:sipwise1@192.168.123.150:50600;line=e779ddd40d3251b>.
Authorization: Digest username="sipwise1", realm="172.17.10.50",
nonce="4a06e2820000000a80c173db2d166fedb7d8d1e933c97855",
uri="sip:1.2.3.4", response="de645a701a7c507c47a5278923bce54b",
algorithm=MD5.
Max-Forwards: 70.
User-Agent: Linphone/2.1.1 (eXosip2/3.1.0).
Expires: 900.
Content-Length: 0.
U 1.2.3.4:5060 -> 192.168.123.150:50600
SIP/2.0 401 Unauthorized.
Via: SIP/2.0/UDP
192.168.123.150:50600;rport=50600;branch=z9hG4bK906580090;received=213.47.175.165.
From: <sip:sipwise1@172.17.10.50>;tag=1631756043.
To: <sip:sipwise1@172.17.10.50>;tag=a49efde55ae28efd11dc5969af09c5db.b607.
Call-ID: 1235449552.
CSeq: 4 REGISTER.
WWW-Authenticate: Digest realm="172.17.10.50",
nonce="4a06e2820000000b2bd307dd3e71c80e3d6549ccc2b28269".
Server: Sipwise registrar.
Content-Length: 0.
So the only thing referring to the public Firewall IP is in the R-Uri of
the registration and in the Authorization-uri-token. Is this token also
used to calculate the auth hashes somehow?
Yes, the uri="" parameter is also used for calculation of the response.
So, if this gets changed then there will be a problem.
Further, the proxy should compare the RURI with the uri="" parameter to
detect man-in-the-middle attacks. AFAIK this is not done in the code,
but needs to be done in the config.
regards
klaus
Username looks fine in the Authorization header, and
so does Realm. Any
ideas?
Andreas
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
5678
days inactive
5714
days old
7 comments
5 participants
participants (5)
-
Andreas Granig -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion