18 Mar
2004
18 Mar
'04
9:29 a.m.
Klaus Darilion wrote:
You can enhance the nat_uac_test to compare rport and
the port
announced in the via header.
This would be really nice! So far our setup using the nat_uac_test
catches about 95% of all NAT users that don't use STUN or have a problem
with it. But for the other 5% that are behind symmetic NATs, and the
rport and announced port in the VIA header are different, we have to
wait for the customer to complain in order for us to realize that he is
behind a symmetic NAT. Fortunately the SPA2000 now includes a new
parameter to check for this type of NAT but most of our installed based
still does not have it enabled.
-Andres
klaus
zeusng wrote:
--
Andres
Network Admin
http://www.telesip.net
Jiri,
I agree with you that the client is "broken" with STUN. However, what
if the
client is using some other method to determine the public IP of it's
NAT and
have no intention to check what kind of NAT its behind? It can send a
http
request somewhere get the ip via http reply, or it allows the user to
manually type in the public ip address?
Anyhow, what we want is to help resolving the NAT issue. According to
Section 4 of the Internet draft, "SIP Extensions for NAT Traversal",
"draft-ietf-sip-nat-01.txt", (which may have already expired), the
proxy is
to maintain a state of the connection and send the reply and other
request
via the rport.
Ok, it's draft only and not RFC yet (Maybe I'm wrong, but that's what I
know). However, SER is already doing the first part, sending reply
via the
rport. I just want to know whether I can do something to help this
"stupid"
or "intelligence" client behind NAT for other request.
Say, if I know that the port is different from the rport in the Via
header,
provided the request is not for call forwarding, there must be some port
translation in between.
E.g. Via: SIP/2.0/UDP y.y.y.y:5070;rport=60500;
Here, 5070 != 60500, so I would assume the client is behind some kind of
firewall or NAT. I need to tell the proxy that ongoing traffic should
go via
the rport.
Zeus
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
-----Original Message-----
From: Jiri Kuthan [mailto:jiri@iptel.org] Sent: Thursday, 18 March
2004 3:59 PM
To: zeusng; serusers(a)lists.iptel.org
Subject: Re: [Serusers] UA behind symmetric NAT advertising Public
address
At 05:17 AM 3/18/2004, zeusng wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Hi,
Is that a way to check the Top most Via rport with the sender's port?
I have a UA capable of detecting its symmetric NAT's public
address and
advertise it in the SIP message. Below is an
example of the
message. The device has private address 192.168.x.x and is set to
listen SIP message at port 5070, the NAT's public address is y.y.y.y,
the register
is listening at public address z.z.z.z port
5060.
UA1 192.168.5.5:5070 --> NAT (y.y.y.y:60500) --> Proxy z.z.z.z:5060
SEND >> z.z.z.z:5060
REGISTER sip:xyz.org SIP/2.0
Via: SIP/2.0/UDP
y.y.y.y:5070;rport;branch=z9hG4bKA38B122163B34FA9B039C915AA2ACB43
From: UA1 <sip:ua1@xyz.org>
To: UA1 <sip:ua1@xyz.org>
Contact: "UA1" <sip:ua1@y.y.y.y:5070>
Call-ID: F75DAF8081B44B62905C14B20CC7421C(a)xyz.org
CSeq: 7900 REGISTER
Expires: 1800
Max-Forwards: 70
User-Agent: Some SIP User Agent
Content-Length: 0
RECEIVE << z.z.z.z:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP
y.y.y.y:5070;rport=60500;branch=z9hG4bK381E2433E71D4FE995B208
FFD8AF8F15
From: UA1 <sip:ua1@xyz.org>
To: UA1 <sip:ua1@xyz.org>;tag=794fe65c16edfdf45da4fc39a5d2867c.8eac
Contact: "UA1" <sip:ua1@y.y.y.y:5070>
Call-ID: F75DAF8081B44B62905C14B20CC7421C(a)xyz.org
CSeq: 7900 REGISTER
Contact: <sip:ua1@y.y.y.y:5070>;q=0.00;expires=1800
Server: Sip EXpress router (0.8.12-tcp_nonb (i386/linux))
Content-Length: 0
Warning: 392 z.z.z.z:5060 "Noisy feedback tells: pid=18470
req_src_ip=y.y.y.y req_src_port=60500 in_uri=sip:xyz.org
out_uri=sip:xyz.org via_cnt==1"
Here, the client 192.168.5.5 (not show in the message) send
a message
with source address 192.168.5.5 source port 5070
to proxy
z.z.z.z port
5060. Because of some intellegence in the UA
(STUN in this case),
it determines that the public address of the NAT is y.y.y.y.
When contructing the Register request, it use the public IP
y.y.y.y in
the Via and Contact header. The message, upon
reaching the NAT, be
translated to have source address y.y.y.y and port 60500.
None of the
nat_uac_test() function can detect that the UA is
behide NAT
and thus
save the contact as sip:y.y.y.y:5070. The reply
of the
register is fine
as it follow the rport.
If however, someone invite this client, SER will return
sip:y.y.y.y:5070. Due to the nature of symmetric NAT, port 5070 is
block and cannot reach UA1.
Then "Some SIP User Agent" is broken. STUN can't be used with
symmetric NATs. y.y.y.y is of zero value.
-jiri
I know I can setup PAT to have all incoming
traffic with
port 5070 to
forward to 192.168.5.5 and make is looks like
restricted
cone NAT but
the NAT device is own by the customer and I have
no control.
Is there a way in SER that I can check the rport with the
source port,
if different, rewrite the contact as sip:[source
address]:[rport]?
Regards,
Zeus Ng, CISSP, CCSA
Principal Consultant
iSquare Technology
Tel: +61 2 9419 3887
Fax: +61 2 9410 2629
Mob: 0416 135 794
Email: zeus.ng(a)isquare.com.au
*************************************************************
*********
This email and any files transmitted with it are
confidential and
intended solely for the use of the individual or entity to whom
they are addressed.
If you have received this email in error, you are prohibited from
reading, copying, distributing and using the information. Please
contact the sender immediately by return email and destroy
the original
message.
******************************************************************
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/