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