Issue With Wireguard // Connecting To Postgres (User Error I'm Sure)

[austincollinpena]

Error

psql: error: could not connect to server: could not translate host name “my-app-name.internal” to address: Name or service not known

1. I created a Wireguard location in LA

C:\programming-projects\golang\no-idea>flyctl wireguard list
Automatically selected personal organization: Austin Pena
+-----------+--------+-------------------------+
|   NAME           | REGION |   PEER IP  |
+-----------+--------+-------------------------+
| <wireguard-name> | lax    | <redacted> |
+-----------+--------+-------------------------+

2. I followed the instructions to create a tunnel in Wireguard, running dig _apps.internal in my WSL gives me a TXT record of my app names (so I know I’m connected). It also includes a TXT record of my app name I’m trying to connect to

3. Running

 psql postgres://postgres:<password>@<name>.internal:5432

Gives me an error

psql: error: could not connect to server: could not translate host name "<app-name>.internal" to address: Name or service not known

How can I debug this so I can connect to my postgres app? I just need to be pointed in the right direction

[thomas]

If dig works in WSL, your WireGuard connection is working. But is your nameserver pointing to the private DNS nameserver? You don’t have to configure that, but if you don’t, you won’t be able to directly use .internal hostnames on the command line; you’ll have to look them up explicitly with something like dig.

[kurt]

If this is on Mac OS, you may need to open a new terminal after connecting wireguard. DNS resolution for wireguard connections seems to require some shell setup magic that doesn’t happen when I try to use an existing shell.

Other OS’s might be the same.

You can also connect to the IP directly:

psql postgres://postgres:<password>@[<ipv6>]:5432

(Note the [ ] around the IPv6 address)

[austincollinpena]

@thomas

But is your nameserver pointing to the private DNS nameserver?

How can I tell this?

@kurt Even after setting up wireguard before opening my shell, I don’t even think I end up getting the ipv6 address.

Here’s what I get

austin@Austin:/mnt/c/Users/Austin Pena$ dig app-name.internal

; <<>> DiG 9.16.1-Ubuntu <<>> app-name.internal
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46852
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;app-name.internal.         IN      A

;; AUTHORITY SECTION:
.                       696     IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2021071900 1800 900 604800 86400

;; Query time: 50 msec
;; SERVER: 172.30.144.1#53(172.30.144.1)
;; WHEN: Mon Jul 19 09:59:11 PDT 2021
;; MSG SIZE  rcvd: 125

[kurt]

dig won’t use the system resolver hijinks that Wireguard creates. Will you try ping app-name.internal?

[austincollinpena]

Ping in both powershell and WSL didn’t return anything.

There has to be some sort of connection I’m making though, because when I turn off wireguard and run dig _apps.internal I don’t get the list of app names.

[kurt]

Oh I’m a dummy! You’ll need to specify AAAA for dig. So dig AAAA app-name.internal.

You might also have to run ping6 app-name.internal.

[austincollinpena]

Dig ended up showing something

Dig:

austin@Austin:/mnt/c/Users/Austin Pena$ dig AAAA app-name.internal

; <<>> DiG 9.16.1-Ubuntu <<>> AAAA app-name.internal
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3330
;; flags: qr rd ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;app-name.internal.         IN      AAAA

;; ANSWER SECTION:
app-name.internal.  0       IN      AAAA    fdaa:<redacted>:2
app-name.internal.  0       IN      AAAA    <redacted>

;; Query time: 0 msec
;; SERVER: 172.30.144.1#53(172.30.144.1)
;; WHEN: Mon Jul 19 14:18:59 PDT 2021
;; MSG SIZE  rcvd: 116

And then when I run

psql postgres://postgres:<password>@[fdaa:0:95<redacted>:2]:5432

I get

psql: error: could not connect to server: could not connect to server: Network is unreachable
        Is the server running on host "<ipv6 address" and accepting
        TCP/IP connections on port 5432?

[kurt]

It makes no sense that dig works but psql won’t, I don’t get it.

We are working on a command that lets you bypass system wireguard to connect to a postgres, I think that will help. My guess right now is that this is an issue with Windows + wireguard. If you’re not using wsl version 2, it might be worth trying that.

[austincollinpena]

I am using WSL v2. Let me know the status on that command or if you can think of any work arounds to connect something like Datagrip or connect to my postgres directly.

[Muhamad_Fakhrusy]

Hello! I recently stumbled upon this issue myself when using fly with WSL2 in Windows when trying to connect to a postgres db with WireGuard

I don’t know whether you’ve already resolved this issue or not, but I fixed this by installing the WireGuard client inside my WSL2 instead of the WireGuard windows client.

Hopefully, it can help anyone that see this error too in the future

[SleeplessByte]

Also on Windows. I do not use WSL(2).

• Wireguard: connects.
• Opening WSL, then doing dig AAAA app-name.internal: works
• Opening cmd.exe (NOT wsl) and pinging the ipv6 address: works
• psql postgres://…@[ipv6]:5432 (WSL): nope
• psql postgres://…@[ipv6]:5432 (NOT wsl): nope

[austincollinpena]

This is what I use. flyctl ssh

[furd]

As another test using Windows with Wireguard:

• Wireguard: connects.
• Opening WSL, then doing dig AAAA app-name.internal: works
• Opening cmd.exe (NOT wsl) and pinging the ipv6 address: works
• Attempting to connect via DataGrip using app-name.internal: nope
• Attempting to connect via DataGrip using the ipv6 address: works

Would definitely like to be able to use the app-name to connect as it leads to quite a bit of wondering if Wireguard is working at all and general confusion!

[kurt]

It sounds like Datagrip isn’t using the system resolver for name lookups. This isn’t uncommon, some apps do their own DNS resolution and know nothing of the wireguard names.

The simplest solution might be to use fly proxy 5432 <db-name>.internal, then connect datagrip to localhost:5432. If you’re already using 5432 you can use fly proxy 15432:5432 <db-name>.internal instead (and then connect to localhost:15432).

[furd]

I can confirm that Datagrip on my Macbook Pro seems to work using the Wireguard name lookup, just not the Windows installation.

[kurt]

This would be worth asking JetBrains about. Datagrip’s DNS resolver is something we can’t change. They may allow you to override the DNS resolver, though.

[furd]

Realistically I don’t think it’s Datagrips DNS resolver for my end in that:

dig via WSL succeeds at hitting the DNS entry.
dig via cmd, not WSL fails to hit the DNS entry.
I can connect via the IPv6 address once I have it, just not resolve the IP via DNS.

So my WSL system is correctly using the Wireguard DNS resolver but my native Windows DNS resolution does not.

[kurt]

Oh I misunderstood your check mark list!

Are you running wireguard in WSL or Wireguard on the Windows side?

The split DNS Wireguard does will probably not work in both WSL and Windows native at the same time.

I don’t know much about Windows DNS, but you might be able to update your Windows config to use the fdaa::X:Y address in the DNS field of your wireguard config.

The root problem here is that there’s no universal way to say “send all DNS lookups for .internal to this IP, and send the rest to the default resolver”. Wireguard does what it can but it’s brittle. WSL + Windows native make it more complicated.