Consul ports inbound/outbound per client/server

Thank you for this section in documentation: it is very helpful indeed, but I would like to go one step further (be more strict) and see what ports needed only for inbound and what only for outbound, and what both per client/server. Also I would like to have a bit more clear understanding what ports only for client and what only for server.

For server:
8600 (DNS) - inbound only (optional, but not sure if server requires any internal DNS communication)
8500/8501 (HTTP/HTTPS) - inbound/outbound ??? (not sure if servers do any internal communication via HTTP)
8502 (gRPC) - outbound only (optional)
8301/8302 (LAN/WAN Serf) - inbound/outbound
8300 (RPC) - inbound/outbound

For client:
8600 (DNS) - outbound only (optional)
to client via HTTP)
8300 (RPC) - outbound only

As of sidecar proxy 21000 - 21255 is it only for servers or clients too? Inbound/Outbound for both?

8502 is it only for servers or clients too?

Documentation says " Server RPC This is used by servers to handle incoming requests from other agents." does it mean it only server to server communication, or client as-well? Could some one explain or point to explanation on what is this port for in a bit more details.

Thank you.

The architecture docs have a really nice picture of what is required just for Consul to cluster and operate itself.

In our docs we sometimes refer to agents, clients or servers. Both clients and servers are generically speaking agents, just specialized cases.

All agents must be able to make outbound connections to the Serf LAN port of other agents within its datacenter as well as receiving inbound connections on their own Serf LAN port.

Servers in all datacenters need to be able to make outbound connections to the Serf WAN port of the servers in all datacenters as well as receiving inbound connections from all other servers on their own Serf WAN port.

Servers run RPC servers and bind to the RPC/Server RPC port. They also forward RPC requests to other servers and use other servers for Raft replication over this same RPC port. Therefore servers must have the RPC port open for both inbound and outbound communication. This is the main form of agent to agent communication for non-gossip related things. Maintaining Raft happens over this port in addition to providing a generic RPC API. If using the HTTP API, internally all the HTTP requests get mapped to their equivalent RPC request and sent to the servers. Basically this port is used for many, many things.

Clients do not have an RPC server running but they do make RPC requests to the servers within their datacenter. Therefore they need the RPC port open for outbound communication.

DNS is provided as a service to the user and is not used internally. If you are not utilizing Consul’s DNS server then you can disable it in the configuration.

HTTP/HTTPs and gRPC are a bit special. The gRPC port is disabled by default and is only needed when you are going to use Connect with an Envoy proxy for exposing an API that Envoy can get its proxy configuration from. This is Envoy connecting to the Agent (client or server) that is managing the sidecar proxies service registration. Consul never initiates outbound connections to a gRPC port.

HTTP/HTTPs will be used for watches configured by the agent although this almost always happens over the loopback interface. Additionally if you are using the builtin Connect proxy instead of Envoy it will also require the HTTP/HTTPs interface. Again its likely that this communication happens over the loopback although its possible to configure it otherwise.

If you are not using Connect or watches on an agent then Consul itself will not require either the HTTP(s) or gRPC ports to be open at all. If you are using Connect with Envoy proxies and not utilizing watches, then the HTTP(s) port will not be used. If you are not using Envoy then the gRPC port will not be used.

The sidecar proxy port range of 21000 - 21255 is used to assign a port to a sidecar proxy registration when no specific port is specified in the service registration. If you are not using Connect then none of these are needed. If you are using connect, that port range only needs to be allowed inbound to the sidecar proxy instance (which usually resides alongside a single agent but it is possible for it to reside on a completely separate node all together).

I think I hit all your questions but really that link I posted at the very top to our architecture docs could show you most of this information with just a picture.


Thank you very much @mkeeler, the answer deserves to be put into Learn section! You answered all my questions indeed.