Accessing the FreePBX UCP



  • There has to be something I'm missing here. :( The end goal is for all users to access the UCP using HTTPS.

    Going through FreePBX it looks like the way to do this is to go into System Admin > Port Management and for UCP disable the Insecure port, and set the Secure Port to 4443.

    The next thing I have to consider is the firewall. I have the FreePBX NIC set to the Internet zone and have added the local office IP (/32) to the Trusted zone. The UCP service (Connectivity > Firewall > Services) is set to the default setting of accessible from the following zones: Internet, Local, Other.

    Here is the behavior I'm expecting:
    From both our local office and other networks I should be able to load https://freepbxhost.tld/ucp

    Here is what's happening:
    From the local office I can load https://freepbxhost.tld/ucp.
    From other networks I cannot load that URL, but I can load https://freepbxhost.tld:4443.

    So it seems like the firewall is allowing traffic as it should, else I wouldn't be able to load https://freepbxhost.tld:4443. So the problem is likely how /ucp is being handled; however, I can't understand why I can use that URL from my office but not from a remote network.



  • @eddiejennings said in Accessing the FreePBX UCP:

    Here is what's happening:
    From the local office I can load https://freepbxhost.tld/ucp.
    From other networks I cannot load that URL, but I can load https://freepbxhost.tld:4443.

    I'm confused. These are two different ports. One is using 443 and the other is using 4443. Did you allow port 443 to the FreePBX host from the other network?


  • Service Provider

    I was wondering about that bit, too. Sounds like something is off with the port 443 forwarding.



  • Which makes sense, as the web management service is configured (by default) to only be accessible by traffic from the "local" zone. So I would expect traffic to 443 to be dropped from other networks.
    0_1506094700637_3ae3a5fd-d3d3-444e-ae7b-24b989288095-image.png
    From this, it looks like there would be some intelligence within FreePBX that would foward requests for the UCP page to a port other than 443, as the default non-secure port is 81 instead of 80.



  • The solution might be train external users to go to https://freepbxhost.tld:4443, but methinks there has to be a way to be able to use https://freepbxhost.tld/ucp.


  • Service Provider

    @eddiejennings said in Accessing the FreePBX UCP:

    Which makes sense, as the web management service is configured (by default) to only be accessible by traffic from the "local" zone. So I would expect traffic to 443 to be dropped from other networks.
    0_1506094700637_3ae3a5fd-d3d3-444e-ae7b-24b989288095-image.png
    From this, it looks like there would be some intelligence within FreePBX that would foward requests for the UCP page to a port other than 443, as the default non-secure port is 81 instead of 80.

    What about your outside firewall. Is there no firewall in front of the FreePBX box?



  • @scottalanmiller Only firewall between the FreePBX VM and the Internet would be whatever Vultr has on their network.

    So I decided to take a step back, and restore the default configuration (setting the insecure port for UCP to Port 81 from the graphic above).

    Afterward I did a few tests, and I believe this is the deal: /ucp must be serviced by port 80 / 443. Here is the default configuration from Connectivity > Firewall > Services.
    0_1506098948727_e0b2b0b6-53a8-4850-9be1-db0cf9fe9613-image.png

    With this configuration, the following URLs fail from the non-office network:
    http://freepbxhost.tld
    http://freepbxhost.tld/ucp

    If I set the Web Management service to be accessible from both Internet and Local, then those two URLs load when requested from the non-office network. This tells me that /ucp is directed to port 80, since, as an additional test, I went back into the System Admin (first graphic of the thread), disabled the UCP port 81, and was still able to load the /ucp URL.

    As a final test I re-enabled Port 81 for UCP in the System Admin module, kept Web Management accessible for Internet and Local in the Firewall module, and removed UCP from Internet accessibility in the Firewall module.

    0_1506100115680_ee69a65f-d6ac-4d41-b1dc-cc0c136daaf6-image.png

    From the non-office network, I was still able to access http://freepbxhost.tld/ucp. Just to see what would happen, I set the zone for UCP to reject (removing it from local and other) and was still able to access that URL.

    I replicated the same steps using https settings and https URLs instead. I also replicated this from two different networks.

    The conclusion seems to be that http(s)://freepbxhost.tld/ucp is serviced on port 80/443. The way to prevent external users from using the UCP over an insecure connection is by not adding Web Management to the Internet zone in the Firewall, but adding Web Management (Secure). Futher (and this seems wrong), it seems that the UCP service in the Firewall configuration doesn't seem affect accessing the UCP.



  • I wonder the need for the UCP direct link? If you just load the default page with Web Management Secure enabled, there is a button on the page for UCP, click it and go. Why manage this separately, unless you really need to make the admin page unaccessable via the internet in general.


  • Service Provider

    @dashrender in absolutely zero locations do I have the admin page open the the public.



  • @jaredbusch said in Accessing the FreePBX UCP:

    @dashrender in absolutely zero locations do I have the admin page open the the public.

    Do you have any instances where the UCP page is available to the public?


  • Service Provider

    @jaredbusch said in Accessing the FreePBX UCP:

    @dashrender in absolutely zero locations do I have the admin page open the the public.

    And when possible, not the UCP page either! :)



  • Alas, I don't see a way to not have my UCP page available, hence, the challenge :P



  • @jaredbusch said in Accessing the FreePBX UCP:

    @dashrender in absolutely zero locations do I have the admin page open the the public.

    If I remember correctly, you have your home and office IP whitelisted on the pbxs. Right? Or some other “jump box” type solution...


  • Service Provider

    @fuznutz04 said in Accessing the FreePBX UCP:

    @jaredbusch said in Accessing the FreePBX UCP:

    @dashrender in absolutely zero locations do I have the admin page open the the public.

    If I remember correctly, you have your home and office IP whitelisted on the pbxs. Right? Or some other “jump box” type solution...

    And if I need random access, I log into the host system (Vultr) and then grant access to my current IP.



  • @jaredbusch said in Accessing the FreePBX UCP:

    @dashrender in absolutely zero locations do I have the admin page open the the public.

    OK I over stated this - what I meant was - every location where a phone registers, it appears that have access to the admin page, and by extension the UCP page.

    I happen to be out of town now and I just checked. I don't have a phone registered here and I don't have access to either site.



  • @dashrender said in Accessing the FreePBX UCP:

    @jaredbusch said in Accessing the FreePBX UCP:

    @dashrender in absolutely zero locations do I have the admin page open the the public.

    OK I over stated this - what I meant was - every location where a phone registers, it appears that have access to the admin page, and by extension the UCP page.

    That should be the behavior; however, none of my test users can access the UCP page (they have phones registered at their homes). One of my tasks on Monday is setting up a phone at my own home to see if I, myself, can't access the UCP from my home network.



  • I will test the two office locations where I have phones tomorrow. This is a brand new install and they haven't used UCP yet.. not a lot of need at this point so we haven't tried it.



  • I am not sure why FreePBX doesnt allow the same responsive firewall setup for web based logins. If you have a phone and it authenticates from an IP, then the User CP is available on the public side.

    The idea of "I never expose XYZ portal to the public" isnt very helpful with a remote workforce. Imagine if you have to VPN to login to Office 365 or Gmail.

    I set the admin interface to a random port number and the default port 443 or 80 to the UCP, so no path is needed. I thought that was the standard way to do it. Where a phone has authenticated from a public IP so should the UCP then be accessible.

    I have moved entirely away from FreePBX so I have no instance to log in to ATM.



  • @bigbear said in Accessing the FreePBX UCP:

    I have moved entirely away from FreePBX so I have no instance to log in to ATM.

    What do you use now?



  • @bigbear said in Accessing the FreePBX UCP:

    Where a phone has authenticated from a public IP so should the UCP then be accessible.

    Right, this is my understanding as well. But this not exposing UCP to the public. This is the responsive firewall only opening UCP for those IPs that have valid registered extensions.



  • This post is deleted!


  • @dashrender said in Accessing the FreePBX UCP:

    @bigbear said in Accessing the FreePBX UCP:

    Where a phone has authenticated from a public IP so should the UCP then be accessible.

    Right, this is my understanding as well. But this not exposing UCP to the public. This is the responsive firewall only opening UCP for those IPs that have valid registered extensions.

    And I guess my point to that is what if someone wants to log in from home and change the main menu schedule (this actually happened to me with a couple customers) and they have no phone at home so they cant log in to the admin interface.



  • @dashrender said in Accessing the FreePBX UCP:

    @bigbear said in Accessing the FreePBX UCP:

    I have moved entirely away from FreePBX so I have no instance to log in to ATM.

    What do you use now?

    (edit: deleted my last post because I replied to the incorrect comment of your last two)

    Fusion PBX, Freeswitch, OpenSIPS for a few things but I am doing a multi-tenant thing. I would still agree if you want to run your own single tenant cloud PBX that FreePBX is easier in most respects.

    One thing I do love about anything Freeswitch-oriented is the use of domains over IP's for a better layer of security. You can afford to allow web UI logins from anywhere for a number of attempts when the attacker has to also discover the DNS name mapped to the IP to make the attempt. I shut off an IP from a web portal login after 10 attempts.

    Also for roaming mobile devices and Bria apps, etc there is no grief as there always is with FreePBX. And no updates that occasional broke my FreePBX installations.



  • @bigbear said in Accessing the FreePBX UCP:

    @dashrender said in Accessing the FreePBX UCP:

    @bigbear said in Accessing the FreePBX UCP:

    Where a phone has authenticated from a public IP so should the UCP then be accessible.

    Right, this is my understanding as well. But this not exposing UCP to the public. This is the responsive firewall only opening UCP for those IPs that have valid registered extensions.

    And I guess my point to that is what if someone wants to log in from home and change the main menu schedule (this actually happened to me with a couple customers) and they have no phone at home so they cant log in to the admin interface.

    Who would be doing that? That sounds like a situation that involves hourly employees, now you have other issues - i.e. people are working and you're not paying them. I know this doesn't directly give you what you want, but it's a possible side affect of what you're wanting.



  • But, if you really want anyone in your company to have UCP access, then just put it in the internet group, and you're golden. Of course, you're now opening it to the world of hackers to attack it.

    So you have to weight the trade offs.



  • @dashrender said in Accessing the FreePBX UCP:

    @bigbear said in Accessing the FreePBX UCP:

    @dashrender said in Accessing the FreePBX UCP:

    @bigbear said in Accessing the FreePBX UCP:

    Where a phone has authenticated from a public IP so should the UCP then be accessible.

    Right, this is my understanding as well. But this not exposing UCP to the public. This is the responsive firewall only opening UCP for those IPs that have valid registered extensions.

    And I guess my point to that is what if someone wants to log in from home and change the main menu schedule (this actually happened to me with a couple customers) and they have no phone at home so they cant log in to the admin interface.

    Who would be doing that? That sounds like a situation that involves hourly employees, now you have other issues - i.e. people are working and you're not paying them. I know this doesn't directly give you what you want, but it's a possible side affect of what you're wanting.

    Not sure I follow. The most recent customer that comes to mind would log in from home and change the emergency number routing in Misc destinations to whomever was on call. I think they had about 80 employees.

    As far as UCP goes I get asked about how to access it, or used to. I dont have any FreePBX instances anymore.



  • @dashrender said in Accessing the FreePBX UCP:

    But, if you really want anyone in your company to have UCP access, then just put it in the internet group, and you're golden. Of course, you're now opening it to the world of hackers to attack it.

    So you have to weight the trade offs.

    If the admin and UCP portals had the responsive firewall logging failed web logins it could provide the same level of security as remote/roaming IP phones.

    And forget about using a mobile phone app on your android/iphone. I havent paid attention in a couple months but that was still an issue and a common question on freepbx forums.



  • @bigbear said in Accessing the FreePBX UCP:

    If the admin and UCP portals had the responsive firewall logging failed web logins it could provide the same level of security as remote/roaming IP phones.

    Yeah I suppose. I guess they take a different tack - you'd only want access if you have a phone there with you to control.

    But I can see the point of why you might want access while not having an extension where you are. But this obtainable via DynDNS.



Looks like your connection to MangoLassi was lost, please wait while we try to reconnect.