License Manager Through Reverse Proxy

460
8
Jump to solution
02-21-2024 12:15 PM
Labels (1)
CodyPatterson
Occasional Contributor III

Hey All,

Enterprise 11.2, License Manager 2023

I was curious if anyone has experience connecting to their license manager through a reverse proxy? We have a public site that our employees can connect to the portal URL through, we were hoping that they would be able to use the portal URL through the public portal and connect, but I'm getting this message here:

CodyPatterson_0-1708546489068.png

 

Our license manager is up and running, I'm able to connect on the network, but not over the public address.

Any thoughts to this?

Thanks in advance!

0 Kudos
1 Solution

Accepted Solutions
CodyPatterson
Occasional Contributor III

Hey @Scott_Tansley @BillFox 

Update to both of you since it may help in the future.

I spoke with our network administrator, and I mentioned checking the certificate on SSLLabs, we did so and found that it had been revoked. Thankfully he had the ability to reissue the certificate, so we uploaded a new CSR and got it reissued, and boom, everything started coming through as normal. We're able to access the License Manager both on and off network. What gave me the hint was that Field Maps stated the certificate was untrusted, even though there was no warning when navigating.

Very relieved to find this and be done with it!

Thank you both for your help!

Cody

View solution in original post

0 Kudos
8 Replies
Scott_Tansley
MVP Regular Contributor

The portal part of the license manager is on HTTP/443 via the Reverse Proxy.  But then it forwards the requests to the FlexLM license manager on a port that is not HTTP.

For this reason, and to avoid complexity/opening up firewalls, I typically recommend clients to get their licenses from ArcGIS Online.  If an organisation is 'secure' and can't use AGOL for licensing, then it typically suggests that the firewall issue won't be a problem and the FlexLM port will only be needed internally.

Scott Tansley
https://www.linkedin.com/in/scotttansley/
0 Kudos
CodyPatterson
Occasional Contributor III

Hey @Scott_Tansley 

Thank you for the response, I was curious if it may have been the port that it is working through, I was under the assumption that once made through 7443, it would then work through 27000 or similar to get to the license manager right off the portal. I'll allow 27000 through just to see what happens.

I agree that it would be complex and insecure to open up the firewall to any further ports, but we'd like to attempt and move away from AGOL licenses for the most part, but if that's the move, then we'll go that way!

I'll check back in once testing done, thank you again!

Cody

Scott_Tansley
MVP Regular Contributor

Check out Bill's comment below.  I believe you'd need 27000 and 5152 on your external firewall based on that.

Sorry, I should have thought to share that.  In NZ we tend to use AGOL because of Civil Defence risks and the fact that AGE may not be available.  Most of our data centres are in EQ or Volcano areas!  😕  I sometimes forget the rest of the world may not think like that.  

Scott Tansley
https://www.linkedin.com/in/scotttansley/
0 Kudos
Scott_Tansley
MVP Regular Contributor

Just one other thought on all of this.  A lot of the environments that I get to interact with have different zones.  By which I mean, the internet comes in on 443 (and your new ports).  This routes to the web server.  That then routes through an inner firewall to the application server on 7443. 

If you're zoned like this, then remember that your inner firewall ports will need to be opened as well, and you'll be effectively routing from the internet to your application zone.  There may be better ways of dealing with this, but it will come down to what's in your IT kit bag to allow it....

Reflecting on the client where we tried to make this work, it was the opening of the inner firewall that made their security advisor through his teddies out the pram, and it never got done...  

 

Scott Tansley
https://www.linkedin.com/in/scotttansley/
CodyPatterson
Occasional Contributor III

Hey @Scott_Tansley 

No worries at all, we're currently discussing this with our network administrators to find a plan for action regarding this. It may be a situation of just using ArcPro offline while users are out of office, which was sadly against what we wanted initially, but if that's just how it goes then not much I can do.

I'll update with the results!

Cody

CodyPatterson
Occasional Contributor III

Hey @Scott_Tansley @BillFox 

Update to both of you since it may help in the future.

I spoke with our network administrator, and I mentioned checking the certificate on SSLLabs, we did so and found that it had been revoked. Thankfully he had the ability to reissue the certificate, so we uploaded a new CSR and got it reissued, and boom, everything started coming through as normal. We're able to access the License Manager both on and off network. What gave me the hint was that Field Maps stated the certificate was untrusted, even though there was no warning when navigating.

Very relieved to find this and be done with it!

Thank you both for your help!

Cody

0 Kudos
BillFox
MVP Frequent Contributor
CodyPatterson
Occasional Contributor III

Hey @BillFox 

We did end up doing this, just set it to an ambiguous port, maybe I should attempt to clear it with the reverse proxy!

I'll give that a shot and let you know, thank you for the resource!

Cody

Edit:

Looks like it has already been enabled through the reverse proxy sadly, so now back to step 1.

0 Kudos