Tips & Tricks

OpenSIPS Tips & Tricks on CloudSOE Images

2026-07-30 · opensips docs

A collection of practical advice for running the CloudSOE OpenSIPS image in production, on either cloud.

Don’t lock yourself out — and how to get back in

This image bans on SSH failures too (sshd jail, journald-backed). A few mistyped keys or an over-eager Ansible run can ban your own IP. Prevention:

sudo fail2ban-client set sshd addignoreip <your-ip>
sudo fail2ban-client set opensips addignoreip <your-ip>

Persist it by uncommenting the ignoreip line in /etc/fail2ban/jail.d/opensips.local and restarting fail2ban. Locked out anyway? Use the cloud serial console (EC2 serial console / Azure serial console), then:

sudo fail2ban-client set sshd unbanip <your-ip>

Syntax-check every config change

A typo in opensips.cfg means OpenSIPS fails to start and your platform is down. Make this muscle memory:

sudo opensips -C -f /etc/opensips/opensips.cfg && sudo systemctl restart opensips

Keep the previous known-good config next to it (opensips.cfg.bak) for instant rollback.

Watch what the scanners are doing

Open 5060 to the world and friendly-scanner traffic arrives within hours. See it live in the journal:

sudo journalctl -u opensips -f
sudo tail -f /var/log/fail2ban.log

For packet-level visibility, sngrep (installable with sudo apt install sngrep) gives a live SIP call-flow view that is hard to beat when debugging registrations. If the same networks keep probing, block them at the security group / NSG rather than relying on bans.

Remember: bans only work if the filter is fed

The opensips jail matches log lines your routing script produces — the stock config logs nothing on auth failure. If sudo fail2ban-client status opensips shows zero failures despite obvious probe traffic, you haven’t added the xlog line to your auth-failure branch yet. The one-liner is in the configuration guide.

Back up the one file that matters

The proxy’s entire behaviour is /etc/opensips/opensips.cfg (plus any files you include from it, and your fail2ban tweaks):

sudo tar czf /home/$(whoami)/opensips-etc-$(date +%F).tar.gz -C /etc opensips fail2ban/jail.d

Ship it off the instance. Restoring onto a fresh instance of a newer image is untar, syntax-check, restart. If you add a database backend (usrloc, auth), back that up too.

Keep things updated

  • OpenSIPS updates come from the apt.opensips.org repository already configured on the box: sudo apt update && sudo apt upgrade.
  • The image tracks the newest stable OpenSIPS release line at build time — for a new major line, prefer launching a fresh instance from the latest CloudSOE image and restoring your config.

Static IPs are not optional for SIP

Every device and trunk provider that talks to this proxy pins its address. On AWS, allocate an Elastic IP before you put the box into service; on Azure, set the public IP to Static (the getting-started guides cover this: AWS, Azure). If the IP does change, update any advertised addresses in opensips.cfg.

Troubleshooting first boot

systemctl status opensips-firstboot
journalctl -u opensips-firstboot --no-pager

First boot only fills the public IP into the login banner — OpenSIPS itself is installed at image-build time, so a first-boot hiccup never affects SIP. A stale banner IP after re-addressing is cosmetic; edit /etc/motd.