What Is a Firewall and What Is a Port?

Address, door and guard

If an IP address is the address of a building, a port is the apartment number. Many services run on one device at the same time, and each has its own number from 0 to 65535. Secure websites usually answer on port 443, call management with SIP usually uses port 5060, and the voice itself travels over a wide range of high ports.

A firewall is the guard at the entrance to the building. It has a list of rules: who is allowed in, to which apartment, and from where. Every packet that arrives is checked against the list, and whatever is not allowed is dropped. In most offices the firewall is built into the router. In larger organizations it is sometimes a separate box.

The basic rule of almost every firewall: whatever goes out from the inside is allowed, and the replies to it are allowed back in. Whatever tries to come in from outside on its own initiative is blocked. This is exactly what protects you, and it is also what can confuse phone calls.

A firewall like this is called a stateful firewall: it remembers every connection opened from the inside, and allows only the replies that match it. More advanced firewalls also inspect the content itself, block dangerous sites and detect attack attempts. But even they may mistakenly flag a phone call as suspicious.

Why phone calls in particular are sensitive to firewalls

Browsing the internet is simple for a firewall: the computer sends a request, and the answer comes back through the same door. A VoIP call is more complex, because it is built from two separate channels:

• The signaling channel (SIP): the messages that set up and end the call: "I'm calling," "ringing," "answered," "hang up." It uses one fixed port.
• The voice channel (RTP): the voice itself, which travels on ports chosen anew for each call from a wide range. The port number is agreed within the signaling messages.

This is where the trouble starts. A firewall that does not "understand" the call sees voice packets arriving at a port nobody opened, and blocks them. The result: the call connects, rings, is answered, and one side hears nothing. In another case, the firewall "forgets" that a connection is open after it has been quiet for a few seconds, and then a phone waiting for an incoming call does not hear it at all. This is also the source of the familiar problem of a call dropping after a fixed number of seconds.

Much of this is also related to the network address translation (NAT) that the router performs, and to a setting called SIP ALG that tries to help and often makes things worse. In practice, the firewall and the NAT are the same box, and you check them together.

Two approaches: open doors, or don't open any

There are two main ways to get telephony through a firewall.

1. Port forwarding. You open certain ports in the firewall and direct them to a specific device on the network. This is needed mainly when there is a physical PBX in the office that must receive calls from outside. It is also the riskier approach: a SIP port open to the whole world is scanned within hours by robots looking for a weak password.

2. A connection initiated from the inside. This is what happens in most cases with a cloud PBX. Each phone initiates a connection outward to the server and registers with it, refreshing the connection every so often so that the firewall does not "forget" it. Because the connection is opened from the inside, the replies, including incoming calls, are allowed back in, without opening a single door to the outside.

The right setup: open enough, closed to everything else

Some principles that hold true in almost every office that works with cloud telephony:

• Do not open inbound ports to the phones if there is no need. With a cloud PBX there usually is not.
• Allow outbound traffic to the PBX servers, on the signaling port and the range of voice ports. A firewall that also blocks outbound traffic (as in strict organizations) needs an explicit rule for this.
• Restrict by address: when possible, allow telephony traffic only to and from the provider's server addresses, and not the whole world.
• Check the timeouts: a firewall that closes quiet UDP connections too fast causes incoming calls that never arrive. Our recommendation: a timeout (UDP timeout) of 180 seconds.
• Turn off SIP ALG in most cases.

The PBX control panel is also a "door" worth protecting. In some systems, including ours, you can restrict access to the control panel to certain IP addresses only, for example only from the office. This usually requires a static IP.

Firewalls and call fraud

The reason all this matters is not only quality. A PBX or phone exposed to the internet is a favorite target for toll fraud: attackers who gain access to an extension and use it to place thousands of minutes of calls to expensive destinations abroad, usually at night or on weekends. The bill arrives afterward.

A good firewall is one layer of protection. Other layers: a strong password for every extension, updating the phones' firmware, and not exposing the management interface of the phone or router to the internet.

A full example: the rules table of an office with a cloud PBX

Take a fictional nonprofit office with 12 phones, a business router with a firewall, and a cloud PBX. This is what the rules list looks like when it is written correctly: short, and every line with a reason:

A few notes on the table. The addresses of the PBX servers and the voice port range come from the provider; do not guess them. The fourth row ("everything else blocked") is the bonus: a compromised phone cannot talk to an attacker's server, because it has no way out except to the PBX. And the fifth row has no exceptions; with a cloud PBX, none are needed.

And what about the computers? They are on a different network, with their own regular rules. When the phones are on their own VLAN, their rules table stays short and does not change when software is added in the office.

Three levels of firewall, and the timeouts that drop calls

The timeout row explains a fault that shows up in every second office. The phone opens a "door" in the firewall when it registers with the server. The door stays open as long as packets pass through it; after a few dozen seconds of silence, the firewall closes it. An incoming call that arrives after the door has closed is stopped there, and the phone does not ring, until it refreshes its registration, and then suddenly everything works. This is why the phone sends a short keep-alive message every 20-30 seconds: to keep the door open. If the router closes after 30 seconds and the phone refreshes every 60, there is half a minute in every minute when you are unreachable. This is why we recommend setting a timeout of 180 seconds for UDP connections in the router and the firewall, well above any reasonable refresh interval of the phone.

And from the other side of the table: a "smart" enterprise firewall creates faults that a simple router does not know. The application detection component classifies voice as VoIP and applies someone else's policy to it; the intrusion prevention component sees 50 packets per second to a random port and suspects a flood. In such places, ask the IT person to exempt the PBX addresses from all advanced inspection, and leave only the address and port rules for them.

When it goes wrong: diagnosis by symptom

The order of checks that saves the most time: first SIP ALG (one minute), then double NAT (check whether the provider's converter also routes), then timeouts, and only last the port rules. In most offices the problem ends at the first or second step.

One last thing, about security: when someone suggests "let's open all the ports to the phones so it works," that is not a solved fault, it is a door left open. With a cloud PBX there is never a situation where you need an inbound port open to the whole world.