🥇FusionPBX and ACL

My article is not a complete product description, but rather a brief clarification of a good publication titled 'FusionPBX, or Here We Go Again, FreeSWITCH.' I believe the topic of ACL in FusionPBX is not well covered in it. I will try to fill this gap based on my own experience with FreeSWITCH/FusionPBX.

So, we have FusionPBX installed with an internal number 1010 registered in the domain domain.local and a route set up for external city calls. We use ACL to secure our telephony system from unauthorized calls that could drain our funds. That is, we only allow outgoing calls from the networks described in the ACL. Here, a clear understanding of how ACL works in FusionPBX, its features, logic, and binding point is essential.

Like the esteemed author of the aforementioned article, I too stumbled upon all the pitfalls related to ACL.

Let's start with SipProfiles.
Both profiles (I will refer to them this way), internal and external, are in the Public context, and this is not by chance. Registration of numbers occurs in the internal profile, which we will focus on. In the internal profile, the ACL list 'domains' is attached as apply-inbound-acl. This line is responsible for the ACL operation at the profile level. So far, everything is clear about the profiles.

Context

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

Outgoing routes (to the city, mobile, long-distance, international, and any others) are located (by default) in the context named domain (let's call it domain.local).

ACL

Now let's delve into ACL. By default, a freshly installed FusionPBX has two ACL lists:

domains default action: deny — this list is linked to the internal profile
lan default action: allow

In the ACL list 'domains', we specify the network (for example, 192.168.0.0/24), grant permission to this network (allow), and apply reloadacl.

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

We begin analyzing the log in the console or through the Log Viewer of FusionPBX.

We see our call:

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

We see the triggered ACL:

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

And then:

mod_dialplan_xml.c:637 Processing 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 we have honestly specified a route.

The answer is actually simple.

The call came in. The ACL allowed it. Since the ACL is tied to the internal profile and this profile is in the public context, FreeSWITCH honestly looks for routing in the public context. But in the public context, there is only incoming routing, and the system honestly tells us that there are no routes available for the city.

From the situation that has arisen, there are at least two ways out.

Attach this ACL not to the profile, but to the internal number itself. This might be the most correct way to solve the issue, as it is better to tie the ACL as close as possible to the Extension for more precise configuration. That is, you can specify a specific address/network of phones that it can make outgoing calls from. The downside of this option is that this will have to be done for each Extension.
Adjust the ACL to work correctly at the profile level. I chose this option because adding a network to the ACL once seemed easier to me than specifying it in each Extension. But this is specific to my task. For other tasks, perhaps a different decision-making logic is needed.

So, let's adjust the ACL domains as follows:

domains default action: allow

In the ACL list, we specify the network:

deny 192.168.0.0/24

Apply it, reloadacl.
Testing: dial the number 98343379xxxx again and… there is a response… HELLO. Everything works.
Let's see what happened in FreeSWITCH:
call is starting:

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

ACL did not allow it:

[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 ->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 passed, and then connection establishment goes beyond the topic.

If we change the network address in the ACL, we will get the picture from the first test, that is, the ACL will allow the call and routing will say NO_ROUTE_DESTINATION.

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

I hope it will be useful to someone.

Source: habr.com