Firewall settings

Which ports to open for Voxbi

Everything your network team needs to let Voxbi through, in one place. Each rule says what it is for, so you can judge it rather than just trust it.

What Voxbi needs from your network

Voxbi needs a small number of outbound connections, from the machines your people work on to our services. Nothing on this page needs an inbound rule.

Every destination is given as a hostname rather than an IP address. That is deliberate: it means your rules keep working when we move infrastructure, and nobody has to tell you to go and change them.

Always required

Open these for every Voxbi customer, whatever your setup.

Port Protocol Destination What it is for
443 TCP voxbi.team Loads the Voxbi app itself. If this is blocked, the app will not open at all.
443 TCP hpp.mixvoip.com The API the app uses to place and control calls. If this is blocked, the app loads but nothing in it works.
443 TCP cdrs.voxbi.com Retrieves your call history. If this is blocked, calling still works but the call history stays empty.
443 TCP cdn.srv.whereby.com Loads the built-in Whereby video meetings. If this is blocked, voice calls work but video meetings will not start.
123 TCP/UDP ntp.mixvoip.com Keeps the clock in sync. A drifting clock produces wrong call timestamps and can make encrypted connections fail to validate.
3478-3479 UDP stun.mixvoip.com Works out a path for audio through your NAT. If this is blocked, calls may connect but arrive with no sound.

Depends on your PBX

These point at your own phone system, so the destination carries your instance name.

Port Protocol Destination What it is for
80, 443 TCP $instance.voxbi.cloud Lets phones and the app fetch their configuration from your PBX. If this is blocked, devices cannot provision themselves.
5060 TCP/UDP $instance.voxbi.cloud Carries the messages that set up, transfer and end a call. If this is blocked, no call can be established at all.
5061 TCP $instance.voxbi.cloud The encrypted form of call signalling. Required if your PBX is configured to accept only encrypted connections.
5000-50000 UDP $instance.voxbi.cloud Carries the actual voice audio. If this is blocked, calls connect and then have no sound in one or both directions. It is a range because the port is picked per call, so open it as a range rather than as individual rules.
8088-8089 TCP $instance.voxbi.cloud Used when calling from a web browser. If this is blocked, browser calling fails while desk phones keep working.

Replacing $instance

Where a destination contains $instance, swap it for your own phone system instance name. Your Voxbi contact can tell you which one is yours if you are not sure.

If your phone system is installed on-site rather than hosted by us, resolving that instance name is handled by your own DNS. There is nothing to set on the Voxbi side for it.

Questions your network team will ask

Do we have to open all of these?

The always required rules, yes. Without them the app either will not load or will load and not work. The second group only matters if your users connect to a phone system, which is almost always the case. Each row says what breaks without it, so you can make that call deliberately.

Why is the voice port a range rather than a single port?

Voice audio picks a port per call from a range, so a single rule cannot cover it. Open it as a range. Expanding it into individual rules would mean tens of thousands of them.

Can we use IP addresses instead of hostnames?

We do not publish IP addresses for these services, and we would advise against pinning rules to them even if we did. Addresses change when infrastructure moves; hostnames do not, so hostname rules keep working without anyone having to tell you.

Do any of these need an inbound rule?

No. Every connection here is outbound, from your network to ours. Your firewall only needs to permit the outbound traffic and allow the replies, which is standard behaviour on any stateful firewall.

Still blocked after opening these?

Talk to us and we will work through it with your network team.