ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Solved Elastix: phones lose registration

    IT Discussion
    freepbx elastix centos
    6
    46
    11.8k
    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.
    • scottalanmillerS
      scottalanmiller @coliver
      last edited by

      @coliver said:

      Would the usage of a STUN server solve this issue?

      Should not be any NAT.

      JaredBuschJ 1 Reply Last reply Reply Quote 0
      • JaredBuschJ
        JaredBusch @coliver
        last edited by

        @coliver said:

        @JaredBusch said:

        @g.jacobse said:

        Confirmed. Switch as the other end of the VPN.

        Change the phones to use some port other than 5060 for the SIP registration.
        Make sure they are all different as you cannot reuse the same port behind a NAT and this issue is looking to me like that.

        Would the usage of a STUN server solve this issue?

        Yes, but you would have to set one up internally as they obviously have everything inside the VPN.

        1 Reply Last reply Reply Quote 0
        • JaredBuschJ
          JaredBusch @scottalanmiller
          last edited by

          @scottalanmiller said:

          @coliver said:

          Would the usage of a STUN server solve this issue?

          Should not be any NAT.

          Should not be any NAT, but it sure is acting like it if everything is reporting the same MAC.

          DashrenderD 1 Reply Last reply Reply Quote 0
          • scottalanmillerS
            scottalanmiller
            last edited by

            Yeah, that is very fishy.

            1 Reply Last reply Reply Quote 0
            • gjacobseG
              gjacobse
              last edited by

              Statement I was given regarding the MACs

              ...as an aside, this has nothing to do with the, or any, firewall.  This is normal layer2/layer3 handoff in any network...
              
              1 Reply Last reply Reply Quote 0
              • NetworkNerdN
                NetworkNerd
                last edited by

                To give background here, the Fortigate has a Juniper L3 switch connected to it. Supposedly the config on that guy has not changed, but I don't think we really know.

                1 Reply Last reply Reply Quote 0
                • DashrenderD
                  Dashrender @JaredBusch
                  last edited by Dashrender

                  @JaredBusch said:

                  @scottalanmiller said:

                  @coliver said:

                  Would the usage of a STUN server solve this issue?

                  Should not be any NAT.

                  Should not be any NAT, but it sure is acting like it if everything is reporting the same MAC.

                  Is that right? Wouldn't you always loose the originating MAC if you go through a router of any kind? i.e. a VPN?

                  JaredBuschJ 1 Reply Last reply Reply Quote 0
                  • JaredBuschJ
                    JaredBusch @Dashrender
                    last edited by

                    @Dashrender said:

                    Is that right? Wouldn't you always loose the originating MAC if you go through a router of any kind? i.e. a VPN?

                    It depends on the VPN. It can easily bridge at either Level 2 or Level 3. One will let everything pass through, the other would show the MAC form the bridge. Either way, as long as there is no NAT, it should not interfere. That is true.

                    Just the description of the problem fits more to a NAT scenario.

                    1 Reply Last reply Reply Quote 0
                    • gjacobseG
                      gjacobse
                      last edited by

                      Speaking with a 3rd party network tech who is one site. We have three phones aren't connecting - turns out that one of the POE ports was bad...

                      One is bad,.. more is likely. replace the switch!

                      1 Reply Last reply Reply Quote 1
                      • gjacobseG
                        gjacobse
                        last edited by

                        Looks like more than one port is bad as far as POE goes.

                        got down to it being either the phone itself or the port, but ports were 'testing' okay. Defaulted the three phones that were missing and they now have IP addresses where we can get to them and program them.

                        Sad news is that during all this,.. they broke the VPN and we can't get in.

                        Interestingly on that note, they have a Fortigate 60D at that site. they can't update the firmware to do the testing they need. Hmm.. Firmware update failed... make you wonder.

                        Glad to see we didn't lose three phones though. Losing a port on the Juniper is bad enough (just the POE side it seems)... but still.

                        1 Reply Last reply Reply Quote 0
                        • scottalanmillerS
                          scottalanmiller
                          last edited by

                          Wow, on a high end Juniper switch? That's more bad ports on a single Juniper than I've seen first hand on decades of use of Netgear!

                          1 Reply Last reply Reply Quote 0
                          • 1
                          • 2
                          • 3
                          • 3 / 3
                          • First post
                            Last post