[SOLVED] Avaya IP Office v9 remote site phone failing
-
Additional info it helps... I just wiped out the OpenVPN configuration and rebuilt it based on the following guide form NetGate: https://docs.netgate.com/pfsense/en/latest/book/openvpn/site-to-site-example-configuration-shared-key.html
Tried again and still no connection for the phone. Trace from montitor:
4179753959mS H323Evt: Recv GRQ from ac10010a
4179753960mS H323Evt: e_H225_AliasAddress_dialedDigits alias
4179753960mS H323Evt: found number <EXT #>
4179754009mS H323Evt: Recv: RegistrationRequest 10.11.0.20; Endpoints registered: 32; Endpoints in registration: 1
4179754009mS H323Evt: e_H225_AliasAddress_dialedDigits alias
4179754010mS H323Evt: found number <EXT #>
4179754010mS H323Evt: RRQ --- CallSigProtocol is H323AnnexL_P. Go for Avaya 4600IP phone
4179754010mS H323Evt: RRQ --- Treat this as a forced login, the phone was probably rebooted (same_cs_addr 1)
4179754010mS H323Evt: GK: Unregister endpoint <IPO> for extension <EXT#> reason 4
4179754011mS H323Evt: RRQ --- Register extn <EXT#> using product IP_Phone, version 6.8202
4179754012mS H323Evt: v=(null) stacknum=0 State, new=NullState, old=NullState id=0
4179754203mS H323Evt: v=0 stacknum=250 State, new=NullState, old=NullState id=-1 -
Does anyone have any ideas of what to try that I may be missing in this? What I could look at or try? I've run into a wall and can't seem to jump high enough on my own to get over it. Thanks for any help. :)
-
@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. :)
