[asterisk-users] IAX authentication oddity - Known issue? Fixed?
Hi, I had the following odd behaviour in Asterisk 1.2 - We are migrating to 1.6, and I will re-test ASAP, though it is quite hard to replicate, but I am curious to know whether it is a known IAX issue in 1.2. We had 2 users in iax.conf: [user1] username=user1 secret=secret1 context=context1 host=iax.hostname.com [user2] username=user2 secret= context=context2 host=dynamic deny=0.0.0.0/0.0.0.0 allow=1.2.3.0/255.255.255.0 A call came in with username=user2, the call was from the valid IP range specified in [user2], and the IAX debug trace showed the call as UNAUTHENTICATED. So far so good. The issue is that once the call was in, the channel-name was allocated as IAX/user1-xxx (instead of IAX/user2-xxx) and the call jumped to context1 instead of context2. I believe that the source IP address for the call DOES fall into the list of IP addresses that resolve using iax.hostname.com. I am concerned! 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
Re: [asterisk-users] IAX authentication oddity - Known issue? Fixed?
On Wednesday 28 July 2010 06:49:01 Steve Davies wrote: Hi, I had the following odd behaviour in Asterisk 1.2 - We are migrating to 1.6, and I will re-test ASAP, though it is quite hard to replicate, but I am curious to know whether it is a known IAX issue in 1.2. We had 2 users in iax.conf: [user1] username=user1 secret=secret1 context=context1 host=iax.hostname.com [user2] username=user2 secret= context=context2 host=dynamic deny=0.0.0.0/0.0.0.0 allow=1.2.3.0/255.255.255.0 A call came in with username=user2, the call was from the valid IP range specified in [user2], and the IAX debug trace showed the call as UNAUTHENTICATED. So far so good. The issue is that once the call was in, the channel-name was allocated as IAX/user1-xxx (instead of IAX/user2-xxx) and the call jumped to context1 instead of context2. I believe that the source IP address for the call DOES fall into the list of IP addresses that resolve using iax.hostname.com. 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. -- Tilghman Lesher Digium, Inc. | Senior Software Developer twitter: Corydon76 | IRC: Corydon76-dig (Freenode) Check us out at: www.digium.com www.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
Re: [asterisk-users] IAX authentication oddity - Known issue? Fixed?
On 28 July 2010 17:32, Tilghman Lesher tles...@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 -- _ -- 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
Re: [asterisk-users] IAX authentication oddity - Known issue? Fixed?
On 07/28/2010 11:32 AM, Tilghman Lesher wrote: They permit what packets will even reach user2 It should also be pointed out that the config option is permit, and not allow. -- _ -- 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
Re: [asterisk-users] IAX authentication oddity - Known issue? Fixed?
On Wednesday 28 July 2010 12:18:04 Steve Davies wrote: 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. It definitely sounds like a bug, but I'd be interested to hear if this is still a problem in both 1.4 and 1.6.2. -- Tilghman Lesher Digium, Inc. | Senior Software Developer twitter: Corydon76 | IRC: Corydon76-dig (Freenode) Check us out at: www.digium.com www.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
