Not connecting to SIP trunk

Yesterday I moved my RasPBX to a virtual machine on my Synology NAS. After shutting down my RasPBX (which up to then worked fine), I started up the virtual machine using the same settings as before on RasPBX. The SIP provider however reports no server is connected to there system. FreePBX also reports no trunks are connected.

Is there a way of verifying all settings and see possible errors? Thiese are some entries in /var/log/asterisk/freepbx.log:

I’m running FreePBX 14 with Asterisk 14.

When shutting down the virtual machine and starting up the RasPBX, it works like before.

When your in the RasPBX, do you see similar errors? The deprecated functions probably aren’t a big deal, according to Deprecated Function PHP warning, but the very first line that says “connection attempt to AMI failed” is a major problem.

Check out this thread: [RESOLVED] FreePBX cannot connect to Asterisk via AMI, you might need to follow it and try resetting the password inside of mysql to match whatever you have in /etc/manager.conf

Thanks, I looked it up, but the passwords in /etc/asterisk/manager.conf and freepbx_settings are the same. To verify, I changed the password in settings => advanced settings => Asterisk Manager Password and it changed in both file and database.

In your log, is that connection attempt to AMI failure still showing up?

Do you see the SIP trunk showing as registered?

Are your internal extensions working, IE can you do extension-to-extension calls?

Are you going through any firewall?

When you SSH into the new VM, can you ping the IP of your SIP gateway? You might want to run some nmap commands from your VM CLI, to see if there is any actual connectivity there. Here is an example from my VM:

nmap -p 5060 -sU

Starting Nmap 6.40 ( ) at 2017-08-06 11:31 CDT
Nmap scan report for (
Host is up (0.0039s latency).
5060/udp open|filtered sip

Nmap done: 1 IP address (1 host up) scanned in 5.80 seconds

-sT will do a TCP scan, the -sU is UDP.

More logs showing “WARNING” would be quite useful. Off the top of my head, it must be something in the way the Synology NAS iteslf is doing connections across it’s NIC.

I’m not really conversant on Synology tech itself, how it’s VM bridges NICs, etc. All my virtual machines are on their own i386 boxes (two hyper-v 2012 and a 6.0 ESXi), both have their own “issues” with bridging NICs and such. Let me know how the port testing goes, that will at least let you know the “basic” connectivity isn’t an issue, plus more logs.

Nmap shows the same results, open port. No warnings in the logs other than the deprecated functions ones. Which logfiles can I inspect to find information on the SIP trunks?

I don’t think there is any log that is specific to SIP trunks. From what I can tell, it is basically all lumped together in the /var/log/asterisk/full log file.

Mine is 319,204 lines long and I only have three phones / extensions ATM; there is quite a few lines generated per second lol.

Can you make calls still between extensions? You might want to try adding “qualify=yes” to your SIP trunk config, that way when you do a “sip show peers” you can see if it’s actually registering or not. I had to add “transport=UDP” into my sip trunk config too to get it to work right recently.

Somewhere in the logs you should find your SIP trunk’s proxy IP address, something like:

[2017-08-07 04:02:20] NOTICE[2581] chan_sip.c: – Re-registration for [email protected]

or it might say just “Registration for”, since mine is already registered. The XXXXXXXXX will be your account name in your registration string, any YY.YYY.YY.YYY will be the IP for your SIP trunk provider.

Honestly, though, I think this must be something specific to the Synology box itself since this was working fine when it is running as a stand-alone box. You might want to post something in their support forums too at:

The NAS may have some “intrusion detection” enabled on it, that might be interfering with UDP sockets. Looking over their Wiki at it does mention this, and has a section on that “package”.

I would try to make an outgoing call, and then immediately after nano your log and look to see what it shows.

When all else fails, re-install. So I did, using FreePBX 14 with Asterisk 13. All trunks up and running now.