Solved Automatic provisioning doesn't work

[IGIT]

So I've been searching every single forum post on this issue and still couldn't find a fix. Here's the case: I cannot automatically provision my SNOM telephone (D375, latest firmware). Our network consists of our DMZ and our LAN. There is communication between 3CX Server and the phones (I can ping the phones from the server and vice versa). I checked for the latest firmware/updates - everything looks okay. Modified the nginx.conf file to allow my LAN - nothing changed. Checked if sip.multicast.net appeared on the 3CX Server - yes it appears. I configured DHCP Option 66 on the DC Server with the link that I also used for manual provisioning - didn't change anything. The cases when it works are 1. When I try to manually provision the telephone (adding the telephone on an extension and pasting the provisioning link to the phone settings). 2. The other case that works is when I simply add the telephone on an extension with its MAC addr., then after I reset the telephone it immediately gets provisioned. I can also download the config file from my browser when I try to access the Provisioning link - http://xxxxx:5000/provisioning/xxxxxxxxxxxxxxxx75g/cfgMAC. I also did a Wireshark capture and I can see that the phone sends a HTTP GET request to the server with the right MAC Adress on the right path and the server responds with HTTP 1.1 404 Not Found. There is no SIP traffic between the two at all and thus no REGISTER/SUBSCRIBE Packets. (Note: I restarted the server and the telephone multiple times)

 

[JohnS_3CX]

You can also run a capture on the phone interface (after you factory reset it) and then provision it from the phones section when it appears in bold.

The capture should show a notify message coming from the PBX telling the phone what URL to use to provision itself.

A simultaneous capture on the PBX interface should show the message being sent out (so you can double-check)

 

[IGIT]

You can also run a capture on the phone interface (after you factory reset it) and then provision it from the phones section when it appears in bold.

The capture should show a notify message coming from the PBX telling the phone what URL to use to provision itself.

A simultaneous capture on the PBX interface should show the message being sent out (so you can double-check)

The phone doesn't appear in the phones section at all and it was like this since I installed 3CX. But at that time we already had another PBX and I thought that it was its fault. Now after 6 months we have completely deleted the old PBX and all its entries. So some days ago I needed to add another phone on our office and I came across this issue.

 

[JohnS_3CX]

Well that may be part of the issue you are facing, and you should really start by learning why it does not appear.

Hint: You said sip multicast appears on the server, but this does not mean necessarily that multicast messages from phones can actually reach your server. Your network may not be allowing those messages. Or maybe you have more than one interface on your server, so disable them all except the one you will use, and restart your services.

So what you need to do is in two parts:

1) Mirror a switch port on the phones network, and see if the device sends a multicast subscribe message to 224.0.1.75 when you factory reset it

2) Run a capture on your PBX at the same time to see if such message arrives. Having only a single network interface on the server will help make the task easier.

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

 

[IGIT]

Well that may be part of the issue you are facing, and you should really start by learning why it does not appear.

Hint: You said sip multicast appears on the server, but this does not mean necessarily that multicast messages from phones can actually reach your server. Your network may not be allowing those messages. Or maybe you have more than one interface on your server, so disable them all except the one you will use, and restart your services.

So what you need to do is in two parts:

1) Mirror a switch port on the phones network, and see if the device sends a multicast subscribe message to 224.0.1.75 when you factory reset it

2) Run a capture on your PBX at the same time to see if such message arrives. Having only a single network interface on the server will help make the task easier.

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

From the Switch mirroring I can see that a multicast subscribe message is being sent to 224.0.1.75 but when I look at the PBX capture I cannot find any multicast subscribe messages.

 

[JohnS_3CX]

Ah then it appears that whatever stands between the phones and PBX is not allowing this message to pass through.

You mentioned DMZ network and your LAN. Is the PBX in the DMZ network?

 

[IGIT]

Ah then it appears that whatever stands between the phones and PBX is not allowing this message to pass through.

You mentioned DMZ network and your LAN. Is the PBX in the DMZ network?

Yes the PBX is in the DMZ network and I can communicate between the two networks as mentioned. However I also do not understand why the DHCP Option 66 doesn't have any effect, it worked just fine with the old PBX.

 

[JohnS_3CX]

The type of setup you use probably blocks multicast from going across the two networks. If you allow traffic between the two sides, you should also look at whether you can allow multicast to pass through too.

As for Option 66, it just tells the phone where to look to get provisioned. So assuming it contains the correct URL, and assuming that URL is accessible by the phone (run a capture to confirm!), then it should in theory work. You did say however that you also modified your nginx configuration, and this could potentially be a reason for making the provisioning server fail.

 

[JohnS_3CX]

Note that for Snom phones specifically the correct URL should end in cfg{mac} like this example:

http://10.20.30.40:5000/provisioning/kdj7ja6ek0/cfg{mac}

 

[IGIT]

The type of setup you use probably blocks multicast from going across the two networks. If you allow traffic between the two sides, you should also look at whether you can allow multicast to pass through too.

As for Option 66, it just tells the phone where to look to get provisioned. So assuming it contains the correct URL, and assuming that URL is accessible by the phone (run a capture to confirm!), then it should in theory work. You did say however that you also modified your nginx configuration, and this could potentially be a reason for making the provisioning server fail.

Traffic between the two sides is set to allow all.
Do you mean running a capture on the PBX when I manually provision the phone?(The provisioning link is completely correct and it works when I use it on my browser or when I try to manually provision the phones)

Nginx was modified yesterday only after not finding any other solutions.

 

[IGIT]

@JohnS_3CX I also need to mention that all this time I had DHCP Option 66 activated and now I deactivated it. Afterwards I ran a capture on the PBX and reseted the phone, I can see that there is no traffic between the PBX and the phone at all. As you said the multicast packets are being blocked somewhere but I do not really know where. (I also ran a capture with the port mirroring again and I can see that multicast packets are being sent, also after the DHCP changes)
So with what I can understand is that the DHCP Server force pushes the config to the phone but the phone cannot access the HTTP or something like this. This is also weird cause it would make things way easier.

 

[JohnS_3CX]

Hi,

What I meant was running a capture on the phone's mirrored port then factory reset it and wait until it boots up, so you can see the communication between the phone and the DHCP server (for Option 66)
If direct URL provisioning works as you said, then theoretically Option 66 should have also worked.

That aside and regarding the the other matter of multicast, If you do not see the multicast message arriving on the the PBX NIC then it could mean that simply allowing all traffic as you did, was not enough to allow multicast messages too. I'm just speculating but you may need to set up some type of general routing encapsulation to allow that to pass. It really comes down to how the network is set up and the equipment you use - something that I cannot be of much assistance with I'm afraid.

 

[IGIT]

@JohnS_3CX Thank you for your tireless work and for helping me and many others out there to figure out how to solve 3CX problems.
I have solved it by adding a new multicast policy on our Fortigate Firewall that allows multicast traffic from LAN to DMZ.

 

[JohnS_3CX]

Really glad to hear that it is solved, and thanks for sharing your Fortigate solution.