FusionPBX and ACL

My article is not a complete description of the product, but only a small clarification of a good publication “FusionPBX, or, again, great, FreeSWITCH”. It seems to me that the topic of ACL in FusionPBX is not well disclosed. I will try to fill this gap, based on my own experience with FreeSWITCH / FusionPBX.

And so, we have established FusionPBX with registered internal number 1010 in the domain.local domain and configured route for external calls to the city. ACL is used to protect our telephony system from unauthorized calls that will take our money. Those. only from the networks described in the ACL allow outgoing calls. And here you need a completely clear understanding of how the ACL in FusionPBX, its features, logic, and its point of reference.

Like the distinguished author of the above article, I also stepped on all the rakes related to the ACL.

I'll start with SipProfiles .
Both profiles (I will call them that), and internal, and external are in the context of Public, and this is not accidental. Registration of numbers takes place in the internal profile, and pay attention to it. In the internal profile, the domains ACL list is assigned as apply-inbound-acl. This line is responsible for the work of the ACL at the profile level. While with all the profiles.
')

Context

The context, among other things, is used in call routing. All incoming routes are bound to the Public context.

Outgoing (to the city, cellular, long-distance, international, and any other) routes are (by default) in the context of the domain name (let's call it domain.local).

ACL

Now let's deal with the ACL. By default, there are two ACL lists in the newly installed FusionPBX:

domains default action: deny - this sheet is bound to the internal profile
lan default action: allow

We register the network in the ACL list of domains (well, for example, 192.168.0.0/24), we allow this network to allow it, we use reloadacl.

Then we register the phone from this network, and everything seems to be good both according to the instructions and logical.
We start testing, we make a call to an external number and ... we get a donut, or rather a donut hole. Suddenly!

We start analyzing the log in the console or through the Log Viewer FusioPBX.

We see our challenge:

switch_channel.c:1104 New Channel sofia/internal/1010@domain.local 

We see a triggered ACL:

 sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted. 

And further:

 mod_dialplan_xml.c:637 Processing 1010 <1010>->98343379xxxx in context public switch_core_state_machine.c:311 No Route, Aborting switch_core_state_machine.c:312 Hangup sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION] 

No route! Although the route is honestly registered with us.

The answer is really simple.

The call came. ACL missed it. And since the ACL is attached to the internal profile, and this profile is in the public context, FreeSWITCH honestly looks at the routing in the public context. But in the context of public only incoming routing, and the system honestly tells us that there are no routes to the city.

From the current situation there are at least two ways out.

1. Do not attach this ACL to the profile, but to the internal number itself. This may be the most correct way to solve, because ACL is best tied as close as possible to the Extension for more fine-tuning. Those. You can register a specific address / network address of the phone from which he can make an outgoing call. The disadvantage of this option is that in each Extension will have to do it.
2. Correct the ACL so that it works correctly at the profile level. I chose this option, because it seemed to me easier to add the network to the ACL once, than to register it in each Extension. But this is specifically for my task. For other tasks, you may need a different decision logic.

So. We will correct ACL domains as follows:

domains default action: allow

In the ACL list of domains, we register the network:

deny 192.168.0.0/24

Apply, reloadacl.
We are testing: we are dialing again the number 98343379xxxxx and ... there is a CPV ... ALLO. Everything is working.
See what happened in FreeSWITCH:
The challenge begins:

 switch_channel.c:1104 New Channel sofia/internal/1010@domain.local 

ACL did not miss:

 [DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth. 

and further:

 mod_dialplan_xml.c:637 Processing 1010 <1010>->98343379xxxx in context domain.local sofia/internal/1010@domain.local Regex (PASS) [Sity] destination_number(98343379xxxx) =~ /^9(8343[23]\d{6})$/ break=on-false 

Routing has passed, and then a connection is established that goes beyond the topic.

If we change the network address in the ACL, but we get the picture from the first test, i.e. The ACL will skip the call and the routing will say NO_ROUTE_DESTINATION.

That's probably all that I wanted to add on ACL FusionPBX.

I hope someone will come in handy.