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

[Mohammad Khan]

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
>  
>