Firewall issues

Hiya all,

My application activates licenses through Tim Parnell’s excellent TPLM solution.
This requires my customers, who are frequently in very locked down networks, to whitelist the activation servers URL.
I’ve run into a few cases now where they can hit via web browser, but not from the app (403 error).
Today a customer says that my application cannot reach the activation server until they open a web browser and first go to the URL manually.

I know far too little about firewalls and content filters. Can anyone suggest likely areas to look? It’s on their IT to allow it, obviously, but I’d like to speed them along if I can send them some hints.

Thanks in advance for any suggestions.

What in the who how why? That’s crazy. TPLM activation uses URLConnection to https:// on the standard port of 443.

My only guess would be some kind of overbearing filter that’s not configured to understand the new gTLDs like If that’s the case though, it’s a them problem and I’m not really sure what we can do about it.

We can try switching your domain to a .com to see if that works? Send me an email, and if you’re comfortable with it CC the customer in so we can try to work out what’s going on.

Edit: TPLM also supports offline activation, but I think for your requirements we still need to hit the online server. We can work out these details privately in email, I just wanted to publicly state that TPLM does support offline activation for those checking out TPLM.

And URL connection will use the systems proxy settings so that shouldn’t be the issue, though I’ve not double checked and tested that.

It could be a group policy that is restricting internet access to certain apps, like their recommended browser, this is easily done in a corporate environment.

The only ways around this will be a downloadable licence or a local redirect to a listening web server built into the app after signing in on the web but that might cause different alarms on the network if there’s a listener on a high port but many many apps do it so it might not be that big of an issue.

That one will probably be because the site isn’t that well “known” much akin to a desktop app showing the “are you sure” message when you try to run it. It might also be that their policies lower the score on ssl’s that are based on lets encrypt but I doubt it as its becoming so widely used. I’ve always recommended that ssl’s be bought for 10 years and that vastly improves any scoring that is done out there.

1 Like

Just for the public knowledge (and for anyone investigating if TPLM is a solution for them), TPLM as a service does not use Let’s Encrypt certificates. Due to a hiccup with the recent root expiry the best solution for one of my customers was a purchased SSL certificate.

I will continue to use a purchased certificate with TPLM for the foreseeable future. If you are checking out the TPLM service and have any questions please reach out!

Oh, I’m sure it’s a “them” problem, but I need to encourage a solution.
They seem to have recognized it’s their issue now and have taken a new line of investigation.

It’s just been very confusing for me.
And, fyi, I think it’s happening with Lime on a separate product too.

Well at least that makes me feel better :innocent:

And in support of TPLM, I’m sure it’s an overbearing security implementation not TPLM, which has been flawless for over a year now.

1 Like

Ah yes sorry, I see it uses a GlobalSign cert which is different to your main website :slight_smile: that removes that non-“issue”, nice

1 Like

As a network type I have to smirk a little when developers describe network border security as ‘overbearing.’ A few late nights clearing up after a compromise, with the boss asking how long will it take every 3 minutes (quicker if you stop asking), only to find the whole thing was triggered by some middle-manager trying to download the latest movie for their kids, tends to change one’s view of ease of use. (True story. More than once. Grey hairs to prove it.)

Anyhow. 403 is client forbidden. The fact the request succeeds after visiting the resource with a browser points away from DNS or URL filtering and towards proxy or firewall authorisation. The Use System Proxy setting redirects the request to the proxy but the application still needs to play nicely, which may entail authenticating before being allowed through.

  1. Verify if there is a proxy and what kind.
  2. Capture the headers that are being sent from the web browser and compare to those being sent to your TPLM application.

Overbearing was probably an overstatement. You are right.

I didn’t say all network border security is overbearing. I do believe a rule becomes overbearing when it’s interrupting your work even though the domain has already been whitelisted.

I said it was overbearing :slight_smile:

Yes. That’s why I smirk a little. I wouldn’t be prepared to make that judgement without seeing the risk assessment.

Whitelisting permits a destination. Authorisation permits people and applications. These are different layers of granularity working at different layers of the network. Whether there is a need for such granularity is where the risk assessment comes in.