A collection of practical advice for running the CloudSOE Kamailio 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 kamailio addignoreip <your-ip>Persist it by uncommenting the ignoreip line in /etc/fail2ban/jail.d/kamailio.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 kamailio.cfg means Kamailio fails to start and your platform is down. Make this muscle memory:
sudo kamailio -c -f /etc/kamailio/kamailio.cfg && sudo systemctl restart kamailioKeep the previous known-good config next to it (kamailio.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 kamailio -f
sudo tail -f /var/log/fail2ban.logFor 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 kamailio jail matches log lines your routing script produces — the stock config logs nothing on auth failure. If sudo fail2ban-client status kamailio 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/kamailio/kamailio.cfg (plus any files you include from it, and your fail2ban tweaks):
sudo tar czf /home/$(whoami)/kamailio-etc-$(date +%F).tar.gz -C /etc kamailio fail2ban/jail.dShip 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
- Kamailio updates come from the kamailio.org apt repository already configured on the box:
sudo apt update && sudo apt upgrade. - The image tracks the newest stable Kamailio branch at build time — for a new major branch, 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 advertise addresses in kamailio.cfg.
Troubleshooting first boot
systemctl status kamailio-firstboot
journalctl -u kamailio-firstboot --no-pagerFirst boot only fills the public IP into the login banner — Kamailio 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.