I’m looking for assistance with finishing a FreePBX virtual server setup. I’ve installed a FreePBX Distro (22.214.171.124 from FreePBX’s website) on a ESXi 4.1 virtual host. I’ve got most of the base configuration down, (static IP, DNS nameservers, changed default passwords) and updated all of the modules. It’s behind a PIX firewall and I’ve opened up 5060 for both TCP and UDP (SIP), 10001-20000 for UDP (RTP) and 22 for TCP (SSH).
As a test, I purchased 2 SIP trunks and 2 DIDs through FreePBX’s SIPSTATION and installed the SIP trunks using the SIPSTATION key.
I’ve setup 2 Extensions on FreePBX, assigning them each one of the DIDs and referencing the DID’s last 4 as the extension number.
I have one X-Rite softphone on my laptop and one Polycom 330 SIP phone successfully connected to FreePBX for testing.
I can successfully use internal functionality like *60 (time) and *65 (extension) on both the softphone and the Polycom.
What I can’t do is dial either extension or any outgoing numbers, nor can I dial in to any of the DID numbers. I’m guessing I have something configured wrong on either Outbound or Inbound Routes, or both.
I ran ‘sip show peers’ in the CLI and it shows the 2 extensions and the 2 SIP trunks Status as ‘Unreachable’. I also see it says Unreachable under SIPSTATION for ‘SIP Ping’. Now this might be normal because we don’t allow ICMP (ECHO, PING) through the firewall but I don’t know.
Here’s some basic version info:
Linux kernel: 2.6.18-194.17.1.el5
If anyone can assist me in getting this working that would be great. Sorry if I didn’t explain it enough or haven’t supplied enough info initially, I’m both a Linux and FreePBX noob.
I am not familiar with ESXi. Does it give the virtual server an IP address that is accessible from outside the ESXi? Or does the ESXi have a firewall or require NAT to talk to the virtual server from the outside?
VMware ESXi is a virtual server host OS, it hosts and runs a bunch of virtual machines. It exposes several physical NICs as virtual NICs that I can pass to the virtual OS, but the virtual OS itself is what sets the IP Address. This FreePBX virtual is setup with a virtual NIC on the “Inside” of my network.
I NAT to an “Outside” static IP address using a PIX firewall, it directs what “Inside” IP goes to what “Outside” IP and whats ports to expose.
I did run the NAT Settings “Auto-Configure” under Asterisk SIP Settings and it correctly pulled the External IP and the Local Network.
I also ran the Firewall Test under SIPSTATION and it passed with the correct Outside IP address.
I double-checked DNS and it resolves outside IP addresses like “google.com” and “yahoo.com” just fine and I was able to update modules so basic Internet is working too.
Tonight to test, I ripped out all of my Routes, Extensions and Trunks and set it up from the beginning again, this time setting up only 1 Extension and phone, and got the same results. Incoming calls get busy signal, Outgoing calls I get told that ‘all circuits are busy’. I see the following error in CLI when the Outgoing call fails:
WARNING: app_dial.c:2198 dial_exec_full: Unable to create channel of type ‘SIP’ (cause 20 - Unknown)== Everyone is busy/congested at this time (1:0/0/1)
I find it strange that you can’t call from phone to phone or phone to trunk or trunk to phone. Hard to believe that all these are setup incorrectly, which is why I was thinking network problems at the ESXi server level. I recall seeing someone here in the past that didn’t make the virtual machines ip available from the outside (or it had a firewall blocking ports - I don’t recall exactly)
I would focus on the trunk first. Esp with sipstation it should be turn key (although there are quite a few complaints recently about support from them).
With your trunk, you should be able to setup an inbound route to send a DID to voicemail (or an IVR) and start working that angle. When you dial the DID from an outside phone what shows up in the asterisk log? You can also enable more debugging with “sip set debug on” on the asterisk cli prompt.
Also, I would expect everything to show registered and reachable… so this is still likely a network/communication problem.
sip show registry should show your trunk (disclaimer: I don’t use sipstation)
I was able to get everything working on a separate virtual build of FreePBX on my laptop using VirtualBox, so at least I proved that my SIPSTATION trunks are working. I have full trunk and extension dialing, in and out and to each other. Even the FOP works.
The major difference is that I connected this new FreePBX build on the “Outside” of the network directly giving it a static external IP address, completely bypassing any firewall or NAT. I know this is a huge security risk but for isolation testing I wanted to take NAT/firewall away from the configuration and it looks like that was the issue.
I’m now going to attempt to move it back to behind the firewall and see what I can do to get it working, at least I know where the issue is.
Does anyone have any suggestions or experience with a FreePBX behind a Cisco PIX firewall? Any recommendations would be welcome.
That is a good start. Still curious why the 'inside the ne’t phones couldn’t talk back and forth to the server.
Sorry - no experience with PIX. I allowed all ports OUT through my firewall/router from my pbx server. Didn’t mess with specific port list and I didn’t need port forwarding.
My suggestion is iron out local traffic, then move on to wan traffic.
Ensure that your VM host is passing your FPBX server a “Real” Lan Ip address in the same subnet as the Lan side of your firewall and not Sharing one with other VM’s causing NAT issues. You need to make sure the phones are registering to the server. You can make calls from a phone that is not registered, but will not receive calls on it. Then once you get extension to extension calling to work, move on to testing your sip trunks.
The last pix i had i removed many moons ago, and never used voip with it. however there were now applications i couldn’t get to work so i think you’ll be fine. You just need a starting point… and right now you are trying to put out the different fires with bucket. get one thing working at a time so you can properly isolate the remaining issues.