Hi, Your mail is dense, I will try to answer at my best from my understanding of the source code: - the default value for auth-call is false. - When a call arrives, the apply-inbound-acl is checked first: * If the IP is approved by the acl, the access is granted * If the IP is rejected by the acl and auth-call is false, sofia responds with 403 forbidden (I skip the proxy-acl and X-AUTH-IP checks for simplicity) * If the IP is rejected by the acl and auth-call is true, it falls back to digest auth. - If accept-blind-auth is set with auth-call, freeswitch only checks if the From user is defined in directory. If so, user is authorized (without any password check) - If auth-cal is set without the acl, the call go through digest authentication - If neither is set, the call is accepted. In your case, even if you can define directly a cidr in the apply-inbound-acl param value, it would be best to set it to a list name defined in autoload_configs/acl.conf.xml. Hope this helps! -- Best Regards, Vallimamod Abdullah SIP Solutions vma@sipsolutions.fr .
On 21 Nov 2017, at 05:26, Anatoli <me@anatoli.ws> wrote:
Could someone please shed light on this topic?
From: Anatoli Sent: Wednesday, November 08, 2017 18:12 To: Freeswitch-users Subject: [Freeswitch-users] ACL: auth_calls + apply-inbound-acl/auth-acl
Hi all,
I'm trying to understand FreeSWITCH's ACL concepts, but I find the documentation not clear with respect to a combined effect of various *acl* params with auth-calls. Could you please provide your comments on the following?
The documentation (https://freeswitch.org/confluence/display/FREESWITCH/ACL) says:
auth-calls: Can be set to true/false forcing users to authenticate or no on the profile. Only allow users from a specific cidr to register/make calls.
First of all, it's not clear what's the default value of the auth-calls param. If it's not explicitly defined, is it true or false? (BTW, same happens with a lot of other params, i.e. no default value specified in the docs, and for some params I couldn't even find the default values in the sources.)
Then, if auth-calls is set to true, will it ignore all *acl* params and always force auth? Or will it force auth only for those not specified in the *acl* params (e.g. IPs in apply-inbound-acl won't be forced to auth, all others will be). Similar doubt with the false value: will it always ignore auth or will it ignore auth for the IPs in the *acl* params and still require it for everything else?
Then the documentation specifies:
apply-inbound-acl: Allow users to make calls from a particular cidr without authenticating. Phones having IPs within these ACLs will be able to perform calls (apply-inbound-acl) or register (apply-register-acl) without having to provide a password (i.e. without getting a "401 Unauthorized" challenge message).
So if I understand it correctly, if I want a particular host (e.g. my SIP trunk provider) to make inbound calls without auth, but everyone else to be rejected with Unauthorized, I should specify in the corresponding sip profile:
<param name="apply-inbound-acl" value="1.2.3.4/32"/>
The documentation adds: The ACL behavior is modified by auth-calls, accept-blind-reg, and accept-blind-auth.
So what should be the value for auth-calls in this case? How would it modify the behavior of apply-inbound-acl (i.e. apply-inbound-acl + auth-calls=false and apply-inbound-acl + auth-calls=true)?
Then, the documentation says:
auth-calls: Users in the directory can have "auth-acl" parameters applied to them so as to restrict users access to a predefined ACL or a CIDR. Note: this will require "auth-calls" to be set to true in your sip (sofia) profile.
So, if I want to restrict my internal users to be able to register (providing their passwords) only from a specific range and be rejected with Unauthorized for other IPs or if not providing auth, should I configure the profile this way?
<param name="auth-calls" value="true"/> <param name="auth-acl" value="1.2.3.0/24"/>
My doubt here is: would auth-acl add an additional level of restriction without altering the default behavior of auth-calls (that is to request auth from everyone) or would it somehow relax the default behavior for some cases?
Thanks, Anatoli
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org