Block WAN requests is only checking for Private IPv4 not if subnet of network matches the PBX

[QueBall]

Ran into what I thought was a strange behaviour and likely should be considered a bug or at least a lazy programmer.

Client has a pool of public IPs assigned to the company so they use legitimate ARIN assigned IP addresses on their internal network (probably got them in the early 90's when you just had to ask nicely). So instead of doing NAT their firewall just filters traffic without translation. Nobody from the outside can connect to internal computers but each computer has a public IP and that entire subnet is considered the internal LAN.

Installed a trial 3cx for them to evaluate.
The 3cx server is installed internally with another legitimate public IP in the same subnet range as the phones.
So based on the network mask should indicate that these are on the LAN.

It appears like the checkbox for blocking "Disallow use of extension outside the LAN (Remote extensions using Direct SIP or STUN will be blocked)" is still blocking these local phones from registering because the filter is too dumb to check if the subnet of the network matches between the client and the local network card on the server. Not doing any vlan or routing tricks here. Essentially the phone and server are on the same dumb switch.

I would consider this a bug. It should recognize the local subnet as being on LAN in addition to assuming that 192.168.x.x, 10.x.x.x, and 172.16.x.x - 172.31.x.x are valid LAN addresses.

So now I have to allow registering from WAN on this site (or other workarounds I'm considering)

 

[cobaltit]

Just because they have the subnet doesn't mean they have to use it. There really isn't anything to be gained for having the network numbered that way.

But you can also just adjust the advanced parameter defining local subnets:

 

[cobaltit]

And I wouldn't classify this as a bug. 3CX is not a router or firewall, and you don't configure the network interface in 3CX. 3CX only sees the interface IP and is not looking for the subnet mask which would be required for it to know what the subnet actually is. I prefer 3CX to focus on doing phone stuff.

 

[QueBall]

But you can also just adjust the advanced parameter defining local subnets:

View attachment 18797

Thanks, the parameters hint looked like a winner but it does not fully work. It allows the phone to register, but the provisioning file download is blocked on port 5000 still so plug and play phone setup and reprovisioning fails making it only a partial fix to registration.

So still a bug in their software not recognizing what is local and doing a dumb hard coding of private IP space not finding the real LAN subnet range. This could even be considered a security issue if you are on an ISP that puts customers on a shared private IP space with carrier grade NAT. (Other customers would be considered on the LAN with this flawed logic)

In this case I have a workaround. Because this is a trial I wasn't trying to get everything on their network perfectly setup, but it looks like I will go ahead and build a voice VLAN, setup the switches, server, vmware, etc and that voice VLAN can be on private IP space to work around this 3cx bug.

 

[cobaltit]

Correct. That value only controls registration. The web server has it's own section. But there's no reason why you can't use a HTTPS URL internally.

 

[JohnS_3CX]

The software has been designed with the idea of either being fully public, or behind a private range.
So it expects local phones to exist in a RFC1918 network and you can consider this a requirement if you have local devices.

It will not do those additional checks for you, so in your case you fall in the situation were the system thinks you are trying to connect public network phones as private phones, and they will not be allowed to reach the local provisioning link. Only the HTTPS link is reachable from non RFC1918 networks.

 

[QueBall]

The software has been designed with the idea of either being fully public, or behind a private range.
So it expects local phones to exist in a RFC1918 network and you can consider this a requirement if you have local devices.

It will not do those additional checks for you, so in your case you fall in the situation were the system thinks you are trying to connect public network phones as private phones, and they will not be allowed to reach the local provisioning link. Only the HTTPS link is reachable from non RFC1918 networks.

Ok.

So you should log this as a defect. It should also be checking if the phone IP matches the subnet of the interface you select in " Network interface for registration and provisioning " when using "Local LAN (in the office)" as provisioning method.
By the very definition of the term local area network it should be considered a bug not to include that.

 

[JohnS_3CX]

That's out of the current design scope but actually not a bad idea.

If you want it added I would suggest to ask your 3CX partner to add it in the Ideas section so it can be voted.