[asterisk-users] SIP and NAT best practices since recent changes?

[Kevin P. Fleming]

On 01/11/2012 05:29 AM, Steve Davies wrote:
> Hi,
>
> Since the recent update to the NAT configuration options and defaults
> in chan_sip.so, I am interested in any SIP/NAT best practices advice.
>
> What I've always done in the past is:
>
> Global: nat=no
> SIP handsets that are local: nat=no
> SIP handsets that are remote: nat=yes
> ITSP SIP trunks: nat=yes
>
> I will then set externip and localnet to reflect the local setup,
> UNLESS there is a functional SIP ALG doing the work in the gateway
> device. I make this statement because I've found one or two firewalls
> where it is best to disable the SIP ALG, and one or two where it is
> best to leave it enabled.
>
> The above always worked very well, but I now find my asterisk logs
> being spammed with warnings containing lots of "!!" and I'd like to
> know the best way to operate to achieve what I've always had while
> following the new rules in order to be as secure as possible with
> "clean" logs. I should add that we do not accept unsolicited
> connections, and 99% of attempts to connect will be stopped at the
> firewall.

The simplest answer is to always use 'nat=yes' (or at least 
'nat=force_rport' in recent versions of Asterisk that support it), until 
you come across a SIP endpoint that fails to work properly with that 
setting. If you do come across such an endpoint, try hard to get it to 
work with that setting; if you can't, then set 'nat=no' for that 
endpoint, and understand that the endpoint's name could be discoverable 
using the attack methods previously disclosed. If the endpoint's 
configuration is suitably locked down (permit/deny, for example) this 
may not be a concern for you. If it's not locked down (for example, if 
it has to register to your Asterisk server from random locations), then 
the next step would be to seriously consider requesting that the user of 
that endpoint consider switching to some other SIP endpoint.

To date, the only endpoints that have been identified that do *not* work 
with Asterisk's 'rport' handling forced upon them are Cisco phones.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org