[asterisk-users] IAX authentication oddity - Known issue? Fixed?

[Steve Davies]

On 28 July 2010 17:32, Tilghman Lesher <tlesher at digium.com> wrote:
> On Wednesday 28 July 2010 06:49:01 Steve Davies wrote:
>
[snip] to avoid repetition below
>
> I don't see a 'type' argument to either of the above, so neither of these
> would at all be used.  That said, you're assuming that the deny and allow
> determine who is allowed to be user2.  That's incorrect.  They permit what
> packets will even reach user2, and a registration needs to occur for the host
> address to become something other than 0.0.0.0 (which is the default, unless
> you have a defaultip parameter).  Hence, user2 won't match anything at all
> until a registration packet comes in that passes your deny/allow ACL.
>

Sorry, I missed the
   type=friend
off both examples. Too busy cleaning up the example :(

Perhaps it is better to describe what I want to achieve first...

We want an primarily inbound IAX config that allows un-authenticated
connections from a specified range of IP addresses. The remote party
is required to use a username. I understood from the VoIP WiKi that if
a username is provided by the caller in the NEW packet, and the
permit/deny list allows the packet, that the following would be okay:

[user2]
type=user                 <--- type=friend should be ok too ?
username=user2
secret=
context=context2
host=dynamic           <--- "don't care" placeholder. Is this bad?
deny=0.0.0.0/0.0.0.0
allow=10.2.3.0/255.255.255.0

A channel is created called "IAX/10.2.3.1-xxx" in this example.

What I am pretty sure I observed is that if I ALSO have the following
configured:

[user1]
type=user
username=user1
secret=a-secret
context=context1
host=10.2.3.1          <--- Specifically an address from the permit
range in [user2]

When a call arrives from IP address 10.2.3.1 with a username of
"user2", then [user2] is used for authentication, but the call
proceeds using [user1] and a channel name of "IAX/user1-xxx" after
authentication is complete. In the example above this meant
password-free access to a password protected context.

I appreciate this is an odd claim, and I will try to reproduce it
using both 1.2 and 1.6 asterisk builds, in the meantime I was
wondering if this was a known issue - Sounds like it isn't.

PS. I  think there is a 99% chance that I mis-interpreted the results,
and this is not a real problem, but that 1% chance is why I am sending
the email :)

Thanks,
Steve