FreePBX remote extensions: access, NAT, contacts and firewall policy

Choose the access and identity architecture

Select one documented path for each device: a managed VPN, a supported remote-access service, an SBC or proxy, or a deliberately restricted public PJSIP edge. Record who owns DNS, certificates, credentials, source-address policy, registration state and media relay. A router port forward alone does not define authentication, authorization, updates, recovery or emergency behavior.

Keep the FreePBX web interface, SSH, database and provisioning service separate from phone registration. A remote endpoint that can send REGISTER or INVITE traffic does not need administrative access. Likewise, a trusted management network should not silently become a class of phone allowed to place calls.

Separate management, provisioning, signaling and media

Inventory the exact services the phone needs. DNS and time can be prerequisites; configuration retrieval may use HTTP or HTTPS; SIP signaling can use UDP, TCP, TLS or WebSocket; RTP, SRTP or DTLS-SRTP uses a separate negotiated media path. Opening one signaling port does not prove that configuration, registration, inbound calling or media can work.

Sangoma's PJSIP-extension reference keeps transport, ICE, RTP symmetry, Contact rewriting and media encryption as different controls. Its detailed interface text is version-13-scoped, so preserve the concepts without presenting its screenshots, field order or defaults as an exact FreePBX 17 map.

Align local, external and advertised addresses

FreePBX Asterisk SIP Settings documents external address, local networks and the RTP range as separate inputs. Asterisk's NAT guidance likewise separates transport local_net, external_signaling_address, external_media_address and endpoint direct_media. Define every PBX-side LAN, VPN or other truly local subnet; do not label an untrusted internet range local merely to make a call pass.

Compare the source address observed by the PBX, Contact and Via information, PBX signaling advertisement, SDP media address and received RTP tuple. force_rport, rewrite_contact, rtp_symmetric, media_address and direct_media have different address owners and effects. Enable only the controls supported by the captured topology rather than applying a generic NAT bundle. When a remote call answers but speech fails, continue with the FreePBX media-path investigation, which compares final SDP and observed RTP with the loaded transport and endpoint controls instead of enabling every NAT option together.

Treat registration contacts as expiring routing state

Keep endpoint identity, authentication, Address of Record and each current Contact distinct. A 200 response to REGISTER, a stored Contact, a successful OPTIONS exchange, an inbound INVITE and actual ringing are separate outcomes. Record the contact URI, source address, transport, expiry, user agent and observation time.

FreePBX exposes Max Contacts, qualification frequency and expiration controls, while Asterisk documents removal and qualification policies on the AoR. Increasing the contact limit can retain stale or competing paths; forcing removal can displace another authorized device. Do not add a static contact or lengthen expiry until the intended single-device or multi-device model is documented.

Keep firewall zones and responsive access explicit

Sangoma's Firewall documentation distinguishes network zones, services and Responsive Firewall. Its getting-started guide warns that newly discovered interfaces begin in Trusted until assigned appropriately. Verify every interface and network, then allow only the required service in the required zone. Do not expose the administrative interface because a remote phone needs PJSIP.

Responsive Firewall tentatively admits otherwise rejected signaling so legitimate clients can register, then blocks repeated failure. That behavior is not a substitute for a strong unique credential, destination restrictions or investigation of a device that repeatedly fails. Preserve the remote IP, service, firewall decision, registration attempt and PBX response before trusting an address or disabling a control.

Prove the remote lifecycle and revocation path

From each real remote network, verify DNS, optional TLS and certificate trust, REGISTER challenge and accepted binding, inbound alerting after an idle interval, outbound authorization, hold, transfer, voicemail or failover, and two-way media. Repeat after router restart, public-address change, phone reboot and credential revocation. Use SDP and a focused capture to prove where media was advertised and observed; SIP success is not RTP success.

Use unique credentials, least-privilege outbound permissions and a supported firmware and provisioning path. Validate emergency location and callback identity only through the provider-approved procedure. Offboarding must revoke the SIP credential, provisioning token, remote-access identity and any stored Contact or push relationship, not merely remove the desk phone. No FreePBX host, firewall, VPN, proxy, endpoint, registration, Contact, call, media path, provisioning service or emergency workflow was inspected or tested for this guide.

Correlate a roaming client's Responsive classification

The FreePBX Firewall guide shows why Responsive status is only one signaling observation. Trusted and Local clients may bypass that view, while a tentatively accepted unknown SIP or IAX source still must authenticate, register, receive calls and pass media under the intended dialplan and network policy.