Unable to call http://100.64.x.x/api/system/*

Hello Guys!

I have a problem with my graylog setup. I’ve done a few before with no issues, but this one is a little bit different.

I am deploying graylog for a customer, we have an IPsec VPN to reach their servers, and we want to reach graylog web interface via an IPsec IP: 100.64.x.x:9000, NAT is working okay.

So the problem is, if I configure like this:

rest_listen_uri =
rest_transport_uri = http://100.64.x.x:9000/api/
web_listen_uri =

I can reach the web interface, but when I try to start an input or if I try to get to some of the things in the web interface:

WARN  [ProxiedResource] Unable to call http://100.64.x.x:9000/api/system/metrics/multiple
WARN  [ProxiedResource] Unable to call http://100.64.x.x:9000/api/system/jobs
WARN  [ProxiedResource] Unable to call http://100.64.x.x:9000/api/system/inputstates

It looks like the graylog server tries to reach itself via the ipsec ip, not the local.

Of course if I uncomment rest_transport_uri , I can’t reach the web interface via the 100.64.x.x IP, I tried a bunch of configurations, like:

rest_listen_uri =
# rest_transport_uri = http://100.64.x.x:9000/api/
web_listen_uri =
web_endpoint_uri = http://100.64.x.x:9000/

I reach the web interface, but with these settings I can’t login, as I get “404 - cannot POST” errors.

Do you have any advice what should I do differently? Use different ports for the api and the web interface?

Thanks in advance!

  • You did not clear out all IP details in your log example; two entries without “x.x”.
  • I don’t know whether putting as the listen IP for the interface and API will work. Would need to look at the docs for that.
  • One option I would consider, is configuring Graylog with the internal IPs completely, so it will work by itself inside the customer’s network. If you’re going to use Sidecar collector’s they’ll also need to connect to the REST API. You could access the web interface through a jumphost or use a port forward to reach it from elsewhere.

Then again, I haven’t had much coffee yet this morning. I may not be grasping the full picture here :slight_smile:

Check the full graylog config.

# When using Graylog Collectors, this URI will be used to receive heartbeat messages and must be accessible for all collectors.
rest_listen_uri = http://100.X.X.X:9000/api/

# REST API transport address. Defaults to the value of rest_listen_uri. Exception: If rest_listen_uri
# is set to a wildcard IP address ( the first non-loopback IPv4 system address is used.
# If set, this will be promoted in the cluster discovery APIs, so other nodes may try to connect on
# this address and it is used to generate URLs addressing entities in the REST API. (see rest_listen_uri)
# You will need to define this, if your Graylog server is running behind a HTTP proxy that is rewriting
# the scheme, host name or URI.
# This must not contain a wildcard address (
rest_transport_uri = http://100.X.X.X:9000/api/```

You should use the api via VPN if you use graylog sidecar, at other situation you need only the web_listen_uri to be accessable.

Thanks for the input!

In the meanwhile I found out via another thread with the “same” problem that the rest_transport_uri needs to be accessible by the browser and the graylog server aswell, and of course the server couldn’t reach its local ipsec address.

So I got a DNS entry in our DNS servers(same as the local fqdn in my customers environment) that points to the ipsec IP and added the FQDN to the rest_transport_uri, and now everything works like a charm.

If you’re going to use TLS, be sure to add that new hostname (both short and fqdn) to the SAN-list of the certificate :wink:

another workaround, use a haproxy or nginx to redirect to x.x.x.x:9000 :slight_smile: in this case you can listen on every ip. with iptables you can redirect the VPN ip to local subnet.
Or just use only iptables.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.