This guide covers the layout and day-two configuration of the CloudSOE OpenSIPS image on both AWS and Azure. It assumes you’ve finished one of the getting-started guides (AWS, Azure).

File locations

PathPurpose
/etc/opensips/opensips.cfgThe routing script — OpenSIPS’ entire behaviour
/etc/fail2ban/jail.d/opensips.localfail2ban jails (sshd + opensips), journald-backed
/etc/fail2ban/filter.d/opensips.confThe SIP auth-failure filter (see arming below)

OpenSIPS is installed from the official apt.opensips.org repository; the newest stable release line for the OS release is auto-detected at image build time (check yours with opensips -V).

Services

sudo systemctl status opensips fail2ban
sudo systemctl restart opensips     # after config changes

Always syntax-check before restarting — a broken config leaves you with no proxy:

sudo opensips -C -f /etc/opensips/opensips.cfg

The one-time opensips-firstboot service only fills the public IP into the login banner; it exits immediately on later boots thanks to its marker file (/var/lib/opensips-firstboot.done).

Logs live in the journal

Ubuntu cloud images have no rsyslog by default — OpenSIPS’ output lands in the systemd journal, which is also where fail2ban reads from:

sudo journalctl -u opensips -f            # follow the proxy log
sudo journalctl -u opensips --since -1h   # recent history

Arming the fail2ban SIP filter

The opensips jail is enabled out of the box (5 failures in 10 minutes → 1 hour ban, escalating to 1 week), but OpenSIPS’ stock config does not log failed SIP authentication — so the filter has nothing to match until you feed it. In the auth-failure branch of your opensips.cfg routing script, add:

xlog("AUTH FAILURE: user=$fU ip=$si\n");

That exact AUTH FAILURE ... ip= shape is what /etc/fail2ban/filter.d/opensips.conf matches (it also catches common community phrasings like auth failed ... from). The jails read the systemd journal directly (backend = systemd) — no log files to rotate or point at.

Whitelist yourself first (sudo fail2ban-client set opensips addignoreip <your-ip>), or persist it by uncommenting the ignoreip line in /etc/fail2ban/jail.d/opensips.local and restarting fail2ban.

NAT and the public IP

On both clouds the instance knows only its private IP while the world sees the public one. For a proxy this matters in two places:

  • Advertised address — if OpenSIPS should present the public IP in Via/Record-Route headers, use the advertised_address core parameter or per-socket advertising in opensips.cfg, e.g. socket=udp:<private-ip>:5060 as <public-ip>:5060.
  • Far-end NAT traversal — clients behind their own NATs need the nathelper module and rport/received handling in your routing script.

The login banner shows the public IP captured at first boot.

Where media goes

OpenSIPS proxies signalling only. RTP flows directly between your endpoints and media servers. If you need this host to relay media (e.g. for clients behind symmetric NAT), install and integrate rtpproxy or rtpengine — and only then open a media port range in your security group / NSG, matching the relay’s configured range.

Next steps

  • Tips & tricks — lockout recovery, watching scanners, backups and updates