Solved Elastix: phones lose registration
-
@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. -
Well, that or make who ever runs the network figure out what is happening on their side.
-
@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?
-
@JaredBusch said:
Well, that or make who ever runs the network figure out what is happening on their side.
That is proving difficult.
-
-
@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.
-
@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.
-
Yeah, that is very fishy.
-
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... -
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.
-
@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?
-
@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.
-
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!
-
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.
-
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!
