In this final segment, I’m going to share my firewall settings that allow my #3CX system to function for both internal phones and external mobile users. This has been enjoyable discovering since I wasn’t able to find any other 3CX users using a Palo Alto firewall (probably because if they are using a Palo Alto, they aren’t using 3CX…). Anyways, the process was a good learning experience. The best starting point was the 3CX documentation: https://www.3cx.com/docs/manual/firewall-router-configuration/
Use Case and Environment
Let’s start with a description of my use case. As with any firewall rule development, having a clear understanding of what services need to be accessible from where is critical to setting this up properly. In my case, I need to be able to support the following capabilities:
- Physical VoIP phones within my #HomeLab network
- 3CX Mobile (Android and iOS) users both on and external to my network
- Web Administration of the 3CX system from within the Trusted Workstations zone on my network
- AWS Chime SIP Trunk access to the 3CX system
From the 3CX documentation, the two following images capture the primary ports that are necessary:
Finally, here is a quick illustration of the relevant security zones defined within the firewall:
Disable SIP ALG
One of the first things you will need to do is to disable the SIP ALG (Session Initiation Protocol Application Layer Gateway) on the Palo Alto. This is simple enough to accomplish within PAN-OS. Once you log in as an administrator on the firewall, navigate to the “Objects” page and select “Applications” from the left hand menu:
This will bring you to the list of registered applications with app-ids within the PAN-OS system. This list is one of the dynamic updates you can register for from Palo Alto so your device can be aware of the latest application behaviors and threats.
In the search block, type “sip” and hit Enter. You may have to scroll down, but you should see the list of applications that match SIP as well as their registered standard ports:
Within this list, you can see the application, it’s category within the PAN-OS system, it’s subcategory, risk level, tags, and standard ports. The SIP ALG setting is found in the “sip” application. Click on that app. It will bring up a new window with the details about the app. I’ve highlighted the SIP ALG setting:
Click on “Customize…” to change the default setting for the app. When the dialog comes up, check the box next to “Disable ALG” and hit “OK” to save.
You should now see on the application detail page that the ALG option has been disabled:
Click “Close” and that’s it for this task.
Create Recommended Objects
In order to help keep your policies clean, it’s recommended to create Address and Service objects that will be used. Let’s start with the Address objects. Navigate to “Objects” and then to “Addresses”. Click the “Add” button at the bottom of the screen as shown here:
When the dialog opens, you can specify either an IP with netmask, an IP range, an IP Wildcard Mask, or a FQDN.
For our purposes here, I created the following objects:
| Name | Type | Address | Tags |
|---|---|---|---|
| sip01 | IP Netmask | 192.168.xx.2 | |
| HomeLab External | IP Netmask | ISP DHCP Client Address | |
| 3CX SIP ALG Detector | FQDN | sip-alg-detector.3cx.com | 3CX |
| 3CX STUN Server | FQDN | stun.3cx.com | 3CX |
| 3CX STUN2 Server | FQDN | stun2.3cx.com | 3CX |
| 3CX STUN3 Server | FQDN | stun3.3cx.com | 3CX |
| 3CX STUN4 Server | FQDN | stun4.3cx.com | 3CX |
| AWS Chime Media US East 1 | IP Netmask | 3.80.16.0/23 | AWS Chime |
| AWS Chime Media US East 2 | IP Netmask | 52.55.62.128/25 | AWS Chime |
| AWS Chime Media US East 3 | IP Netmask | 52.55.63.0/25 | AWS Chime |
| AWS Chime Media US East 4 | IP Netmask | 34.212.95.128/25 | AWS Chime |
| AWS Chime Media US East 5 | IP Netmask | 34.223.21.0/25 | AWS Chime |
| AWS Chime Media US West | IP Netmask | 99.77.253.0/24 | AWS Chime |
| AWS Chime Signaling US East | IP Netmask | 3.80.16.0/23 | AWS Chime |
| AWS Chime Signaling US West | IP Netmask | 99.77.253.0/24 | AWS Chime |
The address and IPs are from the following two sites:
- https://www.3cx.com/docs/troubleshooting-firewall-checker/
- https://docs.aws.amazon.com/chime-sdk/latest/ag/network-config.html
To simplify the rules, I created the following address groups in PAN-OS:
The next step is to define the specific services that will be used by the system. In PAN-OS, the term “service” refers to the ports that are used by an application. If your use-case does not use anything other than the default ports/services defined for that application (refer back to the SIP example above), you can just use “Application Default”. However, 3CX looks for some specific ports to be used. You define the services in the same “Objects” tab that you defined the addresses and applications. Here are the services that I defined based on the 3CX documentation:
Afterwards, I defined some service groups to match the various use cases that will be used by our NAT and Security Policies:
Create Security Policies
Now that we have the various objects that will be used in our policies, let’s create the Security Policies. I create these first so that I have a secure configuration prior to opening ports for NAT. However, the actual order will depend on your desires.
Within the Palo Alto environment, it is not enough to allow specific ports in the firewall. Every communication between security zones must be defined. By default, all Intrazone communications (aka, within the same security zone) are permitted and all Interzone communications (aka, those between zones) are blocked. The following two security policies are created by default and cannot be edited or deleted:
I will walk through the creation of the first required security policy and then provide a list of all of the security policies that I’m using. The first policy will be to allow systems within my Trusted Workstations security zone to be able to access the 3CX Management Console on port 5001. This is a web application that uses the ssl app-id. So, on the security policy page, click “Add” and you will see the following page.
On the General tab, give the rule a meaningful name. Select either “universal” or “interzone” as the rule type since traffic will be moving between the “Trusted Workstations” and “VoIP” security zones. Add a description and any tags required by your policies. Move on to the “Source” tab next:
In the “Source Zone” section, I selected “Trusted Workstations”. If I wanted to limit to a single IP address, user, or device, I could specify those here as well. Moving onto the “Destination” tab:
In the “Destination Zone”, I specified the “VoIP” security zone and the “sip01” address object created earlier. Moving onto the Application tab next:
The 3CX Management Console is a web application that runs on port 5001 using SSL. The “ssl” application ID will match traffic for this application. Next up is the “Service/URL Category”:
On this page, we will specify one of the service objects we defined earlier. In this case, it’s the “3CX5001TCP” service. The names can be whatever makes sense for you. This just states that this security policy will permit traffic to sip01 on port 5001/tcp. Finally, we move to the “Actions” tab:
On this tab, we specify the action (Allow / Deny / Drop) for the policy, as well as any logging or other profile settings. In this case, I just specify “Allow” as the action and leave everything else at default. Click “OK” to save the new security policy rule.
The following is a list of the various security policy rules that were created to support the 3CX. They match the required communications paths specified in the 3CX documentation:
A couple of the rules may not make sense at first glance. That is because of the way the Palo Alto Firewall does NAT security policies. That is why the inbound services have a Destination Zone as “VoIP” (expected), but the destination address as the “HomeLab External” IP rather than the “sip01” address.
Create NAT Policies
Now that we have the security policies for the 3CX Server defined, we need to define the NAT policies the firewall will use to allow traffic to and from the Internet to the 3CX Server. As mentioned previously, I have a need for the server to support users using the 3CX Android and Apple apps from anywhere. I also need the system to be able to communicate with the AWS Chime SIP Trunk, which includes inbound calls.
In order to maintain the full cone NAT that the 3CX server requires, I had to create a static Outbound NAT rule for the 3CX Server in place ahead of my LAN’s default Dynamic IP and Port NAT for all other systems. This ensures the outbound ports don’t get mapped differently on their return trip. It took a bit of testing with the “Firewall Checker” in the 3CX Console to figure out what was happening. Here are the two NAT rules that were created:
I also chose not to make the Outbound rule “bi-directional” since I may want other service ports mapped to other servers later on.
Once I had all of these configurations made, I committed the firewall configuration and did a test. The initial port test failed on the firewall checker until I removed the source as the AWS Chime server restriction. If I had any feedback for 3CX, it would be to publish the IP space that their firewall checker uses so it could be added as a valid source address for the sip and sip-media firewall tests.
That’s it! I hope this series was informative and useful. Like I said, the changes made to the network, including the addition of the Palo Alto firewall has made this a real learning affair. I look forward to your feedback!