[asterisk-users] Asterisk and several clients behind NAT

[Alex Balashov]

jonas kellens wrote:

> Is it possible to have several clients behind NAT to register to an 
> Asterisk-server with a public IP-address ?
> 
> When Asterisk receives an incoming call, how will it know @ which 
> private IP-address the client is reachable ?
> 
> I guess it is impossible for Asterisk to directly contact the private 
> client behind the NAT ?! Or to distinguish between the private clients ?!
> 
> Is there an easy solution to this ? How does hosted IP-PBX services work 
> then ?!

Yes, this problem has a solution.  The NAT gateway creates a UDP state 
mapping between internal source ports and external source (and 
destination, since most user agents are symmetrical nowadays) ports.

The NAT gateway then allocates different external UDP ports for 
different "connections" being tracked in this manner.

Consider, for example, two phones - 192.168.1.10 and 192.168.1.11 - 
registering to an outside SIP UAS through a NAT gateway whose public 
address is 67.194.23.55.  The NAT gateway maps the source ports in a 
random or pseudorandom manner akin to:

    192.168.1.10:5060 --> 67.194.23.55:32947
    192.168.1.11:5060 --> 67.194.23.55:47948

If far-end NAT traversal is enabled on the UAS (in the case of Asterisk, 
that's nat=yes in sip.conf), the Contact URI supplied in the REGISTER 
message is ignored and the actual "received" IP and port on the network 
and transport layer is used in its place.  The latter is what is stored 
as the contact binding.

Later, a call comes in and the UAS maps it back to 67.194.23.55:47948 or 
32947 depending on which registrant it is destined to go to.

This scenario is not without its problems.  Some user agents do not 
behave symmetrically.  Some firewall/NAT router ALGs (application layer 
gateways) break this process, though they mean well and try to be 
helpful.  But by far the most pressing problem is that many NAT gateways 
rather quickly age the temporary state information (internal:external 
UDP port mapping) out after a relatively short period of inactivity. 
That is why many far-end NAT traversal approaches implement a policy of 
periodically "pinging" the stored ("received") contact with some sort of 
message that causes a bidirectional exchange of communication, and 
therefore causes the NAT gateway to reset its expiration timer for that 
"connection" state.  In Asterisk, the OPTIONS messages generated when 
the qualify=yes option is enabled in sip.conf fulfill this function.

Hope that helps,

-- 
Alex Balashov
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671