[SOLVED] Avaya IP Office v9 remote site phone failing
-
@lilbludvl Sorry, been AFK for some time. Try running an IP scanner and see if there's a duplicated IP, or try changing the allocated IP for the phone and see if anything changes...
-
No worries. Welcome back. Hope all is well. So, I ran an IP Scan with "Angry IP Scanner" and it just shows the phone on that IP. I've changed the IP from 20 to 50. Problem still exists. I have two "remote" locations that I'm working this issue with. One has since died (bad hardware for the pfSense). The other is between two VMs on separate internet connections and carriers. It's odd that everything but the phone is working fine. The phone is even able to say "here I am" to the system but can't seem to lock in after that.
-
Check the state table in pfSense when the phone is connecting. Make sure you have states on all 4 interfaces involved for everything from the phone to the pbx. Make sure it's not opening states on the wrong interface indicating traffic routed incorrectly.
Check the firewall logs for anything blocked.Did those Cisco devices have any sort of SIP ALG that might have been correcting misconfigured phones? pfSense obviously doesn't have that.
Steve
-
@stephenw10
Good morning stephenw, I've uploaded a txt file copy of the states record from the HQ pFSense.
I do not see anything with the phone, PBX, or pfsense LAN IPs in the list from the firewall log.
No SIP ALG on the Ciscos. Basic IPSec tunnels on those were used. Only routed LAN traffic between the tunnels, everything else went out the WAN interface directly to the internet.
I have to be missing something but for the life of me I can't find it.States_hq_pfsense.txt -
Why is it NATing all the traffic leaving the LAN? That looks wrong and could definitely be causing a problem here.
If your outbound NAT rules are set to auto still that implies you have a gateway set on the LAN interface which is probably not what you want.
The phone and PBX should be able to reach each other without any NATing in either direction in that sort of setup.
Steve
-
@stephenw10
Might be onto something. I do have a single outbound NAT rule for the inbound port forwarding. I'm forwarding ports 80 and 443 for a webserver we have in-house. The outbound NAT rule is as follows:
LAN - any - * - 10.10.0.0/16 - * - LAN address - * - crossing arrows - "External Routing for Port Forwarding"
Could that be the problem right there? -
Yes, that's probably it if that's source 'any', destination '10.10/16'.
That rule should be far more specific if it's allowing access to just one server IP. You might also question why you need that rule at all..... different subject though.
Steve
-
@stephenw10
I'll try it both ways, removing it entirely and narrowing it down to just from that server. I'll report back shortly. :) -
[SOLVED] Thanks to @stevenw10.
That was it!!! I narrowed the NAT to specify the destination to 10.10.0.10 (webserver) and now the phone is locking in and ready for use. WOOOHOOO! Thank you Steve. :)Edit: updated to include "SOLVED" at start.
-
Nice.
-
@stephenw10
Based on the idea you had about why I needed that rule at all, I went ahead and disabled that rule. Everything seems to still be working just fine. Guess that's what happens when you follow some guides on how to do things. The guide I followed was accurate to get the forwarding to work properly, but it was also why I added that NAT rule. If you can, can you update the title of this thread to include [SOLVED] in it, just in case anyone else runs across this. Thanks again for help. :)
