VoIP Firewall Rules: What to Allow and What to Lock Down

A business VoIP system needs your firewall to let two kinds of traffic through: signalling (SIP, usually on port 5060 or 5061) and the audio itself (RTP, on a range of UDP ports your provider publishes). For a hosted phone system, the safest rule set is simple: allow outbound traffic to your provider’s addresses only, keep the firewall stateful, switch off SIP ALG unless your provider says otherwise, and put the phones on their own VLAN. This guide shows you how to build that, test it, and fix it when calls fail.

TL;DR

• Allow SIP signalling and the RTP media range, but only to and from your provider’s published IP addresses, never “any”.
• With a hosted (cloud) system, outbound rules on a stateful firewall are normally enough. Port forwarding is for on-site phone systems and should be restricted by source address.
• Put phones in their own VLAN or firewall zone, with static addresses or DHCP reservations.
• Most one-way audio and failed registrations come from SIP ALG, NAT timeouts, blocked RTP or UDP flood protection, not faulty handsets.
• Get the requirements from your VoIP provider and handset manufacturer before you change anything.

Table of Contents

• Why VoIP needs its own firewall rules
• The ports and protocols to know
• Inbound and outbound rules for VoIP
• Lock down the rules properly
• Step by step: setting up the rules
• Troubleshooting VoIP firewall problems
• Perspective: what we see on real Essex and London sites
• Choosing connectivity that suits your rules
• Keeping the rules healthy
• FAQ
• Sources

Why VoIP needs its own firewall rules

A firewall is built to say no. Web browsing works with almost no tuning because the browser opens a connection outwards and the replies come back along it. Voice is different. A call has two separate parts, and they travel differently.

Signalling is the conversation that sets up the call: registering the handset, ringing the other party, hanging up. Media is the audio itself, carried as RTP in a stream of small UDP packets. Cisco’s guidance on voice protocols describes this split: signalling servers handle signalling traffic, media servers handle RTP traffic, and some devices handle both. The media port is negotiated during the call, which is why a firewall that only knows “port 5060” can let a call ring and then deliver silence.

Get the rules wrong in one direction and calls fail. Get them wrong in the other and you have exposed a phone system to anyone scanning the internet for open SIP ports. The aim is the narrowest rule set that still lets calls work.

The ports and protocols to know

Exact numbers depend on your provider and handset make, so treat this as a map rather than a rule book.

On SIP, Cisco notes that SIP commonly uses ports 5060 or 5061, but some deployments use different ports, so verify what your own system uses rather than assuming. Some providers move SIP to a non-standard port precisely to cut down on scanning noise.

The RTP range is the one people most often get wrong, because it is a block of ports rather than a single number. Your provider’s setup guide will list it. If you are running an older H.323 system, note Cisco’s point that secure H.323 can break when traffic moves from UDP to TCP because of TLS, so allow both protocols there.

Inbound and outbound rules for VoIP

This is where most guides get vague, so here is the plain version.

Outbound rules let your phones and PBX start connections to the outside world: registering with your provider, sending SIP messages, sending RTP. Inbound rules let the outside world start connections to you.

Hosted (cloud) VoIP

With a hosted system, your handsets call out to the provider and keep that connection alive. A stateful firewall records each outbound flow and automatically lets the matching replies back in. So you normally need:

1. An outbound allow rule from the phone VLAN to your provider’s SIP addresses on the SIP port.
2. An outbound allow rule to the same addresses for the RTP range.
3. An outbound rule for provisioning and NTP, if the phones use them.
4. No inbound port forwards at all.

If your firewall is stateless, which is unusual on modern business kit, you must also allow the matching inbound traffic from the provider’s addresses, otherwise registration or audio breaks in one direction.

On-site PBX or SIP trunks

If a PBX sits in your building and a SIP trunk comes in from a carrier, the carrier must be able to reach you. That means port forwarding or a rule on the public side. Here the discipline matters:

• Restrict the source to your carrier’s published addresses. A rule that says “any source to port 5060” invites constant registration attempts and toll fraud.
• Forward the RTP range to the PBX unchanged, not a different range.
• Never forward ports directly to individual handsets. Put the PBX or an edge device in the path.

What “layer 3” means in practice

People also ask about layer 3 firewall rules. These are rules based on IP addresses and protocols (source, destination, UDP or TCP), which is exactly what most of the above are. Rules that look inside the SIP messages themselves, such as SIP ALG or application inspection, work at a higher layer, and that is where trouble tends to start.

Lock down the rules properly

Opening ports is the easy part. These measures stop an open port becoming a liability.

Restrict by source and destination

Allow only your provider’s published IP ranges. If a rule must be open to “any” to work, that is a sign something else is wrong, such as NAT or a mismatched port, and it needs fixing rather than accepting.

Give phones fixed addresses

When voice shares the data network, SonicWall advises using a static IP address or a DHCP reservation for each device. That lets you write rules that name a device rather than a whole subnet, and makes a misbehaving handset easy to find in the logs.

Separate voice from data

The same vendor guidance says it is best practice to separate VoIP traffic from data traffic using different subnets or VLANs and place it in its own firewall security zone. The benefits are practical:

• A compromised laptop cannot easily reach the phones.
• You can prioritise voice traffic (QoS) on its own VLAN.
• You can write one clear rule set for the voice zone, rather than patching exceptions into the general LAN.

If you want a deeper look at the thinking behind this, this piece on network segmentation outcomes covers why splitting traffic into zones pays off. In an office, VLAN separation also relies on switches that support tagging, and on cabling that is up to the job. Poor cabling causes dropped packets that look like firewall faults, which is why we often review the physical layer first on network cabling installation jobs.

Handle SIP ALG deliberately

SIP ALG is a router or firewall feature that rewrites SIP messages as they pass through. In theory it helps with NAT. In practice it often mangles the messages and causes one-way audio or dropped registrations. Opinion among vendors differs: Fortinet’s own guidance explains that some SIP providers recommend disabling SIP ALG, while Fortinet recommends against it. The sensible rule is to follow your VoIP provider’s instruction for your specific router, change one thing at a time, and test after each change.

Mind your flood protection

RTP is a steady stream of small UDP packets, which can look like an attack to an over-keen firewall. SonicWall notes that if UDP Flood Protection treats VoIP as a flood, the UDP Flood Attack Threshold may need to be increased. Raise it for the voice zone rather than turning protection off for the whole network. The same vendor also suggests excluding the voice network from specified security services, such as deep packet inspection tasks that add delay, rather than weakening the whole firewall.

Step by step: setting up the rules

1. Get the requirements in writing. SonicWall’s advice is to gather the VoIP manufacturer’s firewall requirements before making changes. Ask your provider for their SIP addresses, RTP range, provisioning address and any recommended handset settings.
2. Record your starting point. Export your current firewall configuration and note the current behaviour, so you can roll back.
3. Create the voice VLAN or zone. Assign phones to it and give each a reservation or static address.
4. Build address objects. Create named objects for your provider’s addresses so rules stay readable.
5. Add the outbound rules. SIP, RTP, provisioning, NTP, DNS, in that order, each limited to the voice zone and the provider’s addresses.
6. Deal with SIP ALG and flood limits. Adjust them only as your provider and firewall vendor advise.
7. Place a test call each way. Check registration, both-way audio, hold, transfer and a call lasting at least ten minutes.
8. Log, then tighten. Run for a few days with logging on the voice rules, then remove any broader temporary rules you needed while testing.

Troubleshooting VoIP firewall problems

When calls go wrong, the symptom usually points to the cause.

To diagnose, use the firewall’s own packet capture or session table. Fortinet’s example for one-way audio involves clearing the sessions for the affected source and destination before retesting, because an existing session can keep using old, broken state. Whatever kit you use, clear the session after you change a rule, or you may be testing the old behaviour.

If you are investigating something stubborn, a related lesson comes from email: the cause of a fault is often a security layer doing exactly what it was built to do. This walk-through of troubleshooting blocks on a business mail system shows that same method of isolating the control that is dropping traffic. The principle carries over to a firewall that sees a legitimate RTP stream as a flood.

Two things are worth ruling out before you blame the firewall. First, the internet line: a congested or unstable connection produces the same symptoms. Second, the Wi-Fi: softphones and Wi-Fi handsets on a weak signal drop packets in ways that look like firewall faults, and a wifi survey and design settles that quickly.

Perspective: what we see on real Essex and London sites

Most of the VoIP faults we are called to are not exotic. A firewall rule set that was written for web browsing, a router with SIP ALG on by default, or a phone plugged into the same flat network as every laptop and printer. Fixing them is rarely about opening more ports. It is about opening fewer, to the right place, and then testing.

We work with a range of suppliers and are not tied to one vendor, so our advice follows the requirements of the system you actually have. Our habit is to ask for the provider’s technical requirements first, build the voice zone, then test calls in both directions before we leave the site. We also try to keep disruption low: rule changes are made in a planned window, with the previous configuration saved so we can roll back.

For a small office with a hosted system, a stateful firewall, outbound rules to the provider and a separate VLAN covers most of what you need. Where a business has several sites, a leased line or an on-site PBX, the rules grow, but the principle does not change: allow what the system needs, from who it needs it, and nothing else.

— Paul

Choosing connectivity that suits your rules

Firewall rules cannot fix a poor line. Voice needs steady, low-delay upload as well as download, and a router with a good firewall that can separate zones. Our business broadband plans start at £24 per month for Basic Business Broadband, £38 for Standard and £49 for Fibre Broadband, and a 4G and 5G router from £20 per month can act as a backup line so calls survive an outage. Our VoIP and SIP hosted telephony is supplied without long-term contracts.

If you would rather not do this yourself, we can review your firewall, set up the voice zone and test your calls. Talk to us about hosted telephony and we will tell you what your site needs.

Keeping the rules healthy

A rule set is not finished once calls work. A few habits keep it that way:

• Review after any change. New firewall firmware, a new router or a change of provider can reset SIP ALG or flood settings.
• Watch the logs. Repeated denied SIP packets from unknown addresses are normal on the internet, but they are a reason to check that no rule is open to “any”.
• Update provider addresses. Providers occasionally add servers. Keep your address objects current with their documentation.
• Document everything. Note each rule, its purpose and who asked for it. Stale rules are how holes appear.
• Test after changes. A quick two-way call test takes minutes and saves a day of faults.

If you plan to add AI call handling or a virtual receptionist, the same approach applies: obtain the requirements, allow only what is needed, and test. Our AI-powered business phone systems follow the same pattern of outbound traffic to defined addresses.

FAQ

Which port is used for VoIP?

SIP signalling commonly uses port 5060 for unencrypted traffic and 5061 for TLS, though some deployments use others. The audio travels as RTP over a range of UDP ports set by your provider. Always check your provider’s documentation for the exact figures.

What is the difference between inbound and outbound firewall rules?

Outbound rules control connections your devices start, such as a handset registering with a provider. Inbound rules control connections started from outside. With hosted VoIP on a stateful firewall, outbound rules are usually enough, because replies are allowed back automatically.

Should I disable SIP ALG?

Often yes, when it causes one-way audio or registration drops, but vendors disagree, so follow your VoIP provider’s instruction for your router. Change one setting at a time and make a test call after each.

How do I fix one-way audio?

Check that the full RTP range is allowed in both directions where needed, switch off SIP ALG if advised, and clear existing sessions after any change. Then check for NAT timeouts and flood protection dropping UDP.

Sources

• Know the Basics of Voice over IP Protocols for Secure Firewall (Cisco)
• MSS FW Best Practices: VoIP Phones/Softphones (SonicWall)
• Troubleshooting Tip: One way Audio issue in VOIP (with SIP ALG) (Fortinet)
• Network Segmentation Outcomes That Matter
• Restore Mail in 90 Minutes: Proofpoint Blocks Playbook for UK Admins

Recommended

• VoIP
• VoIP Terms
• Routers