Who Me Too'd this topic

Hi all,  looking for advice following what is in my opinion  very  unusual behavior. 

Where I work for, we have a PA220 running Firmware version 9.0.3  that is used  as the firewall for VoIP traffic for physical desk phones. We have two brands of IP based desk phones;  Yealink and Wildix. Both types/brands connect to our  cloud hosted  Wildix PBX and both reply on the same internal  Windows DHCP server.

Today we tried moving the  WAN interface   to a new WAN line with a new IP.

In summary the following was updated:

• IP of WAN IP object updated to reflect new  WAN line
• WAN IP object removed from   ethernet1/8 interface and assigned to ethernet1/7 interface. (Done for  I want to use ethernet1/8 at a later date for  a new backup WAN line)   Ethernet1/8  becomes unused tap type and ethernet1/7 becomes layer3    like  ethernet1/8 was before. Essentially ethernet1/8 and ethernet1/7 get swapped around, else are the same interface settings.
• Default  route updated on default router to reflect gateway on new WAN line via ethernet1/7.
• The single NAT policy  updated to reflect WAN is now on ethernet1/7 rather than ethernet1/8
• QOS removed from ethernet1/8 and added to ethernet1/7 (Just under Network tab, settings identical)
• Updates the services route interfaces that were on ethernet1/8 to ethernet1/7
• Commit changes
• Unplug  old wan line from ethernet1/8 and plug new wan line into ethernet1/7.
• Test and  discover said issue, realise I can't fix strange issues so save logs and then revert to original configuration.

PBF, IPSec, Globaal protect are not used.  No firewall rules/security policy's refer to the WAN IP directly, but instead by the WAN IP object that was updated.

Following the change, only the Wildix branded phones worked as they should, with the  Yealink  phones now not working. The Yealink phones can still pick up the date and time via public NTP through the  PaloAlto, so NAT and Firewall must have been working for the Yealink phones to a degree, just no RTP/audio type traffic for the Yealinks. Rebooting the individual phones made no difference.

Both the Yealink and Wildix phones have the  same security policy  on the Paloalto and talk to the same cloud hosted PBX.

If I plug a single Yealink phone directly into  the new  WAN line  (via a PoE injector) and give it the new public IP, the phone works fine.

What would cause this odd behaviour? Was it just a caching issue on the Paloalto and it needed a simple reboot or is something more going on?

I also had  the PaloAlto crash  with a critical  "data_plane: restarts exhausted, rebooting system" message when I first tried to validate the changes before committing them, when it got stuck and crashed at 40% during the validation process. Ended up having to redo the changes once it had recovered, and that was when I first encountered the odd behaviour of Wildix phones working fine but the Yealink ones not.

Any ideas?

Regards: Elliott.