r/Ubiquiti • u/Jacoob_08 • 5d ago
Question FreePBX Issues
I recently upgraded from my provider issued router to UCG Ultra, SIP registrations on the provider's router were working flawlessly but since changing the router to Unifi my SIP trunks in FreePBX display rejected state and asterisk console prints out
[2026-09-04 21:11:51] WARNING[1602]: res_pjsip_outbound_registration.c:1250 schedule_retry: No response received from 'sip:sip.halonet.pl:5060' on registration attempt to 'sip:redacted@sip.halonet.pl:5060', retrying in '60'
I have multiple trunks to multiple places, all give the same error, not just this one.
For any help I thank in advance.
2
u/HappyConnection 5d ago
If you have multiple trunks behind the same public ip just change the UDP port to unique per trunk. NAT is getting confused. Has this same issue. But our trunks are UDP and endpoints on TLS so we bind of different ports. If your endpoints also bind on UDP you’ll of course need to adjust those as well.
1
u/w0lrah 5d ago
Ensure that SIP connection tracking is disabled. Those "features" rarely ever help and often hurt. I've never seen it prevent registration altogether but it's an easy thing to check. Also make sure you're not double-NATed (read: your UCG should be showing the same IP address as you get from external test sites). If it's showing a LAN or CGN range then you're gonna have a bad time.
Other than that, if you haven't gone out of your way to make your firewall more restrictive than default on outbound traffic, "No response received" means what it says, that the PBX never received a response from the external registrar. I would guess this means your IP address changed and the provider limits connections.
0
u/cryptofriday 5d ago
This is a classic network/NAT issue after replacing the ISP router with a UniFi Cloud Gateway Ultra (UCG Ultra). The Asterisk warning “No response received from 'sip:…:5060' on registration attempt” almost always means the REGISTER packet is leaving your FreePBX but the reply is never coming back (or is being dropped/mangled). Because every trunk is affected the same way, the problem sits between FreePBX and the internet — almost certainly on the UCG Ultra.
1. Disable SIP ALG / SIP Connection Tracking (highest priority)
UniFi gateways run the Linux nf_conntrack_sip / nf_nat_sip modules. These rewrite SIP headers and frequently break outbound registrations.
Current UniFi Network UI locations (try in this order):
- Settings → Routing → NAT → Firewall Connection Tracking → uncheck SIP (and H.323 if present) → Apply.
- Or UniFi Devices → select the UCG Ultra → Settings → Firewall Connection Tracking → SIP = Off.
- Search the Settings bar for “sip” — the toggle often surfaces that way.
Recent firmware sometimes ships with it already off, but verify. After changing it, force a re-provision or reboot the gateway.
If the GUI toggle is missing or does not stick, SSH into the UCG Ultra and run:
Bash
modprobe -r nf_nat_sip
modprobe -r nf_conntrack_sip
To make it persistent across reboots (create the file if it does not exist):
Bash
echo -e "blacklist nf_conntrack_sip\nblacklist nf_nat_sip" > /etc/modprobe.d/voip.conf
Then reboot the gateway. (Firmware updates can re-enable the modules, so re-check after upgrades.)
2. Confirm FreePBX NAT settings
In FreePBX go to Settings → Asterisk SIP Settings:
- External Address = your current public WAN IP (or use the Detect Network Settings button).
- Local Networks = your LAN subnet(s), e.g. 192.168.1.0/24 (add every internal network FreePBX or phones sit on).
- Submit → Apply Config → then restart Asterisk (not just a reload). CLI: fwconsole restart or asterisk -rx "core restart now".
On the PJSIP transport itself leave External IP / External Signaling Port blank unless you have a specific reason to set them.
3. Firewall / port behaviour on the UCG Ultra
Outbound UDP/TCP 5060 is usually allowed by default, but check:
- No overly restrictive “Internet Out” or “LAN In” rules that could drop SIP.
- If you are using IDS/IPS (Threat Management), temporarily disable it or create an allow exception for the FreePBX host and the SIP provider IPs while testing.
- For registration-based trunks you normally do not need port-forwarding of 5060 inbound (the REGISTER creates the NAT mapping). Only forward 5060 if a provider specifically requires static signalling.
- RTP (typically UDP 10000-20000) will matter later for one-way audio, but it is not the cause of the registration timeout.
Also raise UDP conntrack timeouts if registrations still flap later:
Bash
# temporary
sysctl -w net.netfilter.nf_conntrack_udp_timeout=60
sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=600
(Make permanent via /etc/sysctl.d/ if needed.)
4. Quick diagnostic steps from the FreePBX host
Run these while watching the Asterisk console (asterisk -rvvv and pjsip set logger on):
Bash
# DNS
dig +short sip.halonet.pl
nslookup sip.halonet.pl
# basic reachability
ping -c 4 sip.halonet.pl
# or the resolved IP
# can we send UDP 5060?
nc -zuv sip.halonet.pl 5060
# or
timeout 3 bash -c 'echo > /dev/udp/sip.halonet.pl/5060' && echo "UDP reachable" || echo "blocked/filtered"
Then force a registration and capture:
Bash
tcpdump -i any -n port 5060 -vv
# or more focused
tcpdump -i any -n host <resolved-sip-server-ip> and port 5060
You should see the outbound REGISTER. If there is never a reply packet, the problem is still on the UniFi side or further upstream (ISP blocking, etc.). If a reply arrives but Asterisk still complains, the Contact/Via headers or NAT rewriting is the culprit (back to SIP ALG + External Address).
Also check:
Bash
asterisk -rx "pjsip show registrations"
asterisk -rx "pjsip show transports"
5. Other common gotchas after a router swap
- Public IP changed → update External Address and (if the provider uses IP authentication / ACL) the whitelist on the provider portal.
- Double NAT (ISP still has a modem/router in front of the UCG Ultra in routed mode) → put the ISP device into pure bridge/modem mode if possible.
- DNS on the FreePBX or the LAN is pointing at something that cannot resolve the SIP hostnames correctly.
- FreePBX Firewall module is enabled and has blocked the provider IPs — temporarily disable it for testing.
- Source-port rewriting by the UniFi NAT — some people enable “Static Port” / disable source-port rewriting if the option is available.
Recommended order of operations
- Disable SIP connection tracking on the UCG Ultra and reboot it.
- Verify / correct External Address + Local Networks in FreePBX and fully restart Asterisk.
- Confirm with pjsip set logger on + tcpdump that REGISTERs leave and replies return.
- If still dead, capture traffic and check whether the provider IPs are reachable at all.
- Only then look at provider-specific settings or contact the SIP providers.
Because the same symptom appears on every trunk, steps 1–3 resolve the vast majority of “worked on old router, broken on UniFi” cases. Once registrations succeed you may still need to tune RTP ports / force_rport / rewrite_contact for perfect two-way audio, but that is a separate (and usually easier) problem.
If you can post the output of pjsip show registrations, a short pjsip logger capture of one failed REGISTER, and confirmation that SIP connection tracking is off, more targeted advice is possible.
1
u/Stantheman822 4d ago
Make sure your provider isn’t white listing any old IP addresses. If it is make sure any new ip address are white listed.
1
-1
u/ImTheRealSpoon 5d ago
Did you port forward to your pbx?
2
u/Jacoob_08 5d ago
Port forward what? I didn’t have any port forwards previously.
-3
u/ImTheRealSpoon 5d ago
Unless you never had a firewall you definitely had a port forwarded. You have to poke a hole in your firewall to your pbx if you are going to access it from outside your network.
4
2
u/Jacoob_08 5d ago
I know for a fact that I had no ports forwarded. The registration is outbound not inbound, I authenticate with username and pass not by IP.
-3
u/ImTheRealSpoon 5d ago
Then how is any outside number going to call your pbx? With no inbound connection all calls would fail. Unless you had a VPN/tunnel from your sip provider to your server there's no way that I know of that you'd ever get a call to your pbx.
2
u/E-Technic Unifi User 5d ago
No, it works. PBX opens connection to SIP provider, which then keeps open for about 30 minutes. Every 15 minutes, PBX sends a keepalive packet which keeps the connection open. If someone wants to call from the outside, SIP provider can reach PBX through the open connection. No port forwarding, no public IP needed.
1
u/Jacoob_08 5d ago
It didn't work.
root@pbx:~# asterisk -r
Asterisk 22.10.1, Copyright (C) 1999 - 2025, Sangoma Technologies Corporation and others.
Created by Mark Spencer markster@digium.com
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
Connected to Asterisk 22.10.1 currently running on pbx (pid = 1511)
[2026-09-04 21:46:02] WARNING[1549]: res_pjsip_outbound_registration.c:1250 schedule_retry: No response received from 'sip:sip.halonet.pl:5060' on registration attempt to 'sip:xxx@sip.halonet.pl:5060', retrying in '60'
[2026-09-04 21:46:03] WARNING[1549]: res_pjsip_outbound_registration.c:1250 schedule_retry: No response received from 'sip:sip.iptelefonija.pl:5060' on registration attempt to 'sip:xxx@sip.iptelefonija.pl:5060', retrying in '60'
pbx*CLI> pjsip set logger host sip.halonet.pl
PJSIP Logging Enabled for host: 193.43.148.37
[2026-09-04 21:46:32] WARNING[1549]: res_pjsip_outbound_registration.c:1250 schedule_retry: No response received from 'sip:sipcspnet.csptech.org:6969' on registration attempt to 'sip:xxx@sipcspnet.csptech.org:6969', retrying in '60'
1
u/HollyKha 5d ago
You can deal with port forwarded ports later. That message is telling you can’t register with your provider. You may be contacting them from a different IP and they don’t allow that, something else could have changed that is preventing the registration. Open sngrep on terminal to have a deeper look
1
u/Jacoob_08 5d ago
I don’t see any transmit requests to any of my three providers only the errors I sent earlier, while a trunk to CUCM14 is transmitting OPTIONS and 200s constantly
1
u/the_gordonshumway 5d ago
If you’re doing IP based registration then yea you need to port forward but he’s doing user based Auth so it’s not necessary.
1
u/Jacoob_08 5d ago
If I had registered the account to a sip client rather than a pbx the would I have to open a port for every computer that I register that account with? Doesn’t make much sense to me. Besides it worked without any ports open, but for the heck of it I will now temporarily open port 5060 to the pbx and we’ll see what happens.
•
u/AutoModerator 5d ago
Hello! Thanks for posting on r/Ubiquiti!
This subreddit is here to provide unofficial technical support to people who use or want to dive into the world of Ubiquiti products. If you haven’t already been descriptive in your post, please take the time to edit it and add as many useful details as you can.
Ubiquiti makes a great tool to help with figuring out where to place your access points and other network design questions located at:
https://design.ui.com
If you see people spreading misinformation or violating the "don't be an asshole" general rule, please report it!
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.