FreePBX SBC Integration: How to Put a Session Border Controller in Front of FreePBX

FreePBX is the most widely deployed open-source IP-PBX in the world. It is a GUI layer over Asterisk that gives small businesses, MSPs, and ITSPs a complete telephony platform: extensions, queues, IVR, voicemail, conferencing, recordings, and SIP trunk configuration through a web interface. Most FreePBX servers run on a cloud VM (Vultr, Linode, DigitalOcean, AWS) with a public IP and SIP exposed to the internet by default.

That default deployment is also the reason FreePBX is one of the most heavily probed VoIP targets on the public internet. Automated scanners know the default ports, the default modules, and the default response patterns. A typical fresh FreePBX server collects thousands of SIP scan attempts within a day of going live, and a single compromised extension can generate enough premium-rate toll fraud to clear $20,000 before the carrier’s risk system pages someone.

A Session Border Controller (SBC) at the edge is what closes that exposure cleanly. The SBC absorbs the public-internet traffic, normalizes carrier SIP on the way in, hides FreePBX from anything that does not belong on the call path, and lets the PBX get back to doing what it is genuinely good at: extensions, dial plans, and call control. This article covers what the SBC adds in front of FreePBX, the Asterisk-specific SIP behaviors the SBC has to handle, how Sangoma’s commercial “Session Border Controller” module relates (and where it falls short), and the configuration approach for a production deployment.

What an SBC Adds in Front of FreePBX

FreePBX runs Asterisk’s SIP stack. Extensions, queues, IVR, voicemail, and the dial-plan logic all live inside FreePBX. For a single trunk to a single carrier on a private LAN with no internet exposure, that is enough on its own. The SBC becomes necessary the moment the deployment touches the public internet, terminates more than one carrier, or carries calls under regulatory scrutiny.

Public-internet exposure that FreePBX inherits by default

Most FreePBX servers run on cloud VMs with a public IP, and most SIP trunk providers expect the PBX to be reachable on UDP/5060 or TLS/5061 from the carrier’s signaling addresses. The same port that the carrier uses is the port that every internet scanner uses. The SBC absorbs all of that exposure: the public IP belongs to the SBC, the SIP listener lives on the SBC, and FreePBX moves to a private interface that the carrier and the scanners never see.

Multi-carrier failover and least-cost routing

FreePBX terminates one trunk per carrier cleanly. As soon as the deployment needs primary and secondary carriers, or rate-based routing across three providers, the SBC becomes the routing brain. Each carrier sits behind its own NAP with its own SIP profile and authentication, and route ordering decides which carrier carries any given call. FreePBX continues to see a single trunk on its side.

SIP normalization between Asterisk and the carrier

Asterisk has its own opinions about SIP. The carrier has its own opinions about SIP. The two sets of opinions rarely match exactly. P-headers carry information one side requires and the other rejects, Contact and From formats differ, codec offer order varies, and session timers behave differently between vendors. The SBC’s SIP header manipulation engine normalizes the carrier leg without changing anything about how Asterisk talks on its side.

STIR/SHAKEN and call authentication

FreePBX has no native STIR/SHAKEN signing path. For North American deployments, attestation control, signing-service integration, and bypass policy for outages all belong at the SBC layer. ProSBC integrates with STIR/SHAKEN signing services such as TransNexus ClearIP and Neustar over SIP, with route ordering and Reason Cause Mapping providing redundancy when a signing service is unreachable. CNAM dips and LNP lookups attach to the same routing engine.

Encryption on the public side

Asterisk supports TLS and SRTP, and many FreePBX deployments enable both for internal extension traffic. The SBC carries the same encryption requirement on the carrier side and bridges the difference per leg. A carrier-facing trunk on UDP/5060 with unencrypted RTP can coexist with a FreePBX-facing trunk on TLS/5061 with SRTP, with the SBC performing key exchange independently on each side.

Fraud scoring that runs before the call reaches FreePBX

Toll fraud against open-source PBX deployments is a well-established attack economy. The SBC scores each call against destination prefix, rate, time of day, and pattern history; high-risk traffic gets blocked or rerouted before Asterisk allocates a channel. Fraud detection running on the SBC catches the abuse pattern that per-call risk scoring is designed for: a compromised extension burning international minutes overnight.

A single ProSBC fronts one or many FreePBX servers, presenting a controlled public boundary to the carriers and absorbing all internet-facing exposure. Click to enlarge.

The Sangoma “Session Border Controller” Module Is Not the Same Thing

Sangoma sells a commercial FreePBX module under the name “Session Border Controller.” It adds SIP-aware filtering, rate limiting, and signaling controls inside the FreePBX server. It is a useful hardening layer for the PBX itself, and for a small single-site deployment with one carrier and a known IP whitelist, it solves some of the noise problem.

What it cannot do is take the SBC role at the network edge. The module runs inside FreePBX, on the same host, behind the same public IP. There is no B2BUA termination, no per-leg encryption boundary, no topology hiding from the carrier, and no isolation between the security layer and the call processing layer. If a SIP attack saturates the module, it saturates FreePBX along with it, because they share the operating system, the kernel network stack, and the CPU.

A real SBC is a separate device or VM at the edge, with its own public IP, its own SIP stack, and its own failure domain. It terminates every SIP dialog on each side, re-originates a new one on the other side, and controls every header, codec, and transport choice in between. That role cannot be filled by a module running inside the PBX it is meant to protect. The rest of this article is about deploying a true SBC, such as ProSBC, between FreePBX and the carrier.

Why Fail2ban and iptables Are Not Enough

Every FreePBX admin knows Fail2ban. It scans Asterisk’s security log, finds repeated authentication failures from a source IP, and adds an iptables rule blocking that IP for a configurable window. For SSH brute-forcing, it is exactly the right tool. For SIP-layer attacks on an internet-exposed PBX, it has three structural gaps.

Reactive timing is the first gap, because Fail2ban only kicks in after Asterisk has already logged something. The traffic has already reached the PBX, been parsed, been matched against an extension, and been rejected. Each one of those steps costs CPU. A scan rate of 100 requests per second per source, multiplied across the hundreds of source IPs a coordinated scanner uses, is enough to push the load average past where Asterisk can keep up with legitimate calls.

Silent failures happen when SIP attack patterns never trigger a 401 or 403 in the first place. Malformed SIP messages, oversized headers, slow-loris-style transaction stalls, and OPTIONS-flood probes never reach the authentication stage. They tie up SIP parser resources without producing the log line Fail2ban is watching for, so the PBX degrades quietly while Fail2ban reports nothing.

Layer-3 blindness is the third gap, because iptables sees IP and port but not SIP method or content. SIP-aware rate limiting requires inspecting the SIP message itself: limiting INVITEs per source independently of REGISTERs, applying a different threshold to a known carrier than to an unknown source, and distinguishing a legitimate burst from a coordinated probe. iptables cannot do that. An SBC’s SIP DoS protection can, because it parses the SIP layer and applies policy per method, per source, per trunk group, and per global threshold.

Fail2ban remains useful in the FreePBX-plus-SBC architecture: it stays on the PBX as a defense for the management interfaces (SSH, the FreePBX admin GUI). The SBC takes over SIP-layer defense at the edge.

Asterisk-Specific SIP Behavior the SBC Has to Handle

FreePBX is the GUI. Asterisk is what actually speaks SIP. Every quirk on the FreePBX side is an Asterisk behavior that the SBC has to work with cleanly.

chan_pjsip endpoint identification

Current FreePBX releases default to chan_pjsip, the modern PJSIP-based channel driver. chan_pjsip identifies incoming requests against a configured endpoint, and the identification method has to match what the SBC is sending. The common modes are identification by source IP, by authentication username, or by a custom header. If FreePBX expects IP-based identification and the SBC is sending requests from a NAT-translated address, Asterisk rejects the INVITE with no dial-plan logic ever running. The fix is small but specific: configure the FreePBX trunk endpoint to identify by the SBC’s actual sending address, or switch the identification mode to username authentication and provision credentials on both sides.

Contact and Via rewriting

Asterisk uses its own interface address in Contact and Via headers on outbound INVITEs. On a cloud VM behind a public IP, that address is often a private RFC 1918 address the carrier cannot route back to. Asterisk has its own settings for external address advertisement, but the cleaner architecture is to let the SBC handle topology hiding for everything outbound. FreePBX uses its local address; the SBC rewrites it to the SBC’s public address before the message hits the wire.

DTMF method mismatches

FreePBX defaults to RFC 2833 (out-of-band DTMF in the RTP stream). Some carriers send SIP INFO. Some legacy equipment still sends in-band DTMF. Asterisk can be configured for any of the three per endpoint, but the negotiation gets fragile when the carrier and FreePBX disagree about which method is in use. The SBC translates between DTMF methods per leg, so the carrier and FreePBX each see the method they expect.

REINVITE and direct media handling

Asterisk’s default is to keep media on the box, but the option to negotiate direct media between endpoints exists and can interact badly with NAT, with the carrier’s expectations about who controls the RTP path, and with the SBC’s media anchoring. The cleanest pattern is to disable direct media on the FreePBX trunk endpoint that talks to the SBC, so the SBC retains full media control and there is one path for RTP rather than two.

Session timers and re-INVITEs

Asterisk implements SIP session timers (RFC 4028) and can be configured to require, accept, or refuse them per endpoint. Mismatched timer policy between Asterisk and the carrier produces silent mid-call drops, which read as random and intermittent in the Asterisk full log because the failure is happening one hop away. The SBC enforces a consistent session-timer policy on the carrier leg without requiring changes to the FreePBX endpoint configuration.

Configuration Approach: FreePBX, SBC, Carrier

Specific menus differ between SBC vendors, but the integration logic is the same on any B2BUA SBC.

FreePBX for MSPs: One SBC, Many Tenants

MSPs running FreePBX as a managed service for many small business clients hit a specific scaling problem: every FreePBX instance is its own internet-exposed PBX, with its own attack surface, its own carrier credentials, and its own STIR/SHAKEN obligation. Hardening fifty PBX servers individually is fifty times the work of hardening one.

A single SBC at the edge collapses that. Each FreePBX tenant gets its own NAP on the shared SBC, with its own routing rules, its own carrier mapping, and its own security policy. The SBC handles the carrier-facing complexity once, presents a controlled public boundary for all of them, and the per-tenant FreePBX servers move to private interfaces where their attack surface is the MSP’s internal network rather than the public internet. The same model fits ITSPs delivering hosted PBX to many end customers, and contact-center operators terminating multiple FreePBX-backed campaigns. The SBC for MSPs learning page covers the multi-tenant pattern in depth.

What to Look for in an SBC for FreePBX

• B2BUA architecture is the baseline; a proxy cannot terminate the dialog or rewrite headers freely, which is exactly the work a FreePBX edge needs done.
• PBX-agnostic positioning matters because the SBC should treat FreePBX as just another upstream NAP, so the SBC layer survives a PBX change to 3CX, NetSapiens, or PortaOne later.
• Per-NAP transport, codec, and header rules give each carrier and each tenant its own profile, with independent transport (UDP, TCP, TLS) and codec lists per trunk group.
• Open STIR/SHAKEN partner integration keeps the signing-service partner as your choice rather than the SBC vendor’s choice; ProSBC integrates with TransNexus ClearIP and Neustar over SIP, the deployed production pattern, without locking to either.
• Cloud and virtualization flexibility covers AWS, Azure, VMware, KVM/Proxmox, or bare metal, so a cloud-native deployment sits next to cloud-hosted FreePBX, or a virtualized one runs on the same hypervisor as on-premises FreePBX.
• Self-serve evaluation means a free, permanent lab license is available so the integration can be validated against your actual FreePBX configuration before any commercial commitment.
• Tenant-scale trunk group capacity becomes the deciding factor for MSPs serving more than a handful of FreePBX tenants from one SBC; ProSBC supports up to 1,024 NAPs per server.

Security at the FreePBX Edge

FreePBX includes Sangoma’s security modules, Fail2ban, and the Asterisk security log. The SBC complements those with layered defenses that operate before traffic reaches FreePBX at all, which is the correct architectural position for SIP-layer protection.

• SIP registration scanning protection detects scan patterns, blocks the source automatically, and never forwards the probe to FreePBX in the first place.
• DoS and DDoS mitigation applies SIP-aware rate limiting per source IP, per trunk group, and per SIP method, which iptables and Fail2ban cannot do.
• Toll fraud detection scores each call on destination prefix, call rate, time of day, and pattern history, with optional integration to TransNexus and YouMail for managed feeds.
• Topology hiding keeps the SBC’s public IP as the only address the carrier ever sees, and the carrier’s underlying topology never reaches FreePBX.
• Dynamic blacklisting and greylisting automate the response to detected abuse, including ProSBC’s percentage-based greylisting for graduated response during investigation.

The full SBC security model covers the five layers in more depth.

Frequently Asked Questions

Conclusion

FreePBX is a capable, open-source IP-PBX with a vast deployed base. Its strengths are extensions, queues, IVR, dial-plan flexibility, and the FreePBX module ecosystem. Its weakness, structurally, is that the typical deployment sits on a cloud VM with a public IP and absorbs the full weight of internet-facing SIP abuse directly. The SBC is what fixes that without rewriting how FreePBX works.

The decisive features when evaluating an SBC for FreePBX are B2BUA architecture for full header and encryption control, per-NAP transport and codec policy so each carrier and each tenant gets the right profile, an open STIR/SHAKEN partner model so the signing-service choice stays yours, PBX-agnostic positioning so the SBC outlives any individual PBX choice, and self-serve evaluation so you can confirm the integration works against your actual FreePBX before signing anything.