Policy change kicks IP Phones off line

Lunchbox

We migrated to a full IP phone system early this year and I hadn't seen this issue before last week. I also recently updated to 12.8.1 (from 12.7.1). When I make a policy change to a policy that has nothing at all to do with my IP phones, they still go off line and need to re-register with the provider. This causes ALL the phones to be offline, which translates to no inbound/outbound calls until they re-register.

I have a few policies specifically for the IP Phones (which are on their own VLAN) and they are on top, given the highest priority. The other day, I made a change to a policy on our Corporate VLAN and when I saved the change to the Firebox, the phones lost connection. They did re-register on their own, but for that 45 seconds or so, there are no calls, not only in or out, but even between extensions, since it is a hosted solution (I do have a fail-safe cell phone for when we are unreachable, but not really relevant for the discussion).

In my company, I need to be able make a policy change during "typical" business hours (I say typical because we are 24/7) and having the phones go off-line is really not a good thing for us; this issue with the phones will limit my ability to make changes on the fly, which will lead to unhappy customers. This is an aviation company and the issue is that there is ZERO standardization across aviation, so one piece of software used by a transient pilot needs this and the next piece of software needs that... on occasion, someone will come in with something and have it blocked by our firewall, so I will examine the traffic and poke the necessary hole to get them going. If I can no longer make changes like this on the fly without my phones going offline, this will be a problem for us.

Currently, the WG is connected to a trunk port on the switch and all VLANs flow through it (M470). I was thinking that if I untangled all VLANs and gave each their "eth" ports on the M470 and the switch that this may alleviate my problem.

Just wondering what the hive thought.

Thanks for all your insight!
--Mike

james.carson

Hi Mike,

If you're not touching the policy the phones are getting out via, it's very likely not the actual firewall policies that are causing this -- it's probably something else.

-If a change triggers an SD-WAN action the firewall may push the connections over to another interface (or fail and end up on the same interface.)

-If a change is a modification to a network interface, the interface may restart to apply that change.

If you haven't already done so, I'd suggest opening a support case so that we can look into this further. You can do so via the support center button at the top right of the page. If you can please indicate where your phones are on the network (if it isn't obvious) as well as include a support file or support access to the firewall, we can investigate what might be happening.

james.carson

My guess based on just the description is that an SD-WAN action is getting invoked, a reset sent to the phones, and that causes them to re register with their SIP server.

Lunchbox

I was able to finally test this when the phones were not busy and it functions as expected. While all this was going on, we were also having problems with our internet connection (outside our building/control) and that has been stable for the past 8 days. I didn't get to post until 10/5, so by that time, VZ had corrected the issue with the line. Today, I made a policy change and watched the phones and they stayed online like they should. Since I upgraded to 12.8.1 at the same time we were having issues with VZ, I didn't know which of the 2 caused the problems. Either way, it does work as it should.

Thanks for the info!

james.carson

@Lunchbox Glad you were able to work that out.

I would suggest looking at your multi-wan settings (if you're using multi-wan) and setting your fallback setting to 'gradual failback' -- this will let existing connections on your backup ISP gradually fail back to the original preferred connection instead of being yanked over to the primary connection all at once.

Have a great day.