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

[Steve Davies]

On 11 January 2012 15:43, Kevin P. Fleming <kpfleming at digium.com> wrote:
> 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.
>

Excellent. Thanks as always Kevin.

(Why am I not surprised about Cisco!)

Regards,
Steve