Problem: JIRA cannot communicate with the Bamboo server (application link is configured using internal IP and port; display address is shows externally facing URL) and Bamboo cannot resolve the JIRA ticket information (same application and URL configuration). Note: Applications work and are authenticated. Note: Bamboo in JIRA plug-in does not currently work since it cannot contact the Bamboo server with the display URL.
End State: JIRA and Bamboo users outside the firewall are able to see the JIRA information in Bamboo and the Bamboo information in JIRA.
JIRA is on its own system on an internal IP on the default port with the URL context of jira
Bamboo is on its own system on an internal IP on the default port with the URL context of bamboo
External users ( there are no internal users) access the JIRA and Bamboo through a reverse proxy via an externally facing URL. IE: http://www.example.com/jira
JIRA and Bamboo are currently configured using the internal IP’s and ports in the application links. IE: http://xxx.xxx.xxx.xxx:8080/jira
I want the JIRA and Bamboo transactions to occur within the boundary of the firewall and not exit the DMZ to access the external (display URLS)
I want the users to be able tro see the JIRA information in Bamboo and vice versa.
I have gone through a number of the articles and have seen numerous references to this configuration but not a definitive answer.
I was able to solve the problem in the following manner.
Using the existing reverse proxy that is configured to proxy our externally facing URL’s to the internal servers; I was able to do the same from inside the firewall. I was able to ensure that the intra-server traffic remained within the firewall.
Note: I am not running an internal DNS.
I set the external URL in the local host file of the Bamboo, JIRA, Stash, and Confluence servers to point to the proxy server. IE www.example.com to 192.168.2.2 (proxy server). After verifying that the externally facing URLs correctly resolved in the web browser of each application I then deleted and recreated the application links as follows.
For example: Bamboo to JIRA was 192.168.2.12:8080/jira to www.example.com/jira
After recreating the application link using basic authentication and adding the following IPs to the incoming authentication of each application: proxy server (192.168.2.2), source application IP (jira, bambbo, etc of 192.168.2.12), and the externally facing IP of the site (xxx.xxx.xxx.xxx).
Once each application link was recreated for each application pair; I tested each of the applications integration and they all worked as expected.
All of the Atlassian systems are on Linux servers.
Here are some notes that helped me troubleshoot the issues:
Log examination: tail –f <log file name>
Very useful in seeing the errors and then using the Atlassian site to correct the errors
Time – I had one server drift 7 minutes out (despite a ntp cron job) and this caused authentication problems between the applications.
Atlassian documentation, answers, and FAQs were very useful once the specific issue was noted
Thanks much for the detailed summary, very helpful :) - I think it's worth noting that the main topic indeed seems to be a DNS configuration resolving to internal addresses when queried from within your network as James Dumay suggested, insofar you effectively implemented this by means of explicitly providing the internal address resolution in each servers hosts file.
We are running our Atlassian Suite on Amazon EC2, and unfortunately this is not readily available in Amazon Route 53 yet, despite being a feature of Public IP Addresses and External DNS Hostnames in EC2 indeed:
We provide each instance that has a public IP address with an external DNS hostname. We resolve an external DNS hostname to the public IP address of the instance outside the network of the instance, and to the private IP address of the instance from within the network of the instance.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs