The CloudSOE OpenSIPS image gives you the OpenSIPS SIP server, installed from the official apt.opensips.org repository (the newest stable release line is auto-detected at build time), on a hardened Ubuntu base — with fail2ban jails for both SSH and SIP ready to go. There is no web UI and no credentials file: OpenSIPS is a SIP proxy, administered through /etc/opensips/opensips.cfg.
What you’ll need
- An Azure subscription
- An SSH public key (password login is disabled in the image)
- Working knowledge of OpenSIPS routing script — the image deliberately ships the stock config
Step 1 — Create the VM
- Find the CloudSOE OpenSIPS offer in the Azure Marketplace and click Create.
- Choose a resource group, region and VM name.
- Pick a size — 2 vCPU / 2–4 GB (for example
Standard_B2s) is plenty for a signalling-only proxy handling thousands of registrations. - Under Administrator account, select SSH public key, pick a username (e.g.
azureuser) and paste your key. This is the account you’ll SSH in with. - Attach a public IP, and set it to Static — a SIP proxy whose address changes on stop/start breaks every device registered against it.
Step 2 — Open the firewall ports (carefully)
SIP exposed to the whole internet attracts constant scanning within minutes. Scanners probe port 5060 around the clock. Restrict SIP to the IP ranges of your trunk providers, media servers and edge devices wherever possible. fail2ban helps — it is not a substitute for tight source ranges.
In the VM’s network security group, allow inbound:
| Port | Protocol | Purpose |
|---|---|---|
| 22 | TCP | SSH administration (restrict to your admin IPs) |
| 5060 | UDP + TCP | SIP signalling |
| 5061 | TCP | SIP over TLS, if you enable it |
Azure note: SIP over UDP needs an explicit UDP rule in the NSG — double-check the protocol column after saving. OpenSIPS is a proxy: RTP media flows between your endpoints and media servers, not through this box, so no RTP range is needed here unless you add an RTP relay (rtpproxy, rtpengine) on this host.
Step 3 — Let first boot finish
On the very first boot a one-time service (opensips-firstboot) fills your VM’s public IP into the login banner. OpenSIPS and fail2ban start automatically:
ssh <admin-user>@<public-ip>
systemctl status opensips-firstboot opensips fail2banStep 4 — Verify the proxy
The login banner (MOTD) shows your SIP URI and a quick-start cheat sheet. Confirm the version and that the process is healthy:
opensips -V
sudo journalctl -u opensips --no-pager | tail -20Remember that an Azure VM often cannot reach its own public IP from inside — test SIP from an outside client, not from the VM itself. Configuration lives in /etc/opensips/opensips.cfg; the stock config is a working proxy you can build on.
Step 5 — Know your fail2ban jails — and don’t lock yourself out
The image ships two journald-backed jails: sshd (active immediately) and opensips (5 failures in 10 minutes → 1 hour ban, escalating to 1 week). Before you start testing SIP auth or scripting against the box, whitelist your admin IP:
sudo fail2ban-client set sshd addignoreip <your-ip>
sudo fail2ban-client set opensips addignoreip <your-ip>The opensips jail only arms itself once your routing script logs failed authentication — see the configuration guide for the one-line xlog you add.
Next steps
- Configure OpenSIPS — opensips.cfg, syntax checking, arming the fail2ban filter
- Tips & tricks — lockout recovery, watching scanners, backups and troubleshooting