9608 desk phone discovery mode.. Broadcasting issue?

[TOPBAY]

Hi friends,

All 9608 phones go discovery mode to search IPO and give up.

IPO server edition on VMWare 192.168.20.203
IPO is DHCP too 192.168.20.205-230 as address pool, subnet 255.255.255.0 and gateway 192.168.20.254.

9608 phones can get ip address (ex 192.168.20.205) and I can ping from my PC in same subnet.
I can ping to IPO too, however phone says "discovering 192.168.20.203".

After spending few hours for troubleshooting, I found that our virtual firewall (pfSense 192.168.20.254) is causing this issue.
As soon as I disconnect (remove virtual interface on VM), 9608 phones can discover IPO without any issues.
Firewall's DHCP is disabled.

I know this is not something I can ask about firewall issue here, but if you had similar issue pls advise.
I don't have a switch with me which I can make mirror port and do wireshark.

Giving static IP, and specifying IPO IP on 9608 phone didn't help..

Thanks

 

[janni78]

Do you have IPO on the same interface as pfSense?

"Trying is the first step to failure..." - Homer

 

[TOPBAY]

On VMWare ESXi yes it is same port. 192.168.20.0/24 is same physical port.
One-X soft phones connect without any problem. 9608 desk phone goes discovery mode when pfSense is on.
Work around is disabling pfSense's LAN port and connect all desk phones, after all phones got registered enable pfSense LAN port. In this way desk phones will not go discovery mode and work fine..

 

[intrigrant]

On the firewall open TCP ports 1718, 1719 and 1720 incoming from the ip range of the IP Phones IP Addresses or all local devices (not so secure)
See image below

 

[janni78]

Sounds like a configuration error on ESXi or pfSense.

If you use pfSense as gateway (.254) it shouldn't affect traffic going to IPO (.203).

"Trying is the first step to failure..." - Homer

 

[TOPBAY]

Yes, it is nothing to do with firewall policy bcz phones and IPO is same subnet.
It is pfSense issue for sure, VMWare has few more VMs in same subnet but they are not causing, only pfSense LAN port is causing this issue.
Probably pfSense has arp level control? detecting broadcast packet and preventing or something like this?

 

[TOPBAY]

SOLVED:

Updating IPO SE from 9.1.0 to 9.1.7 fixed this issue.
Thanks