Episode Transcript:
Hello PANCasters and welcome to another episode. Today, we discuss the Application Level Gateway, or ALG for short. We will specifically look at how and why it is used for voice over IP; we’ll also discuss scenarios where it could cause issues and may need to be disabled.
John Arena is a Professional Services Consultant with a background in Technical Support for Palo Alto Networks and a passion for educating and sharing knowledge with customers.
Why do we need an ALG for VOIP traffic? There are two main reasons: Number one, most voice protocols include a signaling component and an actual media component for the audio or video traffic. What is typical in most of the protocols is that the signaling will use specific tcp or UDP ports but within the signaling exchange, there will be dynamically allocated ports for the actual media stream. Having an ALG means the firewall can inspect the signaling traffic and then dynamically add predict sessions for the media sessions based on the dynamically allocated ports. This is sometimes called pin-holing. These predict sessions will be just for the specific IPs and specific ports we see allocated in the call signaling. Without this function, you would need to allow all possible ports your voice services could use in your security policy which is normally a fairly big range.
The second part of ALG is the ability to modify some of the actual payload data within the signaling traffic. This is required if there is NAT configured on your firewall. Why do we need this? Within the headers of the signaling or control sessions, there is endpoint IP addressing information as expected. Ultimately, the media stream will be set up between the IPs of source and destination endpoints. But if there is NAT involved in your firewall, for example if you are translating your private internal range to a public IP towards the Internet, then voice traffic may not work if the signaling header still has your private, non routable IP address. The signaling traffic will still reach the public server as NAT was done on the actual packet but the payload would still have your internal IP so it won’t work. So the ALG will also help with translating some of the payload details within the signaling connection when NAT is used.
I haven’t gone into too much detail on the actual voice protocols, as there are quite a few and each has its own specifics on signaling, call control and media support. The individual protocols can be quite involved in the various mechanisms they use and the connections they create between the voice infrastructure. In terms of Palo Alto Networks and ALGs, the common voice ones we support are SIP and h.225. Please be aware that ALG is used for other apps as well but in the context of today’s episode the main ones to be aware of are SIP and h.225.
This all sounds great and, if you are using NAT or want to keep your security policy locked down, then the ALG which is enabled by default is the way to go — and we would never need to disable it right? Unfortunately that is not the case. The most common reason you'd want to disable the ALG is that your voice setup already has a NAT solution, so having the Palo Alto Networks firewall also do the payload modifications can cause issues with your media streams. There can be other technical reasons why having the ALG enabled causes issues with voice traffic. In these cases, we really need to work out if it is a problem with the way the firewall is doing the pin-holing or payload NAT or if it is an incompatibility with the way the voice service has been configured on the voice infrastructure.
In case there are issues, we can disable the ALG and there are two ways to do this. If you use SIP and want to disable the ALG, it can be done on the actual application definition on the firewall and this would be the preferred way to disable it. The second way which can be used — and would need to be used — in cases where the application does not have the option to disable the ALG is by creating an application override. You would create a custom application for the signaling traffic and add it as an application override.
Please be aware this means that the ALG functions will not be done on that traffic and, as this is an application override, there will be no layer 7 inspection done — so this impacts your security. The other thing to note is that if you are disabling ALG or creating an app override there is no way the firewall will know the dynamic media session details, so you may need to add security policy for the media streams.
So there we have it: a quick intro into Application Level Gateways and specifically for voice-over IP applications. The main thing to take from this is knowing that they are in play on the Palo Alto Networks firewall if you need to troubleshoot VOIP issues.
Check out the full PANCast YouTube playlist: PANCast: Insights for Your Cybersecurity Journey.
Related Content:
