On 01/11/2012 12:09 PM, Bryant Zimmerman wrote:
------------------------------------------------------------------------
*From*: "Steve Davies" <davies...@gmail.com>
*Sent*: Wednesday, January 11, 2012 12:51 PM
*To*: "Asterisk Users Mailing List - Non-Commercial Discussion"
<asterisk-users@lists.digium.com>
*Subject*: Re: [asterisk-users] SIP and NAT best practices since recent
changes?
On 11 January 2012 15:43, Kevin P. Fleming <kpflem...@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: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
