Connection Refused Issue with localhost, ::1, IPv4/IPv6 and selfsigned certificate

[wolowizard]

Hi,

I'm developing a small script to automatically store secrets data in Hashicorp vault. I have Hashicorp vault for development with a selfsigned certificate on my laptop, configured to store some secrets. I can access it with a browser without any problems.

when i run the script with trace
CRO_TRACE=1 ./vault-creds

I get "connection refused", when i exchange localhost with the IP 127.0.0.1 the error is "permission denied".

Maybe the issue is that it is only the hostname localhost without a dot? I'm not sure what happens.

Kind regards
Peter

[wolowizard]

you can find the the test script on Gist

[wolowizard]

I've added the CRO_TRACE output when using 127.0.0.1 instead of localhost in another (redacted) gist I get 403 Forbidden

When using "localhost" there is no trace output just an error msg "connection refused"

[librasteve]

I have fed the trace to ChatGPT ... most likely rubbish, but it seemed to have some sensible things to check.

https://chatgpt.com/c/6939e608-65e8-8325-a965-7b3dcd7f7b92

Summary
Your networking, TLS, and HTTP are working fine.
Vault receives and parses your request normally.
The error is strictly:
➤ Vault token does not have permission to write to dns/data/tst-srv/admin in namespace dev.
Fixing the ACL policy will resolve it.

sorry if this is bullshit

[wolowizard]

I removed the vault token from debug log, even this is only for development. so it's definitivly not the token. Unfortunately I don't know enough about vault to configure permissions for the IP.
I wrote a perl5 script with REST::Client that can interact with the vault server on localhost:8200 and with curl -k it's also not a problem to interact with the vault server

curl -k -H @myheader https://localhost:8200/v1/vci-dns/data/tst-int/admin
{"request_id":"9c242a9e-0382-865d-58a1-ac4d4cde10ae", ...}

[wolowizard]

Hi,

I did some more tests:
the vault server running without TLS on localhost on another port (8199) and connecting there I also get "Error: connection refused" and there is no trace output with the vault-creds script.
Accessing it with curl works fine.

I took the example from the perl5 module HTTP::Server::Simple and started a server on port 8080 which works fine with curl and again if I use the vault-creds script I get always the same "Error: connection refused" and no trace output.

Does this only happen to me or can someone replicate those problems?

Looks like I accidentially closed this issue. Perhaps someone could reopen it again?

Kind regards,
Peter

[librasteve]

@lizmat - thanks!

@wolowizard

I am in catch up mode here a little - sorry taking so long to get to the bottom of this.

So far I have installed Hashicorp vault and I can connect like this:

~ > curl \                                         
  --header "X-Vault-Token: hvs.e6q6E1ZbP0vKSD6lid31wATZ" \
  --request GET \
  http://localhost:8200/v1/dns/data/tst-srv/admin
{"request_id":"4208147a-b1c9-453c-b42f-ec0961379fc1","lease_id":"","renewable":false,"lease_duration":0,"data":{"data":{"password":"SuperSecretPassword123","username":"adminuser"},"metadata":{"created_time":"2025-12-11T17:53:25.801302Z","custom_metadata":null,"deletion_time":"","destroyed":false,"version":1}},"wrap_info":null,"warnings":null,"auth":null,"mount_type":"kv"}

and similarly, this:

#! /usr/bin/env raku

use v6.d;

use Cro::HTTP::Client;
use JSON::Fast;
use URI;

my $filename = $*HOME~'/.myvault-token';
my $token    = chomp $filename.IO.slurp;
note "token: $token";

my $headers = [ 
    :X-Vault-Namespace('dev'),
    :X-Vault-Token($token)
];

my \client = Cro::HTTP::Client.new: 
    base-uri => 'http://0.0.0.0:8200/',
    content-type => "application/json",
    #ca => { :insecure },
    :$headers 
;
        
my $uri='v1/dns/data/tst-srv/admin';

#my %body = :uri('https://srv.test.lab'), :login('admin'), :passwd('v3rys3cr3t');
#my \r = await client.post( $uri.Str, :%body );

my \r = await client.get( $uri );
say await r.body;

CATCH {
  default {
    $*ERR.say: "Error: " ~ .message;
    for .backtrace.reverse {
      next if .file.starts-with('SETTING::');
      next unless .subname;
      $*ERR.say: "  in block {.subname} at {.file} line {.line}";
    }   
  }
}

Please note that I get connection refused if I use localhost and not 0.0.0.0 loopback IP

This DOES work on 127.0.0.1:8200 also

OK - so I have achieved something ... but now have to read your issue to see if I have actually answered your query!

NOTE: so far this is vault running in non-TLS mode

[librasteve]

I have tried to configure my vault with certs on localhost - but no luck yet - looks like i am going to run out of time today

maybe this provides some clues...?

[wolowizard]

BTW, I have this on Ubuntu 22.05.5 LTS with rakubrew and moar-2025.08

[wolowizard]

Hi,
I just found something. I started tshark on localhost and i saw that the raku script wanted to connect to ::1, where vault and the 8080 http server is not running on.
I changed my /etc/hosts and modified the ::1 line from "localhost" to "localh"

127.0.0.1  localhost
::1        localh ip6-localhost ip6-loopback

And this did the trick, the raku script ran successfully with perl http server on port 8080 and also with vault and TLS on port 8200

For some reason there is only one try to connect with ipv6 localhost address and i get this "connection refused" Error. Shouldn't there be another try with ipv4 127.0.0.1 to connect as a fallback or so?

Kind regards,
Peter

[librasteve]

@wolowizard - thanks for your patience. I have used ChatGPT to dig up some background here (sorry again - but I am not an expert in IPv4 / IPv6 fallbacks - so thought it best to share my "sources' in case they are crap)

My takeaway is:

Many languages and libraries (including Rakudo’s Raku IO::Socket::Async, LWP-type libraries in Perl, and even some OpenSSL wrappers) use getaddrinfo() to resolve hostnames.

When getaddrinfo("localhost") is called, your /etc/hosts determines the order of returned addresses. On many Linux systems:

::1     localhost
127.0.0.1 localhost

Order matters: IPv6 is returned first.

Many networking libraries — including those used in Raku — will:

1. Try the first record returned (in this case, ::1)
2. If that fails immediately (e.g., host unreachable) they may try the next record
3. But if the failure is a connection refused, many libraries treat it as a "valid but failed attempt" and do not retry with other addresses

This behavior is documented in POSIX and in some RFCs:
"Connection refused" means “host reachable but port closed,” not "address unusable".

So the library often stops there and does not try IPv4.

---

At high level, it is not unreasonable to expect the application layer to retry, but I cannot see an easy way to do this without ripping out getaddrinfo() or "micromanaging" by directing it to walk multiple options (which really would be very difficult to get right in the general case imo).

A superficial search suggests that eg Rails and Django are subject to the same issues, but I haven't tested this.

---

The default /etc/hosts on Ubuntu 24.04 LTS is:

127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

And macos is:

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost

So that explains why test passes.

[librasteve]

I have taken the liberty of renaming this issue so that hopefully others will find it more easily in future.

[wolowizard]

@librasteve, thanks so much for your help!

I had also created a perl script for testing with REST::Client - which is using LWP UA - and I didn't experience any trouble with accessing the localhost vault API. I'm not sure how the issue is solved there, I didn't look further into it.
My workaround is using a different name like 'localvault' in the URL and changed my /etc/hosts

127.0.0.1  localhost localvault
::1        localhost ip6-localhost ip6-loopback

Perhaps this behaviour could also cause problems with A and AAAA records for the same FQDN.

Kind regards,
Peter