How to restrict VICIdial logins by IP with IP Lists

If managers keep logging into the admin screens from coffee shops and home connections, you can pin web access to a known set of networks. VICIdial does this with an IP List: a named collection of allowed IP addresses that you assign to a User group. The check is a form of IP authentication that runs after the username and password are accepted, so it tightens who can reach the system without replacing the login itself.

Turn the feature on first

IP Lists are hidden until you opt in. In Admin then System Settings, enable the "Allow IP Lists" option. Once that is on, an IP Lists section appears in the Admin menu and you can start building lists.

Build the IP List

Create a new IP List and give it a unique ID. That ID cannot contain punctuation other than underscores, so use something like office_main. Add a descriptive name, then list your allowed addresses one IP per line in the IP Addresses box. Set Active to Y, because a list defaults to N and an inactive list cannot be selected for a group. The Admin User Group field controls who can see and edit the list itself, and ALL is the usual choice.

Assign it to the right surface

Each user group exposes three separate whitelists. The Admin IP Whitelist restricts the administration web screens. The Agent IP Whitelist restricts the agent screens that an Agent uses to take calls. The API IP Whitelist restricts programmatic access through the Agent API and the Non-agent API. Each one is independent, so you might lock the admin screens to the office while leaving agent login open from anywhere.

flowchart TD
  A[Login request arrives] --> B[Check username and password]
  B --> C{Credentials valid}
  C -->|No| D[Reject login]
  C -->|Yes| E{User set to ignore IP Lists}
  E -->|Yes| H[Allow access]
  E -->|No| F{Source IP in assigned list}
  F -->|Yes| H
  F -->|No| G[Block this access]

Because the IP check happens after authentication, a single trusted user can be flagged to skip it entirely. That gives you an escape hatch for a senior admin who travels, while everyone else in the group stays pinned to the office network.

Warning: if you whitelist agent access and you use Dispo Call URL features like dispo_move_list.php, add your web server's own IP to the list. Those actions run from the web server, so without its address they quietly fail. The same caution applies to API functions that the servers trigger internally, so include any internal server addresses your integrations rely on.

Test before you trust it

After you assign a list and enable a whitelist, verify it from two angles. First, confirm a user inside the allowed network can still log in normally. Second, confirm someone on an outside connection is actually blocked, otherwise you've built a false sense of security. A phone on cellular data is an easy way to test the outside case without touching your office firewall. Because each whitelist is independent, repeat the check for every surface you locked down, since a working admin gate tells you nothing about whether the agent gate behaves the same way.

Keep your allowed addresses current too. Office connections change, VPN exit points get renumbered, and a stale list will start locking out the very people it was meant to protect. When you add a new site or remote office, update the IP List before staff there try to log in, not after the support tickets arrive.

IP whitelisting is one layer of the wider permission model. For how groups, levels and access flags fit together, read the users and groups multi-team guide. If you also need to control who reaches the admin tooling at all, see how the admin access permission works.

Want a managed dialer where IP Lists and the rest of the admin surface are already wired up over HTTPS on your own branded subdomain? Start a VICIfast trial and you can be live in under 40 seconds.