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

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" &lt;greger(a)teigre.com&gt; 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" &lt;info(a)beeplove.com&gt; 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@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@sip.dom.com>;tag=3a7ceb24a6ac50c4. >>>>To: <sip:040600@sip.dom.com>. >>>>Contact: <sip:040618@223.178.140.109:1024>. >>>>Supported: replaces. >>>>Call-ID: 7f2c327896a5b0e1(a)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 &gt;&gt;&gt;&gt;serusers(a)lists.iptel.org >>>>http://lists.iptel.org/mailman/listinfo/serusers >>>> >>>> >>>> >>>> >>> >>> >>> >>_______________________________________________ >>Serusers mailing list &gt;&gt;serusers(a)lists.iptel.org >>http://lists.iptel.org/mailman/listinfo/serusers >> >>