Vault and consul tls configured successful, but they are still reached over ipv4 insecurely

Vault
1

Hi All,

I have successfully configured vault and consul via tls. However i couldn’t find a way to redirect or disable both to be reached over ipv4 insecurely without using nginx or similar tool.
Is there way without nginx or similar tool in front of them to accomplished this task?

vault version - 1.9.1
consul version - 1.10.2

Thank you in advance,

BR,
Mladen

2

You configure both with the listener blocks, and by default TLS is enabled and will complain about missing certs. If you don’t have any listener blocks without tls_disabled = true then no insecure connections can get in.

You can even force higher levels of tls via:

listener "tcp" {
...
  tls_min_version = "tls13"

  proxy_protocol_behavior = "allow_authorized"
  proxy_protocol_authorized_addrs = " .... nginx allowed cidr block...." {ex: 192.168.1.0/24}
}
3

Thank you for the reply Aram.
Unfortunately i can’t agree with " If you don’t have any listener blocks without tls_disabled = true then no insecure connections can get in."
Here it is part of consul and vault configuration.

part of vault config

HTTPS listener

listener “tcp” {
address = “dns:443”
scheme = “https”
tls_disable = “false”
tls_skip_verify = “false”
tls_cert_file = “/opt/vault/tls/dns.chain.pem”
tls_key_file = “/opt/vault/tls/dns-key.pem”
tls_client_ca_file = “/opt/vault/tls/dns-ca.pem”
tls_ca_file = “/opt/vault/tls/dns-ca.pem”
tls_min_version = “tls12”
tls_cipher_suites = “TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA”

part of consul config

enable_agent_tls_for_checks = true
verify_incoming = true
verify_outgoing = true
verify_incoming_rpc = false
disable_remote_exec = false
enable_script_checks = false
verify_server_hostname = true
domain = “dns”
ca_file = “/etc/consul.d/tls/dns-ca.pem”
cert_file = “/etc/consul.d/tls/dns.chain.pem”
key_file = “/etc/consul.d/tls/dns-key.pem”

tls_min_version = “tls12”
tls_cipher_suites = “TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA”

I have tried also to set tls_min_version = “tls13”, but without success. In both cases vault and consul are still reached over ipv4 insecurely.

4

First … Vault talks to Consul agent, then the agent talks to the server. So what is talking to what and how do you know they’re being insecure?

5

I’m not referring to the communication between vault and consul.
So when i try to reach vault or consul via the ipv4 in the browser instead using the fqdn, they are loaded insecurely. For this reason i have asked if there is a way to prevent that, without using additional tools.

6

Okay.

However, again, how do you know that it is an insecure connection? Are you using a browser and the icon is blocked out? Are you using curl and you can use http?

7

Just the browser is noticing that the connection to that domain is insecure, but this is normal thing, when trying to reach a particular url via the ip address, because is not being covered by the certificate, which i want to prevent, if possible without using additional tools.
For example if you have nginx in front of vault and you tried to reach the ip address of it, nginx will not loaded it and will return generic error based on the configuration.

8

So you posted to ask why your certificate doesn’t cover your Vault’s IP address???!? It’s your certificate. :slight_smile:

9

I have asked how to block the traffic to vault and consul over the ip address.