Support for binding client interface(s) to multiple addresses

[blalor]

In a containerized (ok, fine: "Docker") environment, I want to expose the consul agent to applications running in containers, but I'm uncomfortable exposing it to the entire world. Unfortunately, those are the only real options unless I want to muck about with iptables (which, trust me, I very much do not). I'd like to be able to specify multiple addresses in the config file as an array ("client_addrs": ["127.0.0.1", "172.42.17.1"]), and that implies multiple -client command-line flags. Related (in my head, anyway) to #421.

[armon]

This is possible but difficult as it requires everywhere that a single listener is used to support N listeners.

[saulshanabrook]

So it is impossible right now to have consul client HTTP API accessible on localhost and on the machines global IP?

[saulshanabrook]

Lemme know if there is an easier way, but I set up consul to bind on localhost (the default) and then used socat to forward incoming traffic to that port.

socat -d -d TCP-L:8500,bind=10.128.1.72,fork TCP:localhost:8500

Where 10.128.1.72 is my IP.

Also had to set advertise_addr in my consul config to that IP as well.

[Esya]

+1 for this feature, same usecase and we'd like to avoid using socat or iptables on top of consul just to redirect the traffic

[smreichling]

Adding my vote for this feature. This is causing us pain because we want the Consul Web UI to be accessible from other machines (no just localhost) but changing the HTTP bind address requires an extra argument to every command line tool that uses the HTTP API and assumes localhost.

[markeijsermans]

Same situation here. I have Consul and Registrator both in Docker containers with --net=host, and have mixed workloads of native & containerized apps. Another possibility is with this with this less than desirable work around: bind consul to the docker's bridge IP. It removes the need for passing in IP's to the container which might not be straight forward in certain situations.

Inside a container (with --net=bridge) access Consul by contacting it's gateway - ie curl $(ip route | grep default | awk '{print $3}'):8500.

curl Consul's api from the host by getting Docker's bridge (docker0) - ie curl $(ip route | grep docker0 | awk '{print $9}'):8500

[blalor]

I'd also like to see the unix domain socket be supported along with the list of listening addresses.

[IainColledge]

Would be a good option

[tgeens]

@blalor I'm inferring from your original post that you run consul in docker with --net=host.

I think there is a workaround if you use --net=bridge:

• you can bind consul -client=0.0.0.0 to all interfaces (inside the net-container-space)
• map 8400/8500/8600 to your bridge0 (172.42.17.1) on the host
• map 8300-8302 to your private-network ip on the host

[techwolf359]

I ran across this one today using addresses->http so I can access the Web UI on server1.

"addresses": {
    "http": "10.xx.xx.xx"
}

Local consul rtt fails because:

server1> consul rtt $FQDN
Unable to look up agent info: Get http://127.0.0.1:8500/v1/agent/self: dial tcp 127.0.0.1:8500: getsockopt: connection refused`

Switching http to 0.0.0.0 actually fixed this by binding to all network interfaces, so now I can use 127.0.0.1 and 10.xx.xx.xx to connect to HTTP. This is slightly different than client_addr above, and is different than some users requests where they would like to bind to explicitly 2 IPs, but maybe not all IPs.

This might be worth calling out in the documentation for the addresses section because in the bind section, the use of 0.0.0.0 is different:

By default, this is "0.0.0.0", meaning Consul will use the first available private IPv4 address.

Suggest adding to the addresses section, the use of 0.0.0.0 to bind to all network interfaces. It might even solve @saulshanabrook's issue.

[steve-jansen]

@techwolf359

Believe the behavior of the 0.0.0.0 wildcard in golang's net package is to bind to the first available interface, not all available interfaces. So, I think the docs are correct.

By default, this is "0.0.0.0", meaning Consul will use the first available private IPv4 address.

[techwolf359]

I wonder if that's left to a system call and OS implementation. On CentOS 7, setting client_addr to 0.0.0.0 is binding to all interfaces for me and fixed the above scenario where consul rtt was unable to connect via 127.0.0.1. External requests still work fine. In any event, if docs aren't updated, trying 0.0.0.0 could possibly help out people in the thread.

[hvpareja]

Hi all,

+1 for this feature. It would be very useful in my case. I need Consul servers to be listening in 2 of 3 different interfaces.

[ajvb]

+1 - I have a set of servers on a different subnet, and it would be nice to be able to configure multiple interfaces for them. My use case would also be solved by being able to specify an outbound interface and an inbound interface.

Also, if you have multiple interfaces on a machine and you try to bind to 0.0.0.0, consul throws this error:

==> Error starting agent: Failed to get advertise address: Multiple private IPs found. Please configure one.

[number5]

set client address to 0.0.0.0 on Ubuntu 14.04 will bind to all interfaces include lo and docker's docker0 /172.17.0.1

[cthumuluru]

Is there a way to specify the bind port and client port for the agent similar to http port?

[jnials]

+1 as well. I need to be able to run local for most things, but the UI on the external port.

[zh99998]

+1 for this request

I'm in a hybrid cloud and this feature is essential for me.

[ryansmithevans]

👍 pretty much required

[sean-]

In your confit you can now add an undocumented (yet) flag: {{ GetInterfaceIP "eth0" }} and it should do the right thing. See the sockaddr library for more details and options.

[jcortejoso]

Is this issue still active? I have configured "client_addr": "0.0.0.0" and consul seems to be listening on all interfaces:

[root@intprivate05 ~]# netstat -tlpn | grep consul
tcp        0      0 10.200.0.136:8301       0.0.0.0:*               LISTEN      29797/consul        
tcp        0      0 127.0.0.1:8400          0.0.0.0:*               LISTEN      29797/consul        
tcp6       0      0 :::8500                 :::*                    LISTEN      29797/consul        
tcp6       0      0 :::8600                 :::*                    LISTEN      29797/consul        
[root@intprivate05 ~]# consul version
Consul v0.7.0
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)

[slackpad]

Closing this as a duplicate of #2217, since there's an active PR against that one.