[asterisk-users] Update peer IP address

Thu Apr 2 16:21:50 CDT 2015

That sounds like asterisk was working 100% correctly.  If you receive an
INVITE from an unknown IP address, then it should fail.  Unless you want to
allow anonymous, which is genearlly a very bad idea.

If you are registering to IP X, but the provider may be transmitting
invites from any number of other IP addresses, then you need a list of IP
addresses, and have a trunk configuration set up for each one so that they
are all recognized (with insecure=port,invite).

If the provider is requiring you to accept invites from random IP
addresses, get a new provider.

On Thu, Apr 2, 2015 at 3:23 PM, Daniel Heckl <daniel.heckl at gmail.com> wrote:

> Okay, Scott, I think we are on the wrong path. Maybe I'm wrong though.
>
> I will summarize again briefly the problems together:
>
>    - The peer ip address could be another than the ip address of incoming
>    invites
>    - After an re-register the REGISTER is send to the new SIP server,
>    answered with OK. But the peer ip address is still the old one (sip show
>    peers).
>    - If now is a INVITE, the request is answered with 401 Unauthorized.
>
>
> That’s why I would say, the problem is not the port or a needed
> authentication. My Asterisk works behind a NAT without port forwarding and
> nat=no, I have qualify=yes that it does not come to a NAT timeout.
>
> Here is an example. The peer ip address was at this time 217.0.23.100, the
> INVITE came from 217.0.23.68 an was rejected with 401 Unauthorized:
>
> INVITE sip:06123456789 at 80.000.111.222:45061 SIP/2.0
> Max-Forwards: 58
> Via: SIP/2.0/UDP 217.0.23.68:5060
> ;branch=z9hG4bKg3Zqkv7ib7h2smv8whryjnos88srot1i7
> To: <sip:6123456789 at telekom.de>
> From: <sip:+49123456789 at tel.t-online.de;user=phone>;tag=h7g4Esbg_44c62525
> Call-ID: af71bbfbf269b895 at 62.155.0.75
> CSeq: 3950540 INVITE
> Contact: <sip:sgc_c at 217.0.23.68;transport=udp>
> Record-Route: <sip:217.0.23.68;transport=udp;lr>
> Min-Se: 900
> P-Asserted-Identity: <sip:+49123456789 at tel.t-online.de;user=phone>
> Session-Expires: 3600
> Supported: histinfo
> Supported: timer
> Supported: norefersub
> Content-Type: application/sdp
> Content-Disposition: session
> Content-Length: 204
> Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REFER, REGISTER,
> UPDATE
>
> v=0
> o=- 0 0 IN IP4 217.0.23.68
> s=-
> c=IN IP4 217.0.4.134
> t=0 0
> m=audio 36480 RTP/AVP 9 8 102
> a=rtpmap:9 G722/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:102 telephone-event/8000
> a=maxptime:20
> a=ptime:20
>
> Am 02.04.2015 um 22:00 schrieb Scott Griepentrog <sgriepentrog at digium.com
> >:
>
> Actually, the IP address is still used to identify the incoming invite.
> With the insecure=port option set, Asterisk will presume the invite to
> still match the trunk account even if the NAT router has mangled (changed)
> the port number.  My suspicion is that when the new register goes out, it's
> creating a new state in the firewall, resulting in a new port number, which
> is why you would have to allow anonymous calls to then accept it without
> insecure=port.  The other possibility is that you have a port forward in
> the router set, which is similarly mangling the port number.  With a valid
> registration being held, and assuming the router does not drop UDP states
> faster than 30 minutes, and also assuming that the provider is sending you
> invites on the registered port rather than always on 5060, there should not
> be a need for an inbound port forward to Asterisk, and you should not need
> insecure=port.
>
> The invite option disables authentication - which means only that Asterisk
> will not force a check of the password on the other end.  Where the IP
> address is well known and trusted, the extra overhead and delay of
> authenticating incoming INVITEs is not needed.
>
>
>
> On Thu, Apr 2, 2015 at 2:28 PM, Daniel Heckl <daniel.heckl at gmail.com>
> wrote:
>
>> Scott, I have changed the configuration as said it and will test it. I’m
>> curious.
>>
>> Can you briefly explain what insecure=invite,port does?
>>
>> ;insecure=port ; Allow matching of peer by IP address without
>> ; matching port number
>> ;insecure=invite ; Do not require authentication of incoming INVITEs
>> ;insecure=port,invite ; (both)
>>
>> Do I understand correctly that in this mode the IP address is not checked
>> and no authentication is required?
>>
>> Am 02.04.2015 um 20:11 schrieb Scott Griepentrog <sgriepentrog at digium.com
>> >:
>>
>> I'd be curious if setting
>>
>> insecure=invite,port
>>
>> makes any difference either (without alllowguest on).
>> 
>>
>> On Thu, Apr 2, 2015 at 9:03 AM, Daniel Heckl <daniel.heckl at gmail.com>
>> wrote:
>>
>>> Ok, I have tested dnsmgr. This is not a solution, the situation has not
>>> changed. With dnsmgr I can not place outbound calls. I do not know why and
>>> what dnsmgr really do.
>>>
>>> My current solution is as follows:
>>>
>>> Say allowguest=yes, configure the default context that there can not be
>>> placed outbound calls. Use iptables to DROP all at your SIP port and allow
>>> only your local phones and the sip trunk ip range. I think srvlookup must
>>> be set to yes to place outbound calls if there is an ip address change.
>>>
>>> I think with the restriction of the firewall that should be a secure
>>> solution.
>>>
>>> > Am 01.04.2015 um 19:23 schrieb Sebastian Kemper <sebastian_ml at gmx.net
>>> >:
>>> >
>>> > On Wed, Apr 01, 2015 at 11:00:56AM -0400, Andres wrote:
>>> >> On 4/1/15 10:48 AM, Daniel Heckl wrote:
>>> >>> John,
>>> >>>
>>> >>> thank you four your answer. I think you have misunderstood the
>>> >>> problem. It’s about a ip address change of the sip trunk, not of my
>>> >>> asterisk server.
>>> >> You would probably benefit by enabling the DNS Manager to allow for
>>> >> dynamic IP changes:
>>> >>
>>> >> # cat dnsmgr.conf [general] enable=yes             ; enable creation
>>> >> of managed DNS lookups ;   default is 'no' refreshinterval=180   ;
>>> >> refresh managed DNS lookups every <n> seconds ;   default is 300 (5
>>> >> minutes)
>>> >
>>> > Hello Andres,
>>> >
>>> > I read that same suggestion elsewhere in connection with Deutsche
>>> > Telekom, so it seems there's some benefit in it.
>>> >
>>> > Daniel, did you try it out already?
>>> >
>>> > Kind regards,
>>> > Sebastian
>>> >
>>> > --
>>> > _____________________________________________________________________
>>> > -- 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
>>>
>>>
>>> --
>>> _____________________________________________________________________
>>> -- 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
>>>
>>
>>
>>
>> --
>> [image: Digium logo]
>> Scott Griepentrog
>> Digium, Inc · Software Developer
>> 445 Jan Davis Drive NW · Huntsville, AL 35806 · US
>> direct/fax: +1 256 428 6239 · mobile: +1 256 580 6090
>> Check us out at: http://digium.com · http://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
>>
>>
>>
>> --
>> _____________________________________________________________________
>> -- 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
>>
>
>
>
> --
> [image: Digium logo]
> Scott Griepentrog
> Digium, Inc · Software Developer
> 445 Jan Davis Drive NW · Huntsville, AL 35806 · US
> direct/fax: +1 256 428 6239 · mobile: +1 256 580 6090
> Check us out at: http://digium.com · http://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
>
>
>
> --
> _____________________________________________________________________
> -- 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
>

-- 
[image: Digium logo]
Scott Griepentrog
Digium, Inc · Software Developer
445 Jan Davis Drive NW · Huntsville, AL 35806 · US
direct/fax: +1 256 428 6239 · mobile: +1 256 580 6090
Check us out at: http://digium.com · http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20150402/ec7bd418/attachment.html>