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

[Greger V. Teigre]

Correct, and if you have a GW supporting connection-oriented media, you can 
use direction=active and get rid of all IP-PSTN, PSTN-IP calls.
g-)

Iqbal wrote:
> Okay so in order to get is straight
>
> 1. You can use just SER to deal with all types of NAT, this means that
> mediaproxy will get hit
> 2. You can use STUN, to get rid of clients which are asymmetric (is
> there alist of these...in fact will post with new topic)
> 3. Or you can ensure none of ur clients use NAT :-)
>
> Iqbal
>
> Greger V. Teigre wrote:
>
>> 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
>>>>
>>
>>
>> .