Remote to Local

[bstamper]

We have an existing 3CX deployment where the 3CX server is "in the cloud". All the phones at all the sites register direct to the public IP that is inbound nat'd to the the 3CX. No issues here. Now, we're implementing SD-WAN and we've put an SDWAN device local to the 3CX server so it can be on the WAN and we can hit it direct via is private address. We essentially put 3 static routes in the 3CX for the private ranges 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and pointed them all to the SDWAN box. From our other locations we can ping the IP of the 3CX server and connectivity looks good.

Now, we go into the 3CX and change the Provisioning from Direct SIP to Local LAN and reprovision the phone. The phone reaches out and registers up. In the SDWAN we see the flows from phone to 3CX direct on the private IP and all good.

Now, we go to make a call, call goes but we've got 1 way audio. When we look at the flows on the SDWAN we see the server is sourcing traffic from its configured public address. So the audio looks like this:
3CX Server -> Phone
PublicIP -> Phone IP

Phone to 3CX Server
Phone IP -> Private IP

I built a replica environment to do some testing and I have no idea how this is even happening but the packet capture doesn't lie. The 3CX is sourcing its traffic from the configured Public IP.

Just curious if anyone has any idea how this would be happening?

 

[leejor]

In the 3CX Activity Log, what does a set registration look like? Does it show the set registering as the public IP plus local port? It sounds as if you are trying to use a device to (in a way), replicate the 3CX SBC.
You don't say which direction audio is working.

 

[JohnS_3CX]

Hi,

Firstly here is our supported network configurations. I think your description probably falls within the "Routed Network" description. This is a good starting point for when you are building a network https://www.3cx.com/blog/docs/network-configurations-supported-3cx-phone-system/

Secondly, do not reprovision the phones. You should factory reset them, and see if they appear in the management console as new phones with their local IP. This requires that the multicast messages from the phones, can reach the PBX NIC which is already listening for phones on 224.0.1.75.

Once the phone is configured as a local phone, it will know nothing of the 3CX FQDN nor will it attempt to resolve its public IP. Same goes for the PBX of course.

Be careful though, a previously added STUN phone will still query the RPS server and try to autoprovision. Do not give it any credentials when they appear on the screen, just use our guides to provision it as a LAN phone. Double-check from the phone's UI when all is done, to ensure that the SIP registrar and the paths for autoprovisioning include the PBX's LAN IP only (not the FQDN).