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

[Greger V. Teigre]

Iqbal,
Excellent summary!  There are many good NAT whitepapers on the net.  Here is 
one that is short and clear that elaborates on your summary:
http://corp.deltathree.com/technology/networkaddress.asp
g-)

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