[Asterisk-Users] Asterisk behind NAT to SIP provider

[Rich Adamson]

> > I experimented a little bit and Asterisk behind NAT with SIP works. I created 
> > an account at iptel.org and use that account for outbound SIP traffic from
> > Asterisk.
> Great! I copied your information for other users to the Wiki.
> 
> http://www.voip-info.org/tiki-index.php?page=Asterisk%20sip%20client%20SER
> 
> Now, I have to check why it doesn't work on my Asterisk. Propably newbie behind
> console keyboard, but anyway...

There has been a fair amount of discussion on the list as to whether nat
works with various/different configurations of sip phones with *. The
"exact" configuration required is highly dependent on a number of technical
factors that must be well understood before anyone can make a generic
statement relative to whether it works or doesn't work. Without that
understanding, practically every statement made on the list has been 
based on opinion and/or some trial & error methodology that has resulted
in a working example. (Nothing wrong with that, but the majority of the
postings leave out critical info that causes the next person to attempt
the same implementation but fails, and additional questions are generated.)

The critical information needed to understand nat config's include:
1. Is * behind a nat box, sip phone behind a nat box, or both?
2. Is the nat box "sip aware"?
3. Can the nat box be programmed to forward a static "range" of ports 
   to the "inside"?
4. Are there two nat boxes involved (one at each end of an expected
   sip-based connection)?
5. Does the sip phone support nat (eg, play nice with headers)?
6. Does * support nat (eg, play nice with headers) and is it config'ed?
7. Are there timers involved at either end of a nat traversal that
   are intended to keep nat table entries from timing out?
8. If so, what are the actual timeout values used for the specific
   nat box, and are sip end-point timers less then those of the nat
   box? (Don't assume all sip phones with nat functions are equal.)
9. What is the nat impact of a sip phone that has been configured to 
   re-register every 60 seconds?
10. What is the range of rtp ports expected by the sip phone (eg, 7960's
    range from 16384 to 32766, but can be changed; xten uses 8000
    to 8012 or something like that)?
11. Can the user implement iax (instead of sip) between end points?
12. When nat is found to function correctly, which end "originated"
    the nat traversal (makes a BIG difference)?
And, probably another half dozen technical parameters that I'm forgetting
to mention.

I've spent many years working with corporate clients in more then 40
states diagnosing networking issues, doing protocol analysis, etc, and
have seen a large number of nat boxes. The nat implementations from
various vendors range from very basic translation tables to some rather
sophisticated functions. And, just because a nat implementation comes
from a well-known vendor doesn't mean anything (even Cisco has problems
with "no" nat timeouts in certain boxes today).

With that said, here's a couple of high-level examples that "could" 
work but these are not based on actual lab tests, etc.

1. If * is behind a nat box "and" * inititiates a tcp/udp conversation
   with a non-nat'ed address, some form of timer-based keep alive
   packet will keep the nat-box-table-entries active allowing the
   implementation to work. (Obviously assumes equipment can support
   sip header functions.) What are some of the configuration issues
   that may need to be addressed?
   a. limit the port numbers that can be used by * (rtp.conf)
   b. limit the port numbers that can be used by the sip phone.
   c. may still need to map the specific rtp port range in the nat
      box depending upon the nat box functionality.
   d. probably define nat=yes within *.
   (The real issue here is "which end initiated" the conversation
   and what is used to keep the nat translations active. I think we've
   already heard some folks doing this with certain Internet-based
   companies, but the postings left out a bunch of technical 
   configuration data on both ends.)

2. * => nat => Internet => nat => sip phone
   Implement a combination of #1, above, at both ends assuming the 
   end-point equipment has the capability to be configured (including
   the sip phone, nat boxes, etc).

What tends to aggravate nat implementations are those NAT boxes that
also implement PAT (port address translation), and the box vendor doesn't
bother to hint at it in their documentation. (There are a very large
number of networking folks that don't understand this, and its probably
safe to assume 99.99% of the user community has never heard of it.)
The PAT issues usually end up with someone suggesting sip phone #1 works 
but #2 doesn't and they are configured exactly the same. Or, call #1 
works but call #2 fails. (And then the next person on the list says
it works fine for them, but doesn't mention who's nat box he's using
or what it's actually doing from a technical perspective.) 

I'd bet a small amount of money that Jan's example config fails under 
certain circumstances possibly including use of a different nat box, 
second sip phone, second phone call, etc.

I think its fair to suggest that it would be nice to have working nat
configurations documented, but it has to include a lot more specific
info then just the * and sip phone config data. Working config's are
out there, just need to gather config data from "all" components.

Any volunteers? (may need to use a Sniffer/ethereal to document the
actual ports used, etc.)

<crawls off soap box and hides behind a nat box to avoid flames>