[asterisk-users] Should you "ever" use nat=no?

[Kevin P. Fleming]

On 02/19/2012 09:42 AM, sean darcy wrote:
> On 02/16/2012 12:30 PM, Kevin P. Fleming wrote:
>> On 02/11/2012 06:59 PM, Bruce B wrote:
>>> If your server is open to the internet and in SIP general section you
>>> have nat=no and in peers you have nat=yes or vice versa then it's
>>> possible to enumerate your extension. Because Asterisk responds with
>>> different messages if the extension exists or not based on that
>>> difference in the nat setting then it's possible to tell if an extension
>>> 100 exists or not. Over the past few years, Digium has come to
>>> realization to respond to all unauthenticated calls the same way in
>>> order to thwart any attack attempts or guesses on the extension but it's
>>> still not perfect yet as these improvements are done at a really slow
>>> pace. Regardless, they are being made and there truely is a security
>>> risk.
>>
>> "really slow pace"? Please point out any one of these issues that took
>> an unnecessarily long time to resolve once it was identified and brought
>> to the development team's attention.
>>
>>>
>>> I always use nat=yes. I don't even know why nat=no exists as there is
>>> nothing that can't be done with nat=yes. Plus nat=yes will take care of
>>> some of the surprise one-way audio scenarios as well so why use nat=no
>>> at all?! I vote to totally get rid of the nat setting all together and
>>> hard code it and set it to yes but again there are others who may not
>>> agree.
>>
>> As was already pointed out in the discussions that lead up to the 'nat'
>> default being changed, there are SIP endpoints out there that do not
>> work properly with 'nat=yes' (or 'nat=force_rport'). They behave
>> improperly when Asterisk adds an 'rport' parameter to the top-level Via
>> header in its responses. Setting 'nat=no' is the only way to keep this
>> from happening.
>>
>
> So in my case, these 40 internal sip devices (primarily aastra), which
> are not nat'd with respect to asterisk, should all be nat=yes unless
> they are unable to deal with the rport parameter? And if they are
> unable, setting nat=yes would immediately break them? If not, what are
> the symptoms of being unable to behave properly with the rport parameter?

You are correct on both points. It is doubtful that your endpoints will 
misbehave with 'force_rport' enabled (or its equivalent in older 
versions), but if they do, it will be immediate (and not subtle).

-- 
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