reverse proxy connection failure

[zabbal]

I've got kibana (+elasticsearch) deployed on a server and I'm trying to expose it public network in a secure way using squid as authenticating reverse proxy with TLS (due to #1559). The idea is to let squid terminate ssl and connect to kibana running on 127.0.0.1

Here is my squid.conf (192.168.2.12 - is 'public' ip address, 'myserver.com' is my server name):

auth_param digest realm Restricted
auth_param digest program /usr/lib/squid3/digest_file_auth -c /etc/squid3/passwd
https_port 192.168.2.12:443 cert=/etc/ssl/myserver.com-cert.pem key=/etc/ssl/myserver.com-key.pem accel options=NO_SSLv2,NO_SSLv3,NO_TLSv1 protocol=http no-vhost defaultsite=myserver.com
cache_peer 127.0.0.1 parent 5601 0 no-query originserver name=kibana
acl target proxy_auth REQUIRED
http_access allow target
cache_peer_access kibana allow target
cache_peer_access kibana deny all

---

Here is the error I receive:

Fatal Error
Unable to connect to Elasticsearch at "http://myserver:80/elasticsearch"
Error: No Living connections
at sendReqWithConnection (https://myserver.com/index.js?_b=3439:77800:15)
at next (https://myserver.com/index.js?_b=3439:76382:7)
at https://myserver.com/index.js?_b=3439:49533:21

---

kibana4 listening on 5601 (all ip addresses), elastic is up and running, squid itself is fine (login/password requested, TLS is there with proper certificate etc). When I'm connecting to 5601 directly everything works fine, but when I'm connecting through squid reverse proxy I got this error. Note: the error is exactly the same even if I disable digest authentication in squid. Seems like some strange hardcoding somewhere.

Why does it try to use http instead of https? Is there some special rewrite rule required? Does anyone have working config for squid to use with kibana4?

[rashidkpc]

There's no version information included here? This should be fixed in master: #1680

[zabbal]

I think I'm using 4.0.0-beta1.1 - what's the recommended way to check version without starting kibana (it takes forever)?
Is the fix part of some beta release or I've got to make checkout and build master?

[rashidkpc]

The fix is part of master, you would need to build from master until the next release. You will need to start the app to check your version. Closing since this is fixed in master.

[zabbal]

Is there instructions on how to actually build it? All I've found in readme is "coming soon..."

[rashidkpc]

https://github.com/elasticsearch/kibana/blob/master/CONTRIBUTING.md

[zabbal]

Ok, tested build 157 (commit 0521d16) and the error is still there.
Is there some specific configuration required? Which commit/build fixed it?

[nasdbfhkja]

Hi

I applied the patch in commit 0962ebf by unpacking the JAR, patching index.js, and re-packing the JAR file.

I can confirm what previous poster says, it still doesn't work.

It looks like Kibana is fetching a JSON config file named "/config", and in this config file there is also a reference to the backend system which includes the wrong scheme, port and hostname.

(I run a reverse proxy in front of Kibana as well, for security reasons. Think password authentication, HTML5 priv/pub key authentication, SSO, portalization, that sort of thing, Kibana sits on the internal network via HTTP and doesn't have to care about all the work that the reverse proxy knows how to do.)

Is there any good reason why commit 0962ebf doesn't just follow the HTTP / HTML standard and use relative URLs, eg. to find elasticsearch --> use the relative path "/elasticsearch/" ??

The new HTTP RFCs have even been fixed so now you can officially use relative URLs everywhere, including in 302 redirects (all browsers supported it before, but it was officially banned for some reason). I can't see a good reason not to use relative URLs everywhere in a single app, but maybe it's just me.

[zabbal]

Since the issue has been confirmed - shall I make a new one or wait until this one is reopened?