connect 2 instance via reversed proxy

[Farhaad_n]

I use NGINX Proxy Manager (NPM) as a reverse proxy for two Jira instances hosted on different servers. However, since both domains (jira1.pp.com and jira2.pp.com) are being pointed to the same NPM server, Jira on jira1.pp.com thinks jira2.pp.com is the same instance because the reverse proxy resolves both domains to the same IP (ex. 172.16.4.2).

jira core 9.12.12

jira core 8.12.0

so when I want to add a link in "Apllication link" jira told me this error:
URL must not point to localhost or restricted IPs.

what can I do? am I doing wrong things?

[Darryl Lee · Accepted solution]

Hi @Farhaad_n - I think this is what you are running into:

Application Link configuration from Jira to Confluence fails with URL must not point to localhost or restricted IPs 

Quoting from there:

Cause
With AppLink 9.1.x there is a restriction when trying to configure the Application Link between Confluence and Jira hosted on the same machine. Application Link version history corresponding to Confluence and Jira can be here - AppLinks versions by product

Solution
To create the Application Link between Confluence and Jira hosted on the same machine, the workaround is to add the following JVM argument in both the Applications(Jira and Confluence)

-Dapplinks.allow.all.hosts=true

Refer to Setting properties and options on startup for more details on how to update the above values in the startup option, Steps are outlined below for quick reference

Please let us know if that resolves the issue!

[Farhaad_n]

I had seen this before but didn’t do it; now I did it and some network changes and it worked.
But why should this happen? Why shouldn't it recognize that it's installed on two servers?
Can't this be fixed with a header in nginx?

[Darryl Lee]

Hi @Farhaad_n  - yeah, I would've thought NGINX would properly handle multiple hostnames via the headers, (well, since HTTP 1.1), but I found a comment from Atlassian's @Jeffery Xie here:

• CONFSERVER-90912 - Failed to create Application Link between Crowd & Confluence 7.19.11 

The behaviour described in this issue is as intended as we've restricted to create application links for localhost by default for security consideration. If you do want to create application links for localhost, you can add applinks.allow.all.hosts and set as true in confluence-install-path/bin/setenv.sh and then restart server.

A subsequent commenter, @Tim Eddelbüttel questioned this:

I hope you're internally also that customers are paying for DC licenses a lot environments still run with a single-node and sometimes as well on the same host (useful or not is a different discussion). There are also local test, development or migrations environments.

I would be highly interested in the given security / attack vector that resulted in this request.

I guess under the covers it's doing a DNS lookup and blocks if the application link is the same IP address (which it considers restricted) or a localhost address.

Ah, ok, I found this documentation on the applinks.allow.all.hosts property where it says:

This property blocks local IPs and network link IPs (including AWS magic IP) during new app link creation. This helps prevent SSRF attacks on the local server.

If you don't need to block local IPs and network link IPs, then set the property to true and restart Confluence.

So ok, I guess it would consider the SAME IP address as "local"? And yeah, obviously localhost or 127.0.0.1.

I am still wondering what Atlassian means by "network link IPs". IPs in the same subnet? I suppose I could go digging in the source code. :-P

Footnotes

I had to re-acquaint myself with what an SSRF attack is:

• Server-side request forgery (SSRF) 

[Farhaad_n]

what can I do?

anyone?