Duo Network Gateway & Confluence



We’ve been rather aggressive in our adoption of BeyondCorp,with the help of Duo and their epic Network Gateway, and for the most part, it all just works as you’d expect. However, Confluence is being a bit weird and I’ve a sneaky feeling it has to do with too many moving parts and DNG and hoping someone else here has solved this, or possibly knows how.

The setup:

  • Duo Network Gateway (DNG)
  • Microsoft ADFS
  • Duo Mobile
  • Ubuntu box running Atlassian Confluence 6.2
  • Apache24 with modproxy

For most things, it works. User visits https://conf.whee.com and they get redirected to our ADFS, where they use their corp domain creds, then have to deal with duo mfa for the final step. If all is good, their device is healthy and in a set geographic location, they are presented with the login page for Confluence.

Once auth’d, they can do most things confluence, except some bits like removing spaces and pages. Here is where I think the numerous proxies are actually causing issues. When you try and do any of those commands, you get a spinning wheel of death and a 403 - - [17/Jan/2018:16:15:05 +0000] “POST /rest/webResources/1.0/resources HTTP/1.1” 403 3712 “https://conf.whee.com/display/chicken/This+should+work” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0”

for everything else, it functions as i’d expect it to. So usual fault finding approach has seen me:

1: ensure the traffic is being proxied as it should do. In this case, yes as i can create content and do what one does when using confluence.
2: are the required ports listening? yes, all is there and redirected where needed.

tcp 0 0* LISTEN 9085/sshd
tcp 0 0* LISTEN 1565/postgres
tcp 0 0* LISTEN 28265/master
tcp 0 0* LISTEN 1380/mysqld
tcp6 0 0 :::22 :::* LISTEN 9085/sshd
tcp6 0 0 ::1:25 :::* LISTEN 28265/master
tcp6 0 0 :::8090 :::* LISTEN 108254/java
tcp6 0 0 :::8091 :::* LISTEN 108586/java
tcp6 0 0 :::8443 :::* LISTEN 108254/java
tcp6 0 0 :::443 :::* LISTEN 36262/apache2
tcp6 0 0 :::* LISTEN 108254/java
tcp6 0 0 :::80 :::* LISTEN 36262/apache2

So is the REST issue being hit by DNG not forwarding right from the browser, or is it something closer to the source? Has anyone else deployed Confluence this way?

I’ve hit a brick wall here, so any help in putting me out of my misery would be so amazing right now.



Can you clarify a bit about your setup? I’m a bit unclear on where apache is fitting into the mix. Is this between the DNG and Confluence? Something like described on this page: https://confluence.atlassian.com/doc/using-apache-with-mod_proxy-173669.html ?

The log line you show is from Apache, I presume? Or is it from Confluence?

I’m assuming your DNS is configured to point conf.whee.com to the DNG’s IP, but the DNG is either configured with a different (internal) DNS that resolves conf.whee.com to the actual confluence server (or apache proxy) or it’s using an IP address as the internal address? And the confluence server is configured to have its hostname be conf.whee.com?

It seems like that 403 must be coming from Confluence (rather than the DNG), and would suggest that something is getting screwed up with confluence’s authentication.

Is the client, or the DNG’s internal address? I’m curious about where the POST is actually coming from. You’re not integrating with Jira here, are you? Because that can require a number of configuration tweaks to get confluence and jira to be able to talk to each other through the DNG.

We actually use a confluence server behind the DNG, however, we use an earlier version than you (5.7 IIRC).

I wonder if it would be possible to configure the DNG to skip the apache proxy as a diagnostic. I don’t see why it would cause a problem, but it would be helpful to know.

It looks like you’re using Firefox. Have you tried this with Chrome. Shouldn’t make a difference, but just for diagnostic purposes?

Could you provide the following fields from the DNG application configuration page? External URL, Internal URL, Internal SSL validation name.