WAN Interface IP change - after Wildix phones still work, Yealink phones don't!

[eveares]

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.

[OtakarKlier]

Hello,

While I have never worked with either phones, I have worked with others in the past. Check your DHCP options to make sure they are pointing to the correct IP's destinations. Also some phones 'remember' their configs, so I would try to unplug one for at least 20-30 seconds and see if that helps. Also does the vendor aware of your WAN IP change?

Regards,

[eveares]

Nothing  has changed with the Windows  DHCP servers, both makes of phone use the same DHCP server  and get the same gateway (paloalto) and also get 8.8.8.8 and 8.8.4.4 as DNS.

Starting to think if I rebooted the  Paloalto, the issue may have gone away. Could the Paloalto be doing  something funky (in  bad way) with cache/stale data or a bug that would have been cleared with a reboot.

Whilst I am not aware of any differences between  how to the two makes of phones talk to the PBX, I will ask our PBX provider.

Any other ideas?

[JorgeOrtega]

Was this resolved?