Here’s the little challenge that is driving me batty (new install of FreePXB)…
I have a DID number forwarded to my network. Asterisk authorises the user, then puts the call into the ‘unknown peers’ call flow.
I can capture the call for any given ip address of their.net (although, I have the additional problem of it then going to call terminated). But, not if I specify host=dynamic – it then goes to no user.
See below: I have substituted my.asterisk.net, their.net and OKUSER for their real equivalents.
(((
[2014-10-10 11:06:44] SECURITY[1884] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“1412735604-825632”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID=“OKUSER”,SessionID=“0x967467c”,LocalAddress=“IPV4/UDP/my.asterisk.net/5060”,RemoteAddress=“IPV4/UDP/their.net.130/5060”,UsingPassword=“1”
[2014-10-10 11:06:44] VERBOSE[27675][C-000000a1] pbx.c: – Executing [OKUSER@from-sip-external:1] NoOp(“SIP/their.net.165-0000009a”, “Received incoming SIP connection from unknown peer to OKUSER”) in new stack)))
Please advise how I can get this connection to be accepted (i.e. not an unknown peer).
Their.net.NNN can be any one of 2048 addresses – and I’m hoping not to enter 2048 peers!
My (possibly perverted) logic reckons that there must be some way of configuring this connection to be accepted, especially since it has passed user authentication.
It seems unlikely that any ITSP would authenticate as a user. Are you sure you don’t mean that you have authenticated with them?
Generally people put insecure=invite precisely because ITSPs never authenticate themselves.
If you have a strange ITSP that does authenticate, I think you need to provide the contents of the INVITE you receive from them, together with your sip.conf entries. Please mangle any authentication data, including in the INVITE, but not so much as to hide its presence.
I’m not entirely sure that I understand your question, but I think you’re saying that you want to allow incoming calls from unknown peers on your PBX. If that’s correct, you’ll need to:
Change “Allow Anonymous Inbound Calls” to “Yes” in the Asterisk SIP Settings module.
Forward Port 5060 from your router to your PBX, at least for the IP address where the call will come from.
Create an Inbound Route to match the DID that will be presented when the call comes in.
Note that forwarding port 5060 for everyone creates a serious security risk and I do not recommend it.
If you really need to allow calls from anyone, you may wish to follow this guide from Ward Mundy, which will allow you to receive inbound calls from unknown peers via VOIP.ms:
My sip.conf is the vanilla freePBX one - as for entries in other places - I keep fiddling with them to try different things I find on the net (e.g. host=dynamic, etc.).
I know the system works fine if I ‘Allow anonymous’ - but would like the end result to be secure, so have been trying combinations that only allow a connection via an authorised account. i.e. I’d like to reject all anonymous calls unless accompanied by a valid username:password combination. Is that doable?
Interesting that FreePBX looks for a peer in the name of the originating number (014238238238) in my example. Why does it not look for one in the name of 443333333333 (which makes more sense to me because the former can be anything and the latter can only be what I expect)??
He’s already allowing calls form anonymous peers. He wants to disable this whilst still allowing calls from the address block used by his ITSP. He claims the ITSP is authenticating calls to him, but I find that very unlikely.
You should never be guessing at the setting of host=dynamic. I’ve never heard of an ITSP that would require it.
[quote=“MangledMind, post:5, topic:24717, full:true”]I know the system works fine if I ‘Allow anonymous’ - but would like the end result to be secure, so have been trying combinations that only allow a connection via an authorised account. i.e. I’d like to reject all anonymous calls unless accompanied by a valid username:password combination. Is that doable?
[/quote]
Yes, but the peer has to send an id and password, which is rather unlikely.
Because that number is the destination number, i.e. the DID number, not the identity of the entity that is trying to authenticate. If you had true DID, you could have thousands of possible values for this number.
It does look as though they are passing a password, which is unusual, unless they are simply reflecting the contact address you gave when you registered. If they were really authenticating with you, I would expect a separate MD5 authentication exchange.
I think you will need to allow guests, but restrict the address range in your firewall.
All that means is that it wasn’t rejected for security reasons. The decision to output that message is made after the end of processing the INVITE request, not at the point of authentication.
The more I investigate this the more confusing it becomes. Here’s my take…
I can get this to work if I turn allow anonymous on. Let’s say this is okay because anonymous means that the caller is not known by IP - and this is true when the caller can have any one of 2048
Now, we know a valid call from my ITSP authenticates - logically that should be our basis for accepting/rejecting the call, but it appears there is no provision for this case (shame).
So, we create an inbound trunk and route combo that includes a requirement to match on DID (OKUSER) and deny 0.0.0.0 and permit all known IP addresses.
Fine - that works, and can be routed to the appropriate IVR/extensions etc.
So what’s the problem, then?
Plenty of incoming calls (e.g. from ‘friendly scanner’ and other hackers) seem to fall into call contexts like from-trunk and ext-did. However, these calls have no defined context - so really should not get in this far. Moreover, in an attempt to see if earlier rejection is possible, an inbound trunk ‘Bogus’ was created as a catch all that just goes to hangup. This seems to remain unused.
I remain utterly baffled why I cannot permit one legitimate, authenticated, inbound route and reject all others through making a few logical and simple settings.