A FreePBX extension not registering usually means the phone or softphone cannot complete SIP authentication with the PBX. The cause may be an incorrect secret, the wrong transport, blocked ports, DNS resolution, NAT, or a firewall rule. A disciplined sequence helps you find the failure without changing several variables at once.
Before starting, record the extension number, device type, user location, PBX address, approximate test time, and whether other extensions are working. Do not publish SIP passwords or full packet captures in a ticket or public forum. For related symptoms, see this VoIP troubleshooting guide.
Define what “not registering” means
Registration is the process in which a SIP device tells the PBX where it can be reached and proves its identity. A FreePBX extension not registering can present in several ways:
- The device shows “offline,” “failed,” or “authentication error.”
- The extension appears unavailable in the FreePBX dashboard.
- The phone registers briefly and then disappears.
- Only one device fails while other extensions remain online.
- Several extensions at one site fail at the same time.
These distinctions matter. One failed phone points first toward device settings or credentials. A group failure suggests a network path, firewall, DNS, PBX service, or provider-side change. Avoid rebooting everything immediately; a restart may remove useful evidence.
FreePBX extension not registering: verify the account and device
Confirm the extension type
Determine whether the extension uses PJSIP or the older chan_sip driver. The phone must use settings compatible with the driver configured for that extension. Do not assume a device configured for one technology can use the other without changing its account details.
In FreePBX, review the extension record and confirm that it is enabled, has the expected username, and has a current secret. If you change the secret, update the device at the same time and save and apply the configuration. A copied password can contain an extra space or incorrect character, especially when pasted into a phone interface.
Compare the required fields
- Username or auth ID: Some clients distinguish between the extension number and authentication username.
- Password or secret: Verify the value without exposing it in screenshots.
- Domain, server, or registrar: Use the PBX hostname or address intended for that device.
- Outbound proxy: Set it only when the phone-system design requires one.
- Port: Confirm that the device uses the port assigned to the selected SIP transport.
Check the device clock as well. Large time differences can cause problems with some authentication or security arrangements, even when the username and secret are correct. If the FreePBX extension not registering message appeared after a password or provisioning change, compare the generated device configuration with the settings actually loaded by the phone.
Confirm SIP transport, ports, and network path
SIP is the signaling protocol used to establish and manage calls. Its transport may be UDP, TCP, or TLS. TLS encrypts signaling; it does not automatically encrypt the media stream. The phone and PBX must agree on the transport and destination port.
Review the extension’s transport setting in FreePBX and the matching setting on the phone or softphone. A device trying TLS against a UDP listener will not register. Likewise, a hostname that resolves to an address reachable only over a VPN will fail when the user is outside that VPN.
Confirm the actual listening ports on the PBX rather than relying on assumptions. On Linux, an administrator might inspect sockets with a command such as ss -luntp, but output and required permissions vary by distribution and service design. The Linux ss reference explains the tool. Treat any command as an inspection step, not permission to alter the server.
Test the route from the device’s network to the PBX:
- Can the device resolve the PBX hostname?
- Can it reach the PBX through the intended LAN, VPN, or public route?
- Is the correct SIP port allowed between those networks?
- Is guest Wi-Fi isolating the device from internal services?
- Did the public address or VPN route change recently?
NAT, or network address translation, changes how private addresses appear across a router. It can affect SIP registration and the return path. Review this NAT overview from Cloudflare if the device is outside the PBX’s local network.
Check DNS and firewall behavior
If the phone uses a hostname, verify DNS from the same network as the device. DNS translates names into IP addresses. A stale record, split-DNS design, missing record, or unreachable resolver can send the phone to the wrong destination. The result can look like an authentication problem even though the request never reaches FreePBX. See the broader DNS troubleshooting process for record-checking guidance.
- The hostname resolves to the expected current address.
- The firewall allows the selected SIP transport from intended source networks.
- Any VPN policy permits the device to reach the PBX and return traffic.
- Firewall logs show whether packets are blocked, rejected, or never observed.
- Intrusion prevention or fail2ban has not blocked the device’s public address.
- Port forwarding, if required, points to the correct PBX address and port.
Do not respond to a registration failure by exposing the PBX to every internet address or forwarding large port ranges. Narrow rules to known networks where practical, use strong credentials, and confirm the external-access design before changing perimeter settings. If a FreePBX extension not registering affects several remote users, compare their source networks and firewall logs before editing individual extensions.
Use FreePBX and Asterisk evidence before changing settings
Look at the FreePBX registration view and Asterisk logs during a fresh attempt. The most useful evidence is often the response code or message:
- 401 or 403: The request reached the PBX, but authentication or authorization needs investigation. A 401 can be part of a normal SIP challenge, so interpret it with the follow-up request.
- 404 or “not found”: The request may target the wrong domain, endpoint, port, or driver.
- Timeout: Suspect routing, DNS, NAT, firewall filtering, or a service that is not listening.
- Repeated register/unregister cycles: Check duplicate devices, unstable connectivity, NAT behavior, or conflicting account settings.
Exact log locations and commands depend on the Asterisk release, FreePBX configuration, and whether the extension uses PJSIP or chan_sip. Use the official Asterisk documentation for relevant endpoint and SIP diagnostic concepts. Capture the time of each test so log entries can be matched accurately.
FreePBX extension not registering: take a packet capture
When configuration review does not identify the problem, a packet capture can show where the exchange stops. A capture records network packets; it does not automatically explain them. Capture only the narrowest traffic needed, protect the file, and remember that SIP packets may contain usernames, addresses, and sensitive authentication material.
- Start the capture on the PBX interface or an appropriate network observation point.
- Trigger one registration attempt and note the exact time.
- Stop the capture promptly rather than collecting unrelated traffic.
- Filter for the device address and expected SIP port and transport.
- Look for the initial REGISTER, the PBX response, and the device’s follow-up request.
If no packet reaches the PBX, investigate DNS, routing, VPN, NAT, or firewall policy. If the PBX responds but the device does not continue, inspect the response and device configuration. If the exchange completes but FreePBX still shows the endpoint offline, compare the selected driver, endpoint identity, contact address, and registration display.
After the fix, verify and document
Once the extension registers, make an inbound and outbound test call if the business can do so safely. Confirm that the device remains registered after several minutes, reconnects after a network transition, and behaves correctly over the intended LAN or VPN. Registration alone does not prove that calling, audio, emergency calling, or voicemail is fully functional.
Document the confirmed transport, server name, port, extension driver, network location, and change that resolved the issue. Store secrets separately and never include them in ordinary troubleshooting notes. If the same failure returns, this record gives the next technician a starting point instead of another round of guesswork.
A FreePBX extension not registering problem is appropriate for professional remote assistance when several users are affected, the PBX is internet-facing, firewall changes are involved, or packet analysis is required. Tech Rescue Ops LLC can help collect evidence and test the registration path carefully without making unverified broad changes.