ASA 5510 clientless VPN content rewriter brakes Jira and Confluence

[Nicola Volpini]

Hello,

we configured our ASA 5510 to serve intranet contents via the clientless VPN feature.

We're trying to give our users the possibility to access our ticketing system, Atlassian Jira, and our corporate wiki, Atlassian Confluence.

With Confluence everything appears to be working fine but when editing/creating a new page the rich content editor is not usable. The editor's buttons are there but it's impossible to interact with it (the main text window is not clickable)

Jira is instead completely unusable: the login form appears to be loaded in an Iframe through some script, but the iframe source is pointing at the untranslated url.

I tried to look at the source code of the generated page and indeed there are parts of it with untranslated URLs. I'm pasting some bits of the code with my company url obfuscated:

<fieldset >
...CUT...
 <input type="hidden" title="baseURL" value="https://jira.<mycompany>.com:443" >

...CUT...

<script type="text/javascript" charset="utf-8" >
        AG.DashboardManager.setup({
            params: {
                "pipeDelimitedHelp" : "(pipe-delimited)",
                "editLayout" : "Choose dashboard layout",
                "move" : "move",
                "layoutAction" : "https:\/\/jira.<mycompany>.com\/rest\/dashboards\/1.0\/10000\/layout",
                "staticResourceUrlPrefix" : "$js.escape($staticResourceUrlPrefix)",
                "blankSearchText" : "Search",

...CUT...


"maxGadgets" : "20",
                "dashboardUrl" : "https:\/\/jira.<mycompany>.com\/rest\/dashboards\/1.0\/10000",
                "dashboardDirectoryResourceUrl" : "https:\/\/jira.<mycompany>.com\/rest\/config\/1.0\/directory",
                "dashboardSubscribedGadgetFeedsUrl" : "https:\/\/jira.<mycompany>.com\/rest\/config\/1.0\/directory\/subscribed-gadget-feeds",
                "dashboardResourceUrl" : "https:\/\/jira.<mycompany>.com\/rest\/dashboards\/1.0\/10000",
                "dashboardDirectoryUrl" : "https:\/\/jira.<mycompany>.com\/rest\/dashboards\/1.0\/\/directory\/10000",
                "dashboardDirectoryBaseUrl" : "https:\/\/jira.<mycompany>.com\/",
                "dashboardDiagnosticsUrl" : "\/plugins\/servlet\/gadgets\/dashboard-diagnostics",

...CUT...

</script>

It seems like the content rewriter skipped the javascript part alltogether.

I'm using an ASA 5510 with ASA version 8.4(2).

Any hint?
Thanks!

[Nicola Volpini]

Hi Tom,

thank you for the update, much appreciated.

[tom.harwell]

Cisco created a bug for this issue (http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCue84586). Was informed today that version 8.4.6ED has been released and contains the bug fix.

I plan to upgrade my ASA this weekend and will post the result.

[Nicola Volpini]

Thanks, much appreciated
I'll keep an eye on the thread!

[tom.harwell]

Finally upgraded to 8.4.6 and JIRA seems to work. I've asked our development folks to test it thoroughly, but at least the login page rendered properly.

[Nicola Volpini]

Thanks Tom, that's indeed great to know! I'll plan an upgrade asap then!

Thanks again for the feedback

[Kevin.ortloff]

Ok everyone. In case you're still working on this. Here's the fix

We’ve been playing around with this for some time and I found; doing multiple packet captures that the problem is not really within cisco webvpn, but the method in which Atlassian performs it's import data functions to either a file upload process or the widget gets. I believe in order to speed up the process, it calls for multiple browser sessions to import this data into the iFrames. Obviously on a LAN this is no problem and most likely does speed things up. On the clientless webvpn, it's a no-go as the sessions are in fact different and the local host tries to hit the 'internet' for your internal server’s hostname. So ASA-845 I noticed there is a new smart tunnel for networks (maybe this was in other very recent versions but I don't know or care). So my first thought to get this at least running was to add the inside network hostname to this list…nothing different happened. Then I opened up the bookmarks for this particular entry and enabled smart tunnel. Walla. It indeed invoked the newly created smart tunnel network and all traffic was pumped through the clientless webvpn. However slower than before, it did fix the problem.

Now as locked down as I have my people (same as a few remarks above), I would consider this a small risk for ONLY this system. I made sure that smart tunnel is only available for this destination and only applied it to the appropriate groups.

In short, you need to do both from my research and testing. One without the other fails. This is a workaround to the careless programming of Atlassian (although I’ll mention again, I’m sure they constructed this latest code to speed up their otherwise sluggish application). However my assumptions are over half of the VPN world is on cisco webvpn/anyconnect and they should have performed much more thorough tests before releasing these latest versions.

Good luck and if you have questions, I’ll come back once in a while and see if anything new or better developed.

[Nicola Volpini]

Thanks for the feedback Kevin.

From what I understand the smart tunnel feature requires some code to be run client side. Correct? That would prevent a public workstation from being used with smart tunnels. Again: if my understanding is correct.

[Gustavo Medina]

Hello,

I worked with Tom on this case and filed CSCue84586 for this issue.

The main problem here was that an iframe's window containing XML document was not treated as window.

8.4.6 does contain the fix for this.

-Gustavo

[serialmonkey]

Hi everyone

What version of JIRA have you been testing with ? I've upgraded to 8.4.6 but we are running the latest JIRA 6.0 and still cannot get this to work through the WebVPN.

Again, as above, Smart Tunnel is not an option for us.

Any ideas ? Raise a TAC ?

Regards,

Mark.

[Nicola Volpini]

Hi, I just upgraded our ASA to version 8.4.6. I can confirm that Jira is now working properly, and so is Confluence.

@Mark Wallis: Our Jira version is v5.1.2.