Clients behind firewall and proxy

Hi!

I am running an Icinga2 master in our datacenter and attached about 500 clients that connect from the customers premises to our location (IP <-> IP).

  1. While this works well, I would like to have maximum compatibility to customer networks by setting up nginx proxy_pass in front of the master node (which later will be seperated via satellites) as well as using port 443 instead of 5665. Does this work? Is this supported?

  2. Another problem are HTTP proxys. Even with WinHTTP (netsh proxy) in 32/64 bit and IE, Icinga2 is unable to use a proxy. Somewhere I read that proxys are not supported. This is a problem for my setup because of locations, that don’t allow routing / SNAT but provide a proxy instead.
    (Installation of Icinga2 satellite is not on option there either.)
    Is it possible to tunnel icinga2 connection through a HTTP proxy just like many applications do?

Comments are welcome!
Thank you.

I’m afraid you misunderstood our documentation, Icinga 2 does not use HTTP(s) for communication.

It is also used for the Icinga 2 REST API which shares the same host and port with the Icinga 2 Cluster protocol.

The internal cluster protocol is based on our own JSON-RPC protocol, secured by TLS.

HTTPs is supported in Icinga 2 to access the API, and it uses the same port.

An HTTP Proxy will not work for neither inbound or outbound communication between two Icinga 2 components.

2 Likes

Thank you very much!
Is it possible to proxy the cluster protocol using CONNECT?

For example: I can proxy SSH through a HTTP proxy if I enter it’s connection details in the corresponding tab. It then “tunnels” this protocol through the proxy, even if the proxy would know that it does not contain HTTP data.

We don’t use proxies, if you fiddle with TCP sockets and VPN, maybe.

But we will always recommend direct clean connections.

What is the reason for proxies?

A lot of our customers have separated their network from public internet.
The most common case would be a network with SNAT to the internet, allowing connection tracking to make all kinds of services work.
The networks that I am talking about, don’t route (forward) public addresses. They only allow internal communication directly and force all clients to use a proxy to browse the web. This works perfectly fine with security and backup software, etc. and gives the security teams more control over which connections are allowed (whitelist mode for example).
We got a lot of such customer networks. It would not be possible for the clients (endpoints) to connect directly to our satellites, they must traverse the proxy.

Hi,

you can chose which side opens the connections - either the satellite connects to the client, or the client periodically attempts to connect to the parent satellite.

Once such connection is established, it doesn’t matter which side starts sending messages (check results, check time updates, etc.).

I’m not sure if your customer’s DMZ is that isolated that it only allows for http proxies, highly likely other services must be connected. For example, how do you gain access via remote in order to do support?

Cheers,
Michael

Hi!

Currently, all clients connect to the master to traverse NAT and dynamic IPs easily.
This works perfectly fine.

Thats actually the case. The only way out of that LAN, is through the proxy (Squid by the way).

Either by TeamViewer Host which supports a HTTP proxy or OpenVPN (which also is an “internal” network, thus accepted).

Spanning a VPN across these customers would cause problems (in terms of IPv4). While in theory I could just ask to allow SNAT to the masters public IP, this is something that needs a very long time for the customers to decide.

The same applies if we would install a satellite in that network (which also needs management and updates).

The easiest approach would be to tunnel through the proxy (just like Putty/SSH is able to).

Kind regards
Kevin

The best way would be a sane site-to-site VPN solution.

Proxies are not build for log lasting connections and should not be used for it… Experience shows that websockets are a nightmare with most proxy implementations…

1 Like

Sounds like a nightmare to support. If site2site VPN doesn’t work, I would just leave the customer environment in a single standalone instance and don’t attempt to connect it to the outside world.

Cheers,
Michael

Regarding the proxies: I had the similar case, client machine was behind a firewall and only a SOCKS proxy was available to bypass that firewall from inside. Running Icinga daemon wrapped in proxychains (http://proxychains.sourceforge.net/) worked. Proxychains transparently intercepts all tcp communications and forwards them through a socks proxy, so no modifications to Icinga were required.

I will try this, thank you!

I tried that but I don’t get this working.
Using “proxychains telnet example.com 5665” I can connect and Icinga2 logs a TLS error.
If I start “proxychains /usr/sbin/icinga2 daemon” I don’t see any connection on my master node.
I’ve also tried SSH and it works well over proxychains but Icinga2 does not.

Unfortunately that was a long time ago and I do not have access to the same environment anymore, but I vaguely remember that I had to use proxychains-ng because stock proxychains did not work for some reason (I also vaguely remember that the reason looked similar to what you are describing - some programs worked, some - icinga - didn’t).