Choose the access architecture
Remote extensions need signaling, media, DNS, time and provisioning access. Decide whether they connect through a managed VPN, a supported remote-access service or a deliberately restricted public SIP edge. A port-forward alone does not describe a complete or maintainable design.
Keep administrative web and SSH access separate from phone registration. Allowing a carrier or endpoint to send calls does not require granting it management access.
Align the advertised addresses
Compare the phone-side address, PBX-side address and any public NAT address. Review the FreePBX Asterisk SIP Settings for local networks and external-address behavior, then verify the endpoint’s NAT-related settings. Changes must match the actual topology, not a generic internet tutorial.
The FreePBX firewall, operating-system rules, cloud security rules and edge firewall can all affect the same flow. Identify which layer rejected a packet rather than disabling several controls at once.
Test from the remote network
Register the phone outside the office and place calls in both directions. Test hold, transfer, a long call and idle-to-incoming recovery. A phone that works immediately after an outbound call but misses calls later can indicate expired state or keepalive behavior.
Use SDP to identify the media destination and a focused capture to confirm packets arrive there. Do not assume the SIP port is the RTP range. See remote extension troubleshooting.
Maintain a bounded policy
Use unique credentials, restricted call permissions and a documented update path. Retain denial logs long enough to diagnose legitimate failures, with privacy controls. When staff leave, revoke the extension and provisioning access rather than only removing a phone from the desk.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.