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

[sean darcy]

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?

sean