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

[Bryant Zimmerman]

----------------------------------------

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. 


Bryant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120111/449bdb75/attachment.htm>