In hindsight, I should have mentioned that telnet is TCP-only so if you don’t have TCP forwarded as well (“Both” in your FW rule on your USG), you’d get a failed connection.
I believe FreePBX actually listens on 5060 UDP and TCP (at least mine seems to), so I’m able to test the forwarding by using telnet from an external source and not getting a connection refused error.
It’s setup for forward both tcp and udp, but still get the connection refused. This is with the FirePBX firewall disabled.
Something isn’t right here.
Honestly, I think it’s a FW setting on your PBX.
The IPs you have in your Gamma group on your USG match the IPs you have in the FW settings in FreePBX?
I can’t get any extensions to connect to the pbx so i’m guessing the Gamma IPs wouldn’t make a difference as they are for the trunks.
I’ve removed them from the WAN out on the USG as it’s set to allow everything out be default.
Short of you adding temporary FW rules to allow someone else to try and connect to your PBX, I’m out of ideas, sorry.
Which driver is the extension setup with, CHAN_SIP or PJSIP? On Which port?
How does the device know which port to connect with?
I’ve tried with both. They are set as default.
CHAP_SIP is setup with port 5160 - the extensions are set to this.
PJSIP is setup with port 5060 - i’ve setup the forwards for this so i could test.
On the handsets i’ve been using pbx.domain.com:5160
If all those ports are open to the world on your WAN, you are asking for trouble at some point.
They are not. They are limited by IP
Yes but what kind of extension have you created to try and register with, CHAN or PJSIP?
Nevermind, I see now…your using CHAN
I’ve just looking at the logs from a phone and this is what i found.
[02-07 15:09:46 51:80:3d] SIP: aid 0, cid 0, tid 0, did 0, REQUEST: REGISTER, Event: 2
[02-07 15:09:46 51:80:3d] SipProc:aid 0 enter NoAnswer SIP_REGISTRATION_FAILURE ====
[02-07 15:09:46 51:80:3d] CALL: State=0x60, Event=0x31e, Chn=0
[02-07 15:09:46 51:80:3d] CallCtl: SendEvent2Lcm: aid 0, Line: 0, event 0x8d3
[02-07 15:09:46 51:80:3d] GUI: Receive Call Register Failed!
I’ve just been looking through the logs and can now see:
NOTICE[10876] chan_sip.c: Registration from ‘“1103” <sip:[email protected]:5160>’ failed for ‘85.92..:38882’ - Wrong password
I’ve double checked the password on the phone and it’s correct, could this be a false positive?
OK - we’ll do our best.
There are plenty of posts in the forum about using a firewall in front of your server. In the firewall, you want to
That will get all of the pertinent information through the firewall into your server.
On the integrated firewall, set up the Trusted networks so that your remote phones and ITSP are all on trusted networks.
With that, you can start troubleshooting the connection issues between you and your ITSP. After that, it’s just setting up NAT configurations at the remote hosts and “away you go”.
If the 85.92.x.x address is yours and one you expect, then no, the password is mis-spelled (or more likely mistyped). If the address isn’t yours, then your firewall isn’t blocking enough address on either the external firewall or the Integrated Firewall.
There’s lot of them - all coming from my trusted networks.
I’ve copied over the secret multiple times and the phones still do not register and produce that error.
Will keep trying.
One important data point - there are two passwords. One is the extension password and one is the UCP user password. Make sure you are using the right password.
Second point - some phones will not accept the 32-character password generated by FreePBX. Try trimming the password down by, say, half and see if that helps.
For example, the Cisco SIP load (depending on version) will only take a 8 to 12-character password, so the long password from the extension manager will obviously not work.
Failed auth from SIP clients can also be triggered if:
Definitely using the secret and not the User pass and all our phones are Sangoma - i presume they are ok with the longer passwords.
I’ll make sure they are using the correct port.
EDIT: i rebooted the phone and now it says it’s registered. Not sure why that would make a difference? having said that, these phones were a part of an existing install and i’m not sure how to use the auto-provision again… next step 
