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

[Kevin P. Fleming]

On 01/11/2012 12:09 PM, Bryant Zimmerman wrote:
>
> ------------------------------------------------------------------------
> *From*: "Steve Davies" <davies147 at gmail.com>
> *Sent*: Wednesday, January 11, 2012 12:51 PM
> *To*: "Asterisk Users Mailing List - Non-Commercial Discussion"
> <asterisk-users at lists.digium.com>
> *Subject*: Re: [asterisk-users] SIP and NAT best practices since recent
> changes?
>
> 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
>
> Steve
>
> I can't get my grandstream phones to work with force_rport behind a
> pfsense firewall. but yes and comedia work fine.

That's rather strange, since 'yes' includes 'force_rport'. Can you 
describe what 'not work' means in this case?

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