TeleDynamics Think Tank

How to troubleshoot VoIP problems caused by your firewall

Written by Daniel Noworatzky | Jun 5, 2019 2:44:00 PM

 

A firewall is a vital component of any enterprise network. But, it can also wreak havoc on the operation of VoIP implementations. In this article, we address the most common problems a firewall can introduce to an IP telephony network, as well as best practices for avoiding or remedying them.

What is a firewall and how does it work?

In order to understand how to deal with problems introduced by firewalls, it is important to first comprehend the fundamental operation of a firewall. Firewalls take advantage of the information found within the headers of packets and segments. Communication over a network is broken down into layers of the Open Systems Interconnection (OSI) model. These layers define the way in which data is transferred over a network. The two most important layers used by a firewall are the network and transport layers. In simple terms, the network layer contains IP addressing information, while the transport layer deals with end-to-end communications, including parameters such as TCP and UDP port numbers.  

Firewalls leverage the IP addresses and TCP/UDP port numbers to either allow or disallow packets to traverse a device. For this reason, firewalls are most commonly placed on the network edge, between the ISP and the internal network. (You can learn more about TCP and UDP, and their role in VoIP telephony, here.)


Types of firewalls

Before the advent of the firewall as a stand-alone device, network edge security services were implemented by routers. However, in the early 90s, their specialization prompted manufacturers to produce firewalls as separate devices. Since their inception, firewalls have gone through several generational iterations, where each one augments the operation of its predecessor. These evolutionary steps are described below.

First-generation firewalls – These devices are configured with a set of filtering rules specifying source and destination IP addresses, as well as source and destination TCP or UDP ports. Each packet traversing the firewall is inspected, and the IP addresses and port numbers contained within its headers are compared with the preconfigured filtering rules. Depending on how a packet compares with the configured rules, it is either dropped or allowed to pass. Because of their form of operation, first-generation firewalls are also called packet filters.

Second-generation firewalls – These firewalls perform the same function as their first-generation predecessors, but they also monitor information pertaining to conversations between specific endpoints by keeping track of which port numbers the source and destination IP addresses are using. This allows the firewall to analyze the overall conversation between the two endpoints and detect if incoming traffic belongs to the same conversation, allowing it to pass through, or from an independent source that may potentially be malicious, in which case it would block the traffic. Such firewalls are also known as stateful firewalls, because they keep track of the states of the conversations taking place between endpoints and make decisions based on those states.

Third-generation firewalls – Whereas the first- and second-generation firewalls operate on layers 3 and 4 of the OSI model, third-generation firewalls also operate on the application layer. For this reason, they are also known as application layer or layer 7 firewalls. These devices are capable of performing what is known as deep packet inspection. This is a process that uses algorithms to detect and discover the application layer protocol being used in each particular packet. Protocols such as HTTP, FTP, SIP, RTP, and others can be acted upon based on the filtering rules applied to the device, regardless of which IP addresses or port numbers are being used. Such devices are configured at a higher level, with varying fundamental parameters, allowing the device to develop the underlying logic of which packets to allow and which to block. These devices require high CPU and memory resources, especially in implementations where there is high throughput traffic.

What does all this mean for VoIP?

Firewalls work quite well for data communication, but when it comes to VoIP, they can introduce unpredictable and undesired behavior. Further complicating matters, firewalls are also often employed to perform network address translation (NAT) at the network edge, a technology that can further complicate the use of VoIP.

Keep in mind that VoIP telephony is composed of several channels of communication between IP endpoints. This includes the call control session, which is employed using the SIP protocol, and the transmission of the actual voice packets, implemented with RTP. These communications occur between the IP telephony devices, as well as with the IP PBX server, and are illustrated in the diagram below.

Note that each session may use different IP addresses, as well as different TCP and UDP ports for each session type. For example, by default, call control information being sent via the SIP protocol will use TCP or UDP ports 5060 and 5061, while RTP uses dynamically assigned UDP port numbers between 1024 and 65535.

The diagram above describes normal VoIP communication between devices within the same enterprise network where no firewall is involved. For calls being made between an endpoint within the enterprise network and another located on the internet at large, these sessions must traverse any firewall device installed on the network edge. The following diagram illustrates such a scenario.

Notice that the firewall must allow three separate flows of traffic to traverse it:

  • Voice packets that flow between the two endpoints
  • SIP control messages exchanged between the two endpoints
  • SIP control messages exchanged between the IP PBX and the ITSP SIP server that control and regulate the SIP trunk

The fundamental problem

The fundamental problem firewalls introduce to VoIP communications is that, depending on the type being used, they inherently view sessions as discrete and unrelated, even though they may be part of the same voice conversation. As a result, some of the communication sessions may be allowed, and others may not. This can often occur in an unpredictable manner, resulting in various problems such as one way or no way voice, or even loss of communications altogether.

The scenario illustrated above involves calls made over a SIP trunk to the PSTN. The same issues are encountered for multisite telephony deployments, where calls between branch sites are routed over the WAN, and thus also traverse any locally installed firewall.

Best practices when implementing firewalls with VoIP

Because of the nature of VoIP, special care must be taken to ensure that the implementation of a firewall will allow voice communications to take place without compromising the security provided by the device. The following general guidelines provide a good starting point for achieving this.

Never use a first-generation firewall – The implementation of a packet filter is insufficient for allowing VoIP to function while delivering a sufficient level of security. Because such a firewall cannot associate the various sessions of a voice conversation, all of the port and IP address pairs that are to be used must be included in the filtering rules to allow the appropriate conversations to pass. For SIP, this is not a problem since only two ports are used and can be configured; however, for RTP, which carries the voice itself, this would mean opening thousands of ports for voice conversations. Unfortunately, this would open up these ports to other types of traffic, as well, essentially negating the security benefits of the firewall.

Use a stateful firewall at the very least – A stateful firewall detects the association between sessions and allows communication to occur on voice sessions associated with SIP sessions that are permitted to pass based on specific filtering rules. Such an application is the bare minimum needed for VoIP to function across a firewall. The weakness still remaining in this scenario is that packets sent by malicious users may masquerade as SIP packets (for example), because they use the correct port numbers and would therefore be allowed to pass through, even if the packets themselves had a completely different payload and were part of a malicious network attack.

Best bet: Use an application layer firewall whenever possible – An application layer firewall will perform as well as the stateful firewall, with the added benefit that it will be able to inspect each packet to determine if it really is what it claims to be. For example, if a malicious user sends a packet using port 5060, knowing that the firewall allows such ports to pass, the application layer firewall will inspect the payload of the packet to determine if the SIP protocol is really being used, or if another protocol is being concealed within it.

Install a session border controller – An SBC is a specialized device used to facilitate the communication of VoIP conversations over the edge of a network. Often incorporated into a security device such as a firewall, the SBC goes one step further in ensuring a smooth VoIP deployment while maintaining the utmost level of security. Even though it serves many more purposes such as NAT traversal, QoS, and interoperability mediation, to name a few, security is one of its major functions.

Disable SIP ALG – SIP Application Layer Gateway is a feature of many firewalls that was originally designed to prevent and remedy some of the IP telephony problems caused by firewalls. It is primarily used to attempt to overcome problems arising from using NAT. Most firewalls have this as an option where it can be enabled or disabled. The majority of the experiences that professionals have had with this feature is that it is more trouble than it is worth. Depending on how SIP has been implemented, it usually causes SIP to behave unpredictably, and thus its use should generally be avoided.

Use IPv6IPv6 alleviates some of the issues with firewalls, especially those having to do with NAT, as well as with the level of security that VoIP communications can enjoy. IPv6 eliminates NAT completely, while providing an inherently secure protocol that employs both authentication and encryption from end to end in a conversation.

Conclusion

Firewalls are an essential part of any network security strategy. Deploying them in a way that offers your network the required level of security, while at the same time not obstructing your VoIP communications, is a difficult balancing act to accomplish. Following these best practices is a good first step to achieving this on your network.

You may also like:

Implementing VoIP safely and efficiently on the network edge

How to resolve one-way or no-way audio on VoIP calls

How to troubleshoot voice quality problems in VoIP phone systems