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

Iqbal iqbal at gigo.co.uk
Mon Apr 4 13:41:04 CEST 2005 

Okay missed a trick here. On the handytone 488, its has a wan and lan 
port. Now I tested this with a Kcorp adsl modem/router.

Plugged the wan of ATA into adsl router, and the LAN was disconnected 
since the Network is connected over wireless to the Kcorp.

In ur setup u say that it gets a external IP, however I cant see how, 
since the broadband router will get the external IP address, and not 
whats connected to it. Mine still gets a internal IP address...

Iqbal
Java Rockx wrote:

>Greger is correct about me "mostly supporting" ATAs with public IPs.
>
>Our approach is the 80/20 rule. We ship UTstarcom iAN-02EX ATAs which
>have full router support (ie, they have a WAN and LAN interface). We
>encourage our customers to connect the WAN port directly to their
>broadband router and then connect their home network to the LAN port
>of the ATA.
>
>This allows us to route most RTP traffic away from our network, which
>is smart for scaling your VoIP platform.
>
>In cases where a customer connectes their WAN port of the ATA to their
>home network, the ATA then gets an RFC1918 IP address, and we must
>proxy all RTP streams for that customer.
>
>Again, we're shooting for the 80/20 rule. If we convince 80% of our
>customers to hook up their ATA "correctly" then our infrastructure is
>less stressed.
>
>Regards,
>Paul
>
>On Apr 4, 2005 2:03 AM, Greger V. Teigre <greger at teigre.com> 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
>>>>>          
>>>>>
>>_______________________________________________
>>Serusers mailing list
>>serusers at lists.iptel.org
>>http://lists.iptel.org/mailman/listinfo/serusers
>>
>>    
>>
>
>.
>
>  
>

More information about the sr-users mailing list