Managing the firewall on a cloud dialer

Getting the firewall right on day one is the first challenge. Keeping it right over the life of the server is the second, less-discussed one. Cloud dialer operations change: carriers update their IP ranges, agents move between offices and remote networks, you add a new SIP trunk, or an OS security update overwrites your firewall config. Any of these events can silently break inbound SIP signaling or RTP audio without anything in VICIdial's logs telling you why.

Understanding the two firewall layers

A cloud VICIdial server has two independent firewall layers and you must manage both. The first is the cloud provider's external firewall — called a security group, firewall ruleset, or network ACL depending on the provider. It sits at the hypervisor level and drops packets before they reach the VM. The second is the OS-level firewall: ufw or iptables on Ubuntu. Changes to one layer do not affect the other. When a port stops working, always check both.

For SIP (Session Initiation Protocol) SIP (Session Initiation Protocol) and RTP (Real-time Transport Protocol) RTP traffic, the cloud layer is often where breakage happens after a carrier change. Carriers occasionally shift their signaling IP ranges — they announce this in their portal or via email — and if your security group restricts SIP to specific source IPs, the new carrier IP gets silently blocked.

Routine firewall audit

Run a quick audit of the OS firewall every time you make a significant change to the server:

# Check ufw status and current rules
ufw status numbered

# Verify SIP port is listening
ss -ulnp | grep 5060

# Verify Asterisk RTP range is configured
grep -E 'rtpstart|rtpend' /etc/asterisk/rtp.conf

On the cloud provider side, review security group rules quarterly or after any carrier or network change. Confirm that UDP 5060, TCP 5060, TCP 5061, and UDP 10000–20000 are still present and the source ranges still match your current carriers and agent networks.

flowchart TD
  A[Carrier IP change or new SIP trunk] --> B[Update cloud security group source IP]
  B --> C[Reload ufw rules if OS rules were also changed]
  C --> D[Place test call]
  D --> E{SIP connects?}
  E -- no --> F[Check both firewall layers for SIP port 5060]
  E -- yes --> G{Audio OK?}
  G -- no --> H[Check RTP 10000-20000 UDP open on both layers]
  G -- yes --> I[Done - document the change]

Handling carrier IP range changes

If your SIP trunk SIP trunk uses IP-based authentication IP authentication rather than a username and password, the carrier's sending IP is also the authentication credential. A carrier IP range change means two things break simultaneously: the firewall blocks the new IP and Asterisk rejects the INVITE because the source IP is not on the whitelist. The carrier's portal will list their current IP ranges. Update both the cloud security group source and the Asterisk peer definition when you see that change.

OS update and firewall persistence

On Ubuntu, ufw rules persist across reboots by default once enabled. However, certain kernel or iptables updates can reset the active ruleset without warning. After any major OS update, run ufw status numbered to confirm rules are still in place and ufw enable if the status shows inactive. Place a test call after every server reboot — this catches firewall and NAT issues before your agents start their shift.

Documenting your rules

Keep a short text file in your server notes listing every open port, what it is for, and which source IP range it allows. When the VoIP (Voice over Internet Protocol) VoIP system breaks at 8 am on a busy call day, that file is worth more than any log. Include the date each rule was added and the carrier or use case it covers. When you remove a rule, delete the corresponding note so you are not debugging phantom rules months later.

For the foundational list of which ports to open from day one, see our VICIdial in the cloud guide. For a reference on the full initial security-group setup, the companion post cloud security groups for a VICIdial server covers the starting rule set in detail.

Ongoing firewall management is low-drama when nothing changes, but demanding when something does. If you would prefer a managed setup where the network configuration is handled for you, see VICIfast plans — a correctly configured server is ready in under 40 seconds, and you can still add your own carrier and rules on top.