FusionPBX and ACL

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

And so, we have installed FusionPBX with registered extension number 1010 in the domain.local domain and a configured route for external calls to the city. We use ACLs to protect our telephony system from unauthorized calls that will take our money. Those. only from the networks described in ACL allow outgoing calls. And here you need a very clear understanding of how the ACL in FusionPBX works, its features, logic, and its point of attachment.

Like the respected author of the above article, I also stepped on all the rakes associated with 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 no coincidence. The registration of numbers takes place in the internal profile, and pay attention to it. In the internal profile, the domains ACL is bound as apply-inbound-acl. This line is responsible for the operation of the ACL at the profile level. So far with profiles.

Context

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

Outgoing (to the city, to cellular, intercity, international, and any other) routes are located (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 tied to the internal
lan profile default action: allow

In the domains ACL list we set the network (well, for example 192.168.0.0/24) , we make allow permission on this network, apply reloadacl.

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

We begin to analyze the log in the console or through the Log Viewer FusioPBX.

We see our call:

switch_channel.c:1104 New Channel sofia/internal/[email protected]

We see the 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/[email protected] [CS_ROUTING] [NO_ROUTE_DESTINATION] 

No route! Although the route we have honestly registered.

The answer is really simple.

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

There are at least two ways out of this situation.

1. Attach this ACL not to the profile, but to the internal number. This may be the most correct way to solve, because ACLs should be tied as close to Extension as possible for finer tuning. Those. You can specify 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 you have to do this.
2. Correct the ACL so that it works correctly at the profile level. I chose this option, because adding a network to the ACL once seemed to me easier than writing it in each Extension. But this is specifically for my task. For other tasks, you may need a different decision logic.

So. Let's fix the ACL domains as follows:

domains default action: allow

In the domains ACL-list we set the network:

deny 192.168.0.0/24

We apply reloadacl.
We test: we dial again the number 98343379xxxx and ... the CPV goes ... ALLO. Everything works.
We look at what happened in FreeSWITCH:
the call begins:

switch_channel.c:1104 New Channel sofia/internal/[email protected]

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/[email protected] 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 scope of the topic.

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

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

I hope someone comes in handy.