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

Greger V. Teigre greger at teigre.com
Mon Apr 4 08:03:18 CEST 2005


Ask Paul and he'll say yes, but he mostly supports ATAs with public IPs and 
only occasionally meet an IP phone behind a NAT.  I actually use STUN, but I 
have tested the behavior for each client (and each firmware).  This reduces 
the number of proxied sessions to those where a symmetric NAT is involved.
g-)

Iqbal wrote:
> 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 




More information about the sr-users mailing list