Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    [SOLVED] Avaya IP Office v9 remote site phone failing

    Scheduled Pinned Locked Moved General pfSense Questions
    18 Posts 3 Posters 2.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • L
      lilbludvl
      last edited by stephenw10

      Hello all,
      I hope I'm not beating a dead horse here, but I am working on an Avaya IP Office v9.0 with 9608G VoIP phones. I have two locations using pfsense to connect via OpenVPN tunnels. Everything seems to be working fine except the Avaya phones will not fully connect. They were able to connect to a webserver to update (at the head site), but nothing past trying to login. I've tried with IPSec tunnels between the pfsense units, an IPSec tunnel directly from the phone to the head pfsense, all with no success. When passing them through the VPN tunnels between the pfSense the phone seems to constantly reset (not a full reboot) after entering the extension for login. When connected directly from the phone to the head pfsense via IKEv1, it hangs at "Discover ...". I'm not sure what I could be missing. Any help is appreciated.

      P 1 Reply Last reply Reply Quote 0
      • P
        Paulk201270 @lilbludvl
        last edited by

        @lilbludvl Did you check the config on the phones as to what IP they are connecting to at the remote end...? I have 2 sites with similar layout that I am about to change from an older Cisco 4402 dual WAN router to a PfSense so would hate to hit a similar problem. You can test the ping from site a with phones to phone system at site b etc...

        L 1 Reply Last reply Reply Quote 0
        • L
          lilbludvl @Paulk201270
          last edited by

          @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".

          1 Reply Last reply Reply Quote 0
          • P
            Paulk201270
            last edited by

            @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??

            L 1 Reply Last reply Reply Quote 0
            • L
              lilbludvl @Paulk201270
              last edited by lilbludvl

              @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:

              1. <1ms <1ms <1ms 10.11.0.1 (site b default gate pfsense)
              2. 44ms 41ms 39ms 10.1.1.1 (IP of site a for the tunnel, pfsense, 10.1.1.2 is site b)
              3. 44ms 45ms 42ms 10.10.5.1 (IPO)

              edit: Had IP for site a tunnel backwards. Correct info now there.

              L 1 Reply Last reply Reply Quote 0
              • L
                lilbludvl @lilbludvl
                last edited by

                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

                1 Reply Last reply Reply Quote 0
                • L
                  lilbludvl
                  last edited by

                  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. :)

                  P 1 Reply Last reply Reply Quote 0
                  • P
                    Paulk201270 @lilbludvl
                    last edited by

                    @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...

                    1 Reply Last reply Reply Quote 0
                    • L
                      lilbludvl
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        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

                        L 1 Reply Last reply Reply Quote 0
                        • L
                          lilbludvl @stephenw10
                          last edited by

                          @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

                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            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

                            L 1 Reply Last reply Reply Quote 0
                            • L
                              lilbludvl @stephenw10
                              last edited by

                              @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?

                              1 Reply Last reply Reply Quote 0
                              • stephenw10S
                                stephenw10 Netgate Administrator
                                last edited by stephenw10

                                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

                                L 3 Replies Last reply Reply Quote 0
                                • L
                                  lilbludvl @stephenw10
                                  last edited by

                                  @stephenw10
                                  I'll try it both ways, removing it entirely and narrowing it down to just from that server. I'll report back shortly. :)

                                  1 Reply Last reply Reply Quote 0
                                  • L
                                    lilbludvl @stephenw10
                                    last edited by lilbludvl

                                    [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.

                                    1 Reply Last reply Reply Quote 0
                                    • stephenw10S
                                      stephenw10 Netgate Administrator
                                      last edited by

                                      Nice. 👍

                                      1 Reply Last reply Reply Quote 0
                                      • L
                                        lilbludvl @stephenw10
                                        last edited by

                                        @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. :)

                                        1 Reply Last reply Reply Quote 0
                                        • First post
                                          Last post
                                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.