Remote Phones over VPN

[Chaz]

Our 3CX is now on google cloud, and we have a SBC in our office. Those phones are working fine. On the other side of our new watchguard VPN, the phones are not working. They were working by using stun, but when we switched to have them point towards the SBC on the otherside of the VPN, we are not registering.

I am questioning that the VPN is fully setup to let the traffic flow. Right now one phone says "sip register failed".

Thanks

 

[Chaz]

I can also ping the phones across the VPN where the SBC resides.
Thanks,
Chaz

 

[JohnS_3CX]

Hi Chaz,

If you have a 2nd site (VPN'd into your primary site) then you might consider adding an SBC there too.

However, I don't see any any reason why it should not work the way you set it up currently.

If the secondary site is logically on the same network as your primary, and there is nothing* blocking the traffic then you should be able to get it to work.

When you switched them, did you make sure to reset them and reprovision them from the management console? Or did they not appear as bold in your Phones section?

 

[jasit]

depends if your firewall is using sip alg, you might not have had to remove it in the past

 

[eddv123]

In a standard VPN setup (SBC and STUN ignored) there are often several issues I have encountered all network related I have listed then for you below:

* Phase 2 settings are what control traffic flow on a VPN (phase 1 the initial connection) ensure your P2 settings match at each end.

* Most VPN's have an interface/firewall setting that requires allowance of traffic through, often I have known it to occur that the VPN is setup but the interface (at both or either end) has remained with a blocked interface.

* If the above fails a test you can try is login to a remote phone and firstly (I hope you are using Yealinks as they support these features) PING from the phone interface to the local IP of the PBX, then trace route and ensure if they work they are taking the correct route.

* Lastly try logging into a phone interface (another test) and try setting the transport type from UDP to TCP in the main account - does it register ? I have found far better results with TCP for SIP transport despite 3CX not officially supporting this on hardware just yet.

 

[JohnS_3CX]

I* If the above fails a test you can try is login to a remote phone and firstly (I hope you are using Yealinks as they support these features) PING from the phone interface to the local IP of the PBX, then trace route and ensure if they work they are taking the correct route

@Chaz this would be the local IP of the SBC for your case

 

[Chaz]

Awesome Guy's. Thank you. I will work on all this.

 

[JohnS_3CX]

An important thing to note: Phones can autoprovision via the SBC when you factory reset them. They will send out a multicast message that the SBC should see, and cause them to appear in bold in your Phones section so you can assign them to extensions. For this to work however, the VPN you set up must also allow those multicast messages to pass.

Running a capture on a PC connected to the same lan from your main site, should show you those messages arriving from the other side of the VPN where the remote office is. Here's an exact sample:

https://www.3cx.com/docs/plug-and-play-ip-phone/

 

[eddv123]

VPN you set up must also allow those multicast messages to pass.

@JohnS_3CX I assume you are referring to IPSec over GRE here?

See "IPsec Deployment with Point-to-Point GRE": https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/V3PNIPmc.html

To my knowledge the situation has not changed, however it was my understanding that multicast traffic was not supported via standard IPSec tunnels - only with the addition of IPSec - GRE.

 

[JohnS_3CX]

Hi Ed,

For the sake of argument, I'm agnostic to the type of tunnel being used.

The main idea is that those messages can reach the other end of the tubes