Why voice breaks when you replace the firewall
The firewall migration went in on a Saturday night. Every rule was carried over, every test passed, and the change was closed on Monday. On Wednesday the help desk started taking calls about choppy audio. By Friday the voice team and the security team were each certain the other had changed something.
Voice is unusual traffic. Most applications open a connection and send data over it. A phone call uses one conversation to set up a second one: signaling negotiates the addresses and ports, and the audio then flows separately, often directly between two endpoints that the firewall has never seen talk. A firewall that handles ordinary applications perfectly can mishandle that in several ways.
1. SIP inspection
Most enterprise firewalls can inspect SIP signaling, and many do so by default, including firewalls from Cisco and Palo Alto Networks. Inspection reads the call setup, opens the audio ports it describes, and rewrites addresses when translation is involved.
When it works, it is convenient. When it does not, it is hard to see: the firewall modifies a message in transit, and neither end knows why the other is confused. Typical symptoms are audio in one direction only, calls that drop at a fixed interval, and features such as hold or transfer failing while basic calls work.
A new firewall may inspect differently from the old one, or have inspection enabled where the old one had it switched off. Find out which before the migration, and decide deliberately. Where signaling is encrypted and the firewall is not decrypting it, inspection cannot read the call setup, so the audio ports must be permitted by rule.
2. Priority markings
Voice packets are marked so that switches and routers send them first when a link is busy. A firewall in the path has to preserve those markings and, ideally, honor them. If the new firewall resets them, calls sound fine at nine in the morning and poor at two in the afternoon, when the link fills. A quality problem that follows the clock is often this one.
3. Timeouts
Firewalls close connections that have been idle. Phones and gateways hold signaling connections open for hours and may send very little on them. If the new firewall's idle timer is shorter than the old one's, connections are closed silently and the next call or the next registration fails. The symptom is phones that unregister at intervals, or the first call after a quiet period failing.
4. The path back
A stateful firewall expects to see both directions of a conversation. If a redesign sends audio out through one firewall and back through another, the second firewall has no record of the call and drops the return traffic unless a rule independently permits it. Signaling can succeed while audio fails, because the two take different routes.
How to prevent it
- Put voice on the test plan by name. Not "applications tested" but: an inbound call, an outbound call, hold and resume, a transfer, a call held open for an hour, a call at the busiest time of day.
- Record the old firewall's behavior, not only its rules. Inspection settings, timers and marking behavior do not appear in a rule export.
- Capture on both sides of the firewall. If a message goes in one way and comes out another, you have found it.
- Involve the people who run the phones before the change, not after.
A firewall change is tested when the applications work, not when the rules match.