Mindbending issues with FreePBX - Firewall?

Hi Everyone,

I inherited a FreePBX/Centos UNIX server setup from the previous owner of our company. He was bought out and moved on, and we are now owned by a corporate conglomerate who immediately wanted us to move to their own telephony until they saw how great this setup was.
Unfortunately, I’m (begrudgingly) now the ipso facto default admin for the box with very little knowledge other than what I’ve managed to trawl up from the InterWebz™ and learned along the way.

I’ve taught myself how to use the FreePBX back-end to set up extensions, program the handsets and do some minor fiddling with the UNIX server. But I try to keep out of the heavy UNIX CLI wizardry and default to an expert we have on staff at a sister company.

Everything has been going swimmingly and our FreePBX install has worked flawlessly (even after our move into a new building) until Sunday, Feb. 16 when a corporate firewall blanket update rolled out and disrupted everything.

Here’s our set-up:

PBX Firmware:
PBX Service Pack:

Handset are all Cisco SPA504G’s.

We currently run a VLAN. All phones are configured for VLAN with an ID of 60.

Phones are able to connect to DHCP, they receive an IP address, gateway and subnet mask from the server. The ranges are good. CPUs that are daisy chained though the handsets are receiving uninterrupted network connectivity.

DNS has been set as public and in the handset web GUI.

On Sunday, all phones were suddenly unregistered from the server.
Nothing I could do would re-register the phones and the VOIP server was unreachable via the web interface.

I discovered that an automatic rollout on our Cisco firewall occurred on Sunday at approximately noon. This appeared to impact our connectivity.

I attached to the VOIP server from the command prompt and restarted it properly. The server was now reachable via a web GUI. Phones were still not registering.

I restarted the phones and rebooted the phones - nothing.
They all use POE, so I power cycled a few phones for several minutes. Nothing.

Eventually I ran across an article online where someone was having a similar issue and they suggested a factory reset of the offending handsets.

I ran the factory reset, plumbed in the VLAN settings, called up the handset web server and added the server proxy and FreePBX extension-based phone credentials, restarted and it registered with the server.

We now have incoming and outgoing activity again. We have a dial tone. I can ring out. I can receive calls.

HOWEVER… now anyone who calls in cannot hear the person who picks up the call. For instance, if I dial into an extension using my cell from outside, the internal extension will ring, the user will pick up and they can hear me calling from my cell, but I cannot hear them talk. After several seconds, the call is terminated.

That said, the server is responding as though everything is working. Incoming calls are being routed to the directory, then to the correct user mailbox. VM is working fine and voicemails are being funneled to email addresses without error.

I’ve had the support team at corporate working on this for two days now and everyone is flummoxed. We’ve checked ports, network traffic to and from the switch and firewall, the firewall has been rolled back to the previous state before the firmware update, we’ve restarted switches, the firewall, the VOIP server, monitored traffic to and from the VOIP server to the phones, etc.

Nothing seems to be working. And nothing is pointing to a solution.

We’ve now opened a ticket with Cisco to see if there’s some inherent incompatibility with our switches or firewall, but since it’s been running flawlessly for months I highly doubt that is the issue. So, I thought I’d give this route a shot…


Any help would be gratefully appreciated…

Get an hour of support from http://www.freepbx.org/support-and-professional-services, they can review the logs, and do some captures to track down where your issue is.

Hi Preston,

We’re getting to that point. First, Support at our corporate entity needs to exhaust all of the issues on our side first. It’s what we pay them for… Once they give up we’ll pay someone else.

I was fishing in the dark in the vain hope that someone would say something like “Oh! That’s X, you idiot!” or something similar…

Can’t say “Oh that’s X!”, but a few pointers.
If your calls connect but you get no audio, it’s either a NAT issue or an RTP issue. Basically the SIP traffic (UDP port 5060 by default) is working properly, but the actual audio traffic (UDP 10000-20000 by default) is being blocked or sent to the wrong place.

Asterisk (the actual phone system that FreePBX controls) doesn’t see any RTP packets for a call after a certain amount of time (typically 30 seconds), it drops the call.

If all this started after a firewall change, check your firewall and see if there’s anything related to UDP restrictions. Could also be the NAT SIP settings… try a google for Asterisk externip or NAT for more info

That being said, the history lesson was nice but hard to figure out your network topology.

“Cisco Firewall” is meaningless. Is it an ASA or a router running Firewall Feature Set? Is the Cisco the default gateway for each VLAN? Are the IP’s on the phones and the IP of the server in the same network? If they are not it is important that NAT is not enabled and the phones have a clear route to the server without access lists or ALG’s.

Thanks so much Jolouis. That’s great information to look into. I’ll forward this to support and they can take a look at it.
We will look into modifying the sip_general_additional.conf file. We saw that it contained information for NAT in there that should probably not be active.
I passed this onto our network guy and a light bulb went off in his head, apparently. Fingers are officially crossed.

Hi SkykingOH,

The firewall is a dedicated ASA variety appliance.

It is also the gateway for the VLAN.

The IP of the phones and the IP of the server are in different ranges and on separate networks.

We have NAT disabled on the firewall appliance, but we did notice that one of the .conf files on the Unix server hosting Asterisk has a line referencing NAT as ‘on’.

We’re currently looking into modifying that file and seeing what happens…