[Serusers] UA behind symmetric NAT advertising Public address

Thu Mar 18 09:11:07 CET 2004

You can enhance the nat_uac_test to compare rport and the port announced 
in the via header.

klaus

zeusng wrote:

> 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
> 
> 
>>-----Original Message-----
>>From: Jiri Kuthan [mailto:jiri at iptel.org] 
>>Sent: Thursday, 18 March 2004 3:59 PM
>>To: zeusng; serusers at lists.iptel.org
>>Subject: Re: [Serusers] UA behind symmetric NAT advertising 
>>Public address
>>
>>
>>At 05:17 AM 3/18/2004, zeusng wrote:
>>
>>>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 at xyz.org>
>>>To: UA1 <sip:ua1 at xyz.org>
>>>Contact: "UA1" <sip:ua1 at y.y.y.y:5070>
>>>Call-ID: F75DAF8081B44B62905C14B20CC7421C at 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 at xyz.org>
>>>To: UA1 <sip:ua1 at xyz.org>;tag=794fe65c16edfdf45da4fc39a5d2867c.8eac
>>>Contact: "UA1" <sip:ua1 at y.y.y.y:5070>
>>>Call-ID: F75DAF8081B44B62905C14B20CC7421C at xyz.org
>>>CSeq: 7900 REGISTER
>>>Contact: <sip:ua1 at 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 at 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 at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
>>
>>--
>>Jiri Kuthan            http://iptel.org/~jiri/ 
>>
> 
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
> 