Set Up Access to 20.3 Operator Console and CABI using a DMZ for external access

[Brendan Mitchell]

Currently we have UIM & UMP 8.51 on the inside and use Apache with AJP on a DMZ server to allow external users access to UMP incl our custom dashboards. Now with the upgrade to 20.3 UMP gets replaced with OC. The new OC supports Apache AJP access so that is great. BUT ....

We now need to install a seperate CABI server to host the CABI dashboards. I see on my browser when I use the OC alarms or inventory then behind the scenes the browser is opening a TCP connection direct to the CABI server. So that means the CABI server cannot sit on the inside since external users will not be able to access it. So how will that work in my situation. Do I install a robot on my DMZ serever and install the CABI server with ports open to the inside UIM hub, and port 80 open to the external users? The problem is futher complicated in that my DMZ server has muliple NICs and the CABI WASP will no doubt bound itsself to the NIC facing into the HUB, whilst I probably need it to be bound to the NIC facing the external users. Any ideas? Has anyone got this working in 20.3? I could not find anything documentation about how to setup and access CABI from the DMZ

[jjanderson]

Currently looking into this myself
so far we can access the OC on our company URL but certain views just sit with a spinning icon.. you can however get to these no problem using the internal IP.
we are using a Linux Proxy Server to split the data between the UMP and the OC / CABI server until we get 20.3 installed and Flash is gone.
currently have a ticket with  Broadcom for help but so far i'm still trawling the internet for help

[Andrew Cooper]

We have a front-end load-balancer basically to manage access. Which does what you want so here goes.
First you need

• 2 DNS names (oc.lan and cabi.lan) which point to the LB front-end address (we looked at using same address but different ports but it got too messy/hard)
• all protocols have to be the same ie Browser -> LB = https then LB -> OC and LB -> CABI have to be https (you cannot do ssl off-load on the LB (which we wanted to do) though only the Browser -> LB needs to be a registered cert
• either both internal and external traffic goes through the LB or you have to use a split DNS, as the DNS names need to be the same for all users

Now you have sorted out the pre-requisites, the configuration

• the LB needs to send oc.lan to the oc pool (can be 1 server) and cabi.lan to the cabi pool (again can be 1 server)
  No rewrite is required (effectively a pass through)
• On the OC no special config needs to be done
• On the CABI server in the cabi probe need to define the setup/cabi_url key to contain the full name from the browser perspective (eg https://cabi.lan/cabijs).  this is the url that will be inserted into the pages so that the connection will be opened via the LB rather than directly to the CABI server.  If this key is not defined then the url used is a mess of the browser protocol and the cabi server address or even ip (yuck)
• We also define in the CABI server and OC server wasp setup/cabi key to point to the full path of the cabi probe (eg /<domain>/<hub>/<robot>/cabi

Restart everything and good luck, we had a lot of "fun" getting it to work but it has worked fine through 9.2, 20.1 and now 20.3

Regards, Andrew

Nginx, haproxy and BIGIP all worked fine with this configuration, the biggest issue was getting all the users to go through the LB and getting the DNS address resolution correct.
​

------------------------------
Knows a little about UIM/DXim, AE, Automic
------------------------------

[Brendan Mitchell]

Thanks Andrew for those pointers. Just upgraded our customer today from 8.51->9.02->20.3.0 
Only other thing we had to do was those 3 special Chrome flags for 3rd party cookies