<span style="font-family: Arial, Helvetica, sans-serif; font-size: 10pt"><br />
<span style="font-family: tahoma,arial,sans-serif; font-size: 10pt;"><hr width="100%" size="2" align="center" />
<b>From</b>: "Steve Davies" <davies147@gmail.com><br />
<b>Sent</b>: Wednesday, January 11, 2012 12:51 PM<br />
<b>To</b>: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users@lists.digium.com><br />
<b>Subject</b>: Re: [asterisk-users] SIP and NAT best practices since recent changes?</span><br />
<br />
On 11 January 2012 15:43, Kevin P. Fleming <kpfleming@digium.com> wrote:<br />
> On 01/11/2012 05:29 AM, Steve Davies wrote:<br />
>><br />
>> Hi,<br />
>><br />
>> Since the recent update to the NAT configuration options and defaults<br />
>> in chan_sip.so, I am interested in any SIP/NAT best practices advice.<br />
>><br />
>> What I've always done in the past is:<br />
>><br />
>> Global: nat=no<br />
>> SIP handsets that are local: nat=no<br />
>> SIP handsets that are remote: nat=yes<br />
>> ITSP SIP trunks: nat=yes<br />
>><br />
>> I will then set externip and localnet to reflect the local setup,<br />
>> UNLESS there is a functional SIP ALG doing the work in the gateway<br />
>> device. I make this statement because I've found one or two firewalls<br />
>> where it is best to disable the SIP ALG, and one or two where it is<br />
>> best to leave it enabled.<br />
>><br />
>> The above always worked very well, but I now find my asterisk logs<br />
>> being spammed with warnings containing lots of "!!" and I'd like to<br />
>> know the best way to operate to achieve what I've always had while<br />
>> following the new rules in order to be as secure as possible with<br />
>> "clean" logs. I should add that we do not accept unsolicited<br />
>> connections, and 99% of attempts to connect will be stopped at the<br />
>> firewall.<br />
><br />
><br />
> The simplest answer is to always use 'nat=yes' (or at least<br />
> 'nat=force_rport' in recent versions of Asterisk that support it), until you<br />
> come across a SIP endpoint that fails to work properly with that setting. If<br />
> you do come across such an endpoint, try hard to get it to work with that<br />
> setting; if you can't, then set 'nat=no' for that endpoint, and understand<br />
> that the endpoint's name could be discoverable using the attack methods<br />
> previously disclosed. If the endpoint's configuration is suitably locked<br />
> down (permit/deny, for example) this may not be a concern for you. If it's<br />
> not locked down (for example, if it has to register to your Asterisk server<br />
> from random locations), then the next step would be to seriously consider<br />
> requesting that the user of that endpoint consider switching to some other<br />
> SIP endpoint.<br />
><br />
> To date, the only endpoints that have been identified that do *not* work<br />
> with Asterisk's 'rport' handling forced upon them are Cisco phones.<br />
><br />
<br />
Excellent. Thanks as always Kevin.<br />
<br />
(Why am I not surprised about Cisco!)<br />
<br />
Regards,<br />
Steve<br />
<br />
Steve<br />
<br />
I can't get my grandstream phones to work with force_rport behind a pfsense firewall. but yes and comedia work fine. <br />
<br />
Bryant</span>