[SOLVED] Avaya IP Office v9 remote site phone failing
-
@Paulk201270
Yep. Phones are getting a DHCP reservation with option 242 set with the following:
MCIPADD=<IPOs IP>,MCPORT-1719,HTTPSRVR=<HTTP IP>
My previous employer and also this one, have Cisco's (2900, 1900, 1800 series) currently doing the VPNs and the Avaya's work fine over them. Not sure why the pfsense are having this issue. Basic run down: I can ping from computer at site b to computers, printers, IPO, and servers at site a. Computer at site a can ping computers, printers, and even the phone at site b. Phone is able to connect to the HTTP server and get it's updates. It's also able to connect to the IPO (when going across the pfsense VPN), but as soon as I enter it's extension for login that's when it fails. Using the phones built in IKEv1 VPN connecting to site a's pfsense the phone just hangs at "Discover...". The monitor app on the Avaya system shows this line: "Unregister endpoint <endpoint ID> for extension 8900 reason 4". -
@lilbludvl said in Avaya IP Office v9 remote site phone failing:
Unregister endpoint
What IP range is the phone getting and that of the Avaya system, are there any rules on the IPSEC interfaces that might prevent the SIP or final registration traffic??
-
@Paulk201270
For example purpose lets say site a is 10.10.0.0/16, site b: 10.11.0.0/24.
The phone is getting a reserved DHCP on site b of 10.11.0.20. The IPO has 10.10.5.1. The firewall setting on both sides for the vpn traffic is allow any any across the tunnel. Site a's default gateway is a different router (Cisco-10.10.1.1) that has a route for all 10.11.0.0/24 traffic to go to the pfsense 10.10.1.5. A tracert to the IPO from site b computer 10.11.0.100 is as follows:- <1ms <1ms <1ms 10.11.0.1 (site b default gate pfsense)
- 44ms 41ms 39ms 10.1.1.1 (IP of site a for the tunnel, pfsense, 10.1.1.2 is site b)
- 44ms 45ms 42ms 10.10.5.1 (IPO)
edit: Had IP for site a tunnel backwards. Correct info now there.
-
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. :)
