Auto provisioning - Double NAT + VLANs

I’ve read:

I have double NAT with VLANS on the interior router LAN.

  • Ports 1443 and 84 are forward from edge router to interior router and interior to PBX, port checker is showing open.
  • SIP trunks function fine and send and receive calls(when phones are manually provisioned).
  • Phones and PBX on same VLAN. Firmware 2.0.4.36. All modules up to date. PnP enabled. Correct profile for phones.
  • Network scan allows extension to be mapped in EPM.
  • Phone ports are tagged with VoIP VLAN to enable receiving DHCP from VoIP network.

I’ve tried:

  • HTTP, HTTPS,
  • auth, no auth,
  • external(FQDN, WAN IP), internal
  • http(s)://username:password@hostname:port
  • disable firewall

Each time I’d change any of the above in the PBX, I’d make sure the portal knew the right auth and port.

Portal shows poll counts going up and timestamps. Phones will not pull a config via PnP or redirect. Manual is only way to successfully provision. End goal is to use VPN for remote workers, but I can’t even get a simple provision to work. I don’t understand why the PnP won’t even work since everything is local on same network. And I’d think the double NAT isn’t the issue if my trunks and routes work for calls, and with the ports forwarded. Two days, nothing but frustration. What other steps am I missing?

Wiped phones, started over, using local address, HTTPS, it says success, but nothing happens.

/var/log/httpd/access_log shows:
GET /factory0500.bin HTTP/1.1
GET /cfg0500.xml HTTP/1.1
GET /MAC_ADDRESS.cfg HTTP/1.1
GET /MAC_ADDRESS HTTP/1.1
GET /MAC_ADDRESS.xml HTTP/1.1
GET /fw500.rom HTTP/1.1

/var/log/httpd/error_log shows:
[error] [client 192.168.4.12] File does not exist: /var/www/html/ALL_THE_ABOVE_FILES

Are you using the correct port for provisioning? System Admin, Port Management.

Are you using http/https provisioning credentials? System Admin, Provisioning protocols.

I’ve tried both auth and no auth

Lorne, thanks for your replies. Anybody else have ideas? I have done the research and troubleshooting that I am aware of. I’m not lazy waiting for someone to give me handouts. I just don’t know what else I’m supposed to do to get ZTP to work. I seems as though it’s supposed to be fairly easy according to the wiki.

Sounds like your VLANs are getting in the way. The default VLAN has to have access to the PBX for the phones to be able to reach the PBX and get their configs.

Thanks for the reply Tony. I’ve switch the PBX, my computer, and the phone over to a un managed switch with no VLANs, uplinked directly to the router with the ports forwarded. Port checker shows correct port open. PBX can successfully talk to the internet. I’ve verified auth info, provisioning port both in the EPM and the portal. I’ve factory reset probably 25 times each time I make a change. What else can I check to troubleshoot?

The only way I can provision is PnP. Disabled PnP. Disabled the firewall on the PBX as well. Redirect still won’t work.

I would contact support. You get free support on the phones https://support.sangoma.com Maybe you have redirect in our portal setup wrong with the URL??? I did lookup your account quickly and you have redirect setup going to a public IP but you are stating here its all on a LAN. Most firewalls dont let you pigeon hole back in by default where you go out and come back to the public IP. Change the redirect server to use your LAN IP of the PBX since the phones are on the same LAN.

I appreciate your help very much!! But alas I have tried LAN IP address in the beginning and wondered if I was supposed to tell it WAN IP since it’d be coming from the RS. I’ll try LAN again.

That leads me to a second question: what about my remote clients? Will they need me to jump into the portal to change the address to WAN to provision, and then back to LAN for my local phones provisioning?

I cant answer your remote phone question as that is all in how you setup your network but if the phone is on local LAN you need to use the LAN IP as stated most routers wont let you go out the WAN and come back in.

I tried LAN IP. No joy. Opened ticket. Will update.

For anyone reading this, for some reason the culprit was the deployment redirect not functioning. Lorne took the phones off of the deployment and used the individual redirect (http://username:password@hostname:port) PER PHONE and boom, everything worked. He is going to research/escalate the deployment redirect issue. Lorne was a tremendous help figuring this out, thank you!

As a side note for anyone else following, when I put the equipment on the non VLAN switch and router via Tony’s help, I also forgot to take the VLANs out of the EPM template. Once I did that, and Lorne took the phones off the deployment, everything worked.

Will update this with news of the deployment problem findings.

Also, for anyone that was curious about remote + deployment, Lorne said you must take the remote phones off the deployment redirect and use per phone redirect via http(s)://username:password@FQDN or WAN IP:port

With deployment redirect it doesn’t know difference between WAN or LAN. You define the IP address and it uses that so its whatever you define in the deployment.

When you were using deployment type for the redirect server did you define http:// or https:// before the IP address as that is required to know what protocol you are using.

[quote=“tlewis, post:17, topic:45147, full:true”]
With deployment redirect it doesn’t know difference between WAN or LAN. You define the IP address and it uses that so its whatever you define in the deployment.
[/quote] Gotcha, thanks.

[quote=“tlewis, post:18, topic:45147, full:true”]
When you were using deployment type for the redirect server did you define http:// or https:// before the IP address as that is required to know what protocol you are using.
[/quote] The screen (attached) I see shows the ability to define the provisioning port, so I assumed that would tell it which protocol (beings that the PBX informed me that port 84 is the default for HTTP). Am I incorrect?

Just tried putting http:// before the IP address in the portal deployment settings. Booted up a brand new S500 out of the box. Nothing. Took the phone out of the deployment, put those same details in the individual settings, phone provisions fine. Lorne said he was able to replicate this in his own testing and he’d be escalating. I’ll update with findings.

1 Like