asterisk users - Jan 2012 - SIP and NAT best practices since recent changes?

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.

Thanks,
Steve

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.

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

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

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>