There’s something uniquely satisfying about uncovering the true root of a problem. Today’s IT journey takes us not only into the world of firewalls, but also back to a classic topic that never quite goes away: VoIP.
Our client approached us with a specific challenge — they needed to operate their VoIP PBX from a different network, but the device’s internal IP address had to remain unchanged. From a networking perspective, this isn’t a major issue — especially with the right tools — since most things can be prepared without relying on fixed IP addresses. VoIP, however, is a different story.
SIP signaling is an old protocol — still a cornerstone of VoIP — and it brings its share of complexity. The issue stems from the fact that relevant IP addresses aren’t just present in packet headers, but also deep within the SIP messages themselves (in fields like Contact, Via, or within SDP). This means that unless handled properly, a device behind NAT may insert incorrect internal IP addresses into packets, leading to failed or one-way calls (e.g., no audio).
Most modern firewalls attempt to „help” with this — the most common feature being SIP ALG (Application Layer Gateway), also known as a SIP helper. It tries to rewrite SIP messages on the fly to account for NAT. In practice, though, this often causes more harm than good. Not all SIP implementations behave the same way, and many modern PBXs are NAT-aware — allowing you to explicitly configure external IP addresses, enable NAT keepalives, or use symmetric RTP.
A more robust and purpose-built technology is STUN (Session Traversal Utilities for NAT). With STUN, the VoIP device contacts an external STUN server to discover how it appears to the outside world — specifically, what public IP and port are being used. This lets the PBX correctly populate SIP and RTP fields without needing the firewall to modify anything. In most cases, this approach is more reliable than relying on SIP ALG to guess what’s needed.

So, the key point is: if NAT is involved, the VoIP system needs to be aware of it. You either configure the external IP statically or let it detect it dynamically via STUN. Without that, calls just won’t work correctly.
I’m no longer a VoIP expert — arguably, I never really was — but I’ve gained a solid sense of what can break a VoIP call, and more importantly, how to avoid those pitfalls.
In this particular case, we were lucky: we simply had to notify the PBX operator of the new external IP address. Once that was set, no further changes were needed — though they might have been, under slightly different conditions.