[Security] Only allow softphone to work on internal network

[svenv]

Hi,

We have an issue whereby our sales and dispatch people share the QR code with others or call from home using their device. They have irregular schedules so it's hard to maintain a schedule within 3cx and disable external calls from an extension past working hours. We also have a lot of calls so we're not able to properly control whether the calls are personal or commercial.

I have 3 ideas to solve this, but none of them seem to be possible with 3cx.

1. Only whitelist the internal network IP address to be able to access the webclient / softphone. Not ideal as it also blocks the console and static IP address of ISP could potentially change (we experience this every 1-2 months) which would entirely block us.
2. Disable QR code login so they have to use the normal way of logging in. Seriously, it's so easy to share a QR image, take a picture, send and everyone can just access it. This should not be possible for an Enterprise solution or it should at least be possible to disable.
3. Only allow log in through SSO. We have this with Cloudflare Access for our system. Our employees can only access our ERP system with their MS account and when they are on the internal network (static IP). So they can't access from home or anywhere else. Admins can access from anywhere with their MS account (different Azure AD group).

3 would be the best solution.

Any (other) ideas?

 

[NicholasP_3CX]

Hi @svenv,

You can block them from connecting via the Tunnel from outside the network.

 

[svenv]

Hi @NicholasP_3CX

So for this we require an SBC inside our network? It seems this is for IP Phones? Or it automatically works for the softphone and webclient phone extensions?

 

[NicholasP_3CX]

This also applies for the 3CX Apps.

 

[svenv]

Any other solution that doesn't need a raspberry pi? (they are not super reliable)

 

[bitn2]

You dont need a SBC from inside. This will block the app and the SBC from OUTSIDE the network.

 

[NicholasP_3CX]

That option block the tunnel connection which the 3CX apps use, and the SBC uses to connect IP Phones from outside the network.

 

[svenv]

So where can I specify what's the internal network IP address?

 

[NicholasP_3CX]

@svenv you do not need to do anything extra.

Your users are currently connecting from outside the network. You want to prevent them from connecting. You literally just need to enable that option and they will NOT be able to connect.

 

[svenv]

They should be able to connect inside our network though how else are they making/receiving calls? How does 3cx now what is our network without me specifying our IP?

 

[NicholasP_3CX]

The app will detect within its settings that it is outside the network and connect through the tunnel. The tunnel only connects from outside the network.

Trust me on this one.

 

[SweetAction]

It probably looks at the IP and if it's any of the RFC1918 IPs (192.168/16, 172.16/12, 10/8) it's considered internal.
Or it might probe some port that wouldn't be forwarded from external but is available when local.

 

[Vali_3CX]

@svenv
This "only internal" issue popped-out regularly since, well, 2008 Bottom line - app cannot safely distinguish what "internal" means, with the notable exception that it's in the same subnet as the PBX, and this is, as I said, an exception in real-life environments. Usually client can move/connect to different WiFis on the same physical office, the PBX might be located in a different country but VPN-ed, and so on.

 

[svenv]

Thank you all. So basically it's not possible then? Because most WiFi networks have the RFC1918 IPs (192.168/16, 172.16/12, 10/8), so an employee connecting to their network at home will just be able to connect despite blocking remote tunnel connections.

 

[SweetAction]

The RFC1918 networks at the customers house don't matter BECAUSE the connection to the PBX is via WAN so the IP presented to 3CX will be non RFC-1918.

Lookup 3cx.example.fqdn from inside network - result is 192.168.1.2 - must be internal.
Lookup 3cx.example.fqdn from outside network - result is 1.2.3.4 - must be external.

If you block remote tunnel it will block external users.