[Serusers] NAT NAT..and a little more NAT

Sun Apr 3 17:11:54 CEST 2005

Thanks Greg, so from what I understand its better NOT to use STUN, and do
fat end traversal all the time, i.e do it at SER level whether its
asymmetric or symmetric

Iqbal

On 4/3/2005, "Greger V. Teigre" <greger at teigre.com> wrote:

>Iqbal wrote:
>> maybe well written but I have come across another question, in the
>> ser.cfg file on onsip it mentions that with correct use of the
>> mediaproxy you can deal with asymmetric and symmetric, hence my
>> summary may be wrong.
>
>No, your summary is correct.  The config files in the onsip.org document
>have the assumptions that STUN is NOT used.  Hence, all NATed devices will
>be proxied.  When STUN is used, it is transparent and the config files will
>see the client as non-NATed.
>
>> Symmetric CANNOT go through STUN, it wont work. hence the STUN is no
>> use, and yes then ser will see it as natted.
>
>One big problem is that many clients have faulty STUN implementations, even
>specific firmware can have problems (Grandstream changed its behavior to
>wrong handling of symmetric NAT in 10.5.16, I think).
>
>In fact, it is possible both to detect (some of) these faulty
>implementations (i.e. faulty handling of symmetric NAT, ex. using test 16 in
>nathelper), but not if ex. a full-cone is detected when in fact, it's a
>restricted NAT. (Let me add that there also are many
>mutations/implemenations of the four NAT types that can confuse STUN...)
>
>Conclusion: ALWAYS test the clients you want to use with STUN!
>
>We are considering adding an appendix with advanced NAT techniques in
>ser.cfg including on where you can use STUN (test your clients) as well as
>direction=active supported PSTN gateways (used to allow non-proxied outgoing
>calls from a call behind a symmetric NAT) to reduce the proxied calls to the
>following:
>- SIP-SIP when one or both are behind symmetric
>- PSTN-SIP when the SIP client is behind symmetric
>
>We'll see when we get the time. There are lots of more basic stuff we need
>to do first.
>g-)
>
>> If asymmetric comes via STUN, and the client understands what the STUN
>> server has sent back, and can fix itself then ser will NOT see it has
>> natted, since its been fixed
>>
>> Iqbal
>>
>> On 4/2/2005, "Mohammad Khan" <info at beeplove.com> wrote:
>>
>>> Very nice and well written, Many many thanks.
>>>
>>> One question,
>>> If a client from Assymetric NAT and it comes through STUN, does SER
>>> see that client as a *nated* client?
>>> And,
>>> if a client from Symentric NAT and it still comes through STUN, SER
>>> see that client as Nated client, right?
>>>
>>>
>>> See below:
>>>
>>>
>>>
>>> Iqbal wrote:
>>>
>>>> Heres my understanding...hope it helps (may even confuse), and
>>>> looking for corrections...its a long read
>>>>
>>>> 1. There are 4 different types of NAT
>>>> a) Full Cone
>>>> b) restricted cone
>>>> c) port restricted
>>>> d) symmetric
>>>>
>>>> a,b,c are also referred to as asymmetric NAT.
>>>>
>>>> 2. SIP has a problem because the siganalling uses one path and the
>>>> media stream another.
>>>>
>>>> 3. Full cone - Anyone of the internet can send packets to the
>>>> IP:port combo, this is mapped to a internal IP:port.
>>>>
>>>> 4. Restricted Cone - Only those external PC which have been
>>>> contacted are ALLOWED to contact via the mapping, i.e if I contact
>>>> PC(a) from internal Ip 10.1.1.1:123 then PC(a) can contact me on
>>>> that NAT mapping, PC(b) cannot
>>>>
>>>> 10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(a)
>>>> If pc(b) sends to 202.70.65.78:10000 there will be nothing sent
>>>> through to 10.1.1.1:123
>>>>
>>>> 5. Port restricted Cone - Same as restricted but instead of just
>>>> detecting that the source IP is that of pc(a), it also looks to see
>>>> if the source port is the same
>>>>
>>>> 10.1.1.1:123 --->NAT---->202.70.65.78:10000 -----> pc(a)
>>>> [213.123.324.34:8000]
>>>>
>>>> The nat will only accept inbound from 213.123.324.34 and if it
>>>> comes from port 8000
>>>>
>>>> 6. Symmetric - This is the easy one,
>>>>
>>> 10.1.1.1:1000 ----NAT -----> 200.123.123.34:1234 ----pc(a)
>>>
>>> 10.1.1.1:1000 ----NAT -----> 200.123.123.34:2222----pc(b)
>>>
>>>            ^^
>>> you mean 10.1.1.x ( x is other than 1), right?
>>> I think, this was a typo.
>>>
>>> Thanks,
>>> Mohammad
>>>
>>>
>>>> In the NAT the IP:port pair is different for each external client,
>>>> so eeach external client has a mapping of its own
>>>>
>>>> 7. The problem RTP
>>>>
>>>> In RTP the message body has the info needed for the UA to
>>>> communicate successfully. This body is called the SDP message. The
>>>> problem is that the client doesnt know anything about the NAT,
>>>> hence the IP addresses which are contained in the SDP are usually
>>>> the internal ones, i.e what the client knows....so when the
>>>> endpoints want to "talk" they look at the IP in the message and you
>>>> get nothing because these are usually internal IP addresses.
>>>>
>>>> EG
>>>>
>>>> INVITE sip:040600 at 192.168.20.2:5060 SIP/2.0.
>>>> Record-Route: <sip:143.248.130.35;ftag=3a7ceb24a6ac50c4;lr=on>.
>>>> Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0.
>>>> Via: SIP/2.0/UDP
>>>> 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
>>>> From: "Iqbal" <sip:040618 at sip.dom.com>;tag=3a7ceb24a6ac50c4.
>>>> To: <sip:040600 at sip.dom.com>.
>>>> Contact: <sip:040618 at 223.178.140.109:1024>.
>>>> Supported: replaces.
>>>> Call-ID: 7f2c327896a5b0e1 at 192.168.20.3.
>>>> CSeq: 8717 INVITE.
>>>> User-Agent: Grandstream HT487 1.0.5.18.
>>>> Max-Forwards: 16.
>>>> Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
>>>> Content-Type: application/sdp.
>>>> Content-Length: 343.
>>>> .
>>>> v=0.
>>>> o=040618 8000 1 IN IP4 192.168.20.3.
>>>> s=SIP Call.
>>>> c=IN IP4 192.168.20.3.
>>>> t=0 0.
>>>> m=audio 38660 RTP/AVP 0 8 4 18 2 15 99.
>>>> a=sendrecv.
>>>> a=rtpmap:0 PCMU/8000/3.
>>>> a=rtpmap:8 PCMA/8000/3.
>>>>
>>>>
>>>> This header is just like email headers hence u read it backwards,
>>>> so if you look at the line above the From: line you see the first
>>>> Via, which is what the client thinks it is i.e 192.168.20.3, BUT
>>>> the proxy is clever, it knows where it received the message from ,
>>>> and it adds the rport and received tags
>>>>
>>>> Via: SIP/2.0/UDP
>>>> 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
>>>>
>>>> Soooo the proxy can talk SIP fine, because it knows these IP
>>>> addresses.
>>>>
>>>> BUT...poor old RTP is stuck because its headers or should I say
>>>> direction is held lower down :
>>>>
>>>> v=0.
>>>> o=040618 8000 1 IN IP4 192.168.20.3.
>>>> s=SIP Call.
>>>> c=IN IP4 192.168.20.3.
>>>> t=0 0.
>>>> m=audio 38660 RTP/AVP 0 8 4 18 2 15 99.
>>>> a=sendrecv.
>>>> a=rtpmap:0 PCMU/8000/3.
>>>> a=rtpmap:8 PCMA/8000/3.
>>>>
>>>> The client expects to receive on port m=38660 and IP c=
>>>> 192.168.20.3, which is where the other endpoint will try to send
>>>> "voice" to.
>>>>
>>>> 8 Solution - You need to tell the client, not to act so dumb, and
>>>> work out what the NAT settings are and put them in the SDP section
>>>> of the message. So the client can ask the NAT....or it can ask
>>>> someone on the outside what it should be.
>>>>
>>>> 9. Ask the NAT - use UPnP...I dont have much info on this..:-)
>>>>
>>>> 10. Ask someone on the outside --
>>>> You send a probe packet to the server sitting outside, it then
>>>> sends a message back, with the details it received, the client then
>>>> decides if its behind a NAT. This can be used for all 4 cases of
>>>> NAT.
>>>>
>>>> EG lets say we send out a packet from 10.1.1.1:1000 so in the SDP
>>>> message m=1000 and c=10.1.1.1, but if I send out a probe first, and
>>>> I get back 212.134.123.23:12345 then I can rewrite the SDP so
>>>> m=12345 and c=10.1.1.1 , simple
>>>>
>>>> Problem -- Since NAT settings are dynamic, and hence tend to
>>>> change, you really need to get the SIP message out very soon after
>>>> sending the probing message out,
>>>>
>>>> The client send and receive ports must be the same
>>>>
>>>> And....if you recall the restricted cones (port restricted
>>>> included) will not allow replies unless there has been a packet
>>>> sent out to that destination first, hence the client needs to send
>>>> a packet out to the endpoint, b4 he can be allowed in via the NAT
>>>> (but we dont need to worry about that)
>>>>
>>>> IT WILL NOT WORK FOR SYMMETRIC NAT....because it wont :-), because
>>>> the external UA IP:port is different to that where we sent the
>>>> probe, hence the voice packet coming back will not have the correct
>>>> path set.
>>>>
>>>> 11. The above is usually done with a STUN server, and sending the
>>>> packet out to this server
>>>>
>>>> 12. Symmetric NAT--- use a relay in the middle...Nathelper+
>>>> rtpproxy or mediaproxy
>>>>
>>>> 13 Nathelper
>>>> a) fix_nated_contact - rewrites contact Hf to source IP:port
>>>> b) fix_nated_sdp - rewritres media IP and also direction ????
>>>> c) force_rtp_proxy - forces media to go through proxy
>>>> d) nat_uac_test - mode=1 then as shown above the "received" header
>>>> is compared to c= in sdp
>>>> mode=2 then the Contact header is looked at to see if its private
>>>> mode=3 (1+2) means it does both of the above
>>>>
>>>>
>>>> 14) mediaproxy is much the same...and good examples are available
>>>>
>>>> 15)Summary
>>>>
>>>> 4 types of NAT, which can be combined into 2 main sets, asymmetric
>>>> and symmetric.
>>>>
>>>> Asymmetric issues can be resolved by using STUN, hence no need for
>>>> mediaproxy/nathelper
>>>> Symmetric clients cant use STUN, hence u need to use
>>>> mediaproxy/nathelper (or some other server end...also known as
>>>> far-end nat traversal solution)
>>>>
>>>> However if you didnt want to use STUN and mediaproxy/nathelper,
>>>> then you could just use mediaproxy/nathelper and setup port
>>>> forwarding on your NAT device.
>>>>
>>>>
>>>> I think that covers most, any suggestions let me know, I wrote this
>>>> for my own use, but if its useful, I'll tidy it up.
>>>>
>>>> One question....
>>>>
>>>> Is there any way via a debug log, albeit, ngrep, tcpdump,
>>>> sip_scenario display that I can from the server side detect if the
>>>> NAT is asymmetric or Symmetric.
>>>>
>>>> tks
>>>> Iqbal
>>>>
>>>> _______________________________________________
>>>> Serusers mailing list
>>>> serusers at lists.iptel.org
>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>
>>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Serusers mailing list
>> serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>