WireGuard noob challenges

1

New to WireGuard (and IPv6) but interested in its use here. I’m challenged getting it to work:

Local machine is Ubutun 20.04 with WireGuard (sudo apt install wireguard)

Following the instructions, I was unable to use basic as the DNS name:

NOTE the documented flow no longer matches the flyctl wireguard create flow (v0.0.210).

flyctl wireguard create
Automatically selected personal organization: [[redacted]]
? Region in which to add WireGuard peer:  sea
? New DNS name for WireGuard peer:  basic
Creating WireGuard peer "basic" in region "sea" for organization personal
Error add peer failed: Name has already been taken

So, I used my freddie.

I assume (!?) basic is a global name for that region because, it’s not in my org:

flyctl wireguard list
Automatically selected personal organization: Daz Wilkin
+---------+--------+---------------------------+
|  NAME   | REGION |          PEER IP          |
+---------+--------+---------------------------+
| freddie | sea    | [[IPv6-redacted]]         |
+---------+--------+---------------------------+

Then I:

wg-quick up freddie
[#] ip link add freddie type wireguard
[#] wg setconf freddie /dev/fd/63
[#] ip -6 address add [[IPv6-redacted]]/120 dev freddie
[#] ip link set mtu 1420 up dev freddie
[#] resolvconf -a freddie -m 0 -x
[#] ip -6 route add fdaa:0:205d::/48 dev freddie

And:

ip a show freddie
515: freddie: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet6 [[IPv6-redacted]]/120 scope global 
       valid_lft forever preferred_lft forever

But:

dig -6 _apps.internal TXT

Yields:

; <<>> DiG 9.16.1-Ubuntu <<>> _apps.internal TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26815
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_apps.internal.			IN	TXT

;; Query time: 971 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Apr 14 09:40:38 PDT 2021
;; MSG SIZE  rcvd: 43

I have an app deployed:

flyctl apps list
NAME    OWNER    STATUS  LATEST DEPLOY 
[[app]] personal running 43m47s ago

And I added:

[experimental]
  private_network = true

NOTE I am confused by this annotation. IIUC, it enables private networking but I expected it to disable public networking too; it does not.

2

DNS is tricky, it may not even work transparently on Ubuntu. Those .internal names might only work with the internal DNS resolver. If you look in your wireguard config, you’ll see a line like this:

DNS = fdaa:0:33::3

If your wireguard link is up, you should be able to run dig TXT _apps.internal @fdaa:0:33::3.

Will you see if that works?

3

Thanks Kurt!

Unfortunately not:

dig TXT _apps.internal @fdaa:0:33::3

; <<>> DiG 9.16.1-Ubuntu <<>> TXT _apps.internal @fdaa:0:33::3
;; global options: +cmd
;; connection timed out; no servers could be reached

Is this simply because my host is not (correctly) configured to use IPv6?

I’m unfamiliar with IPv6 but, both interfaces appear to have IPv6 addresses:

ip a show enp5s0
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 54:b2:03:0a:06:5c brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.150/24 brd 192.168.1.255 scope global dynamic noprefixroute enp5s0
       valid_lft 53171sec preferred_lft 53171sec
    inet6 fe80::1010:e2a3:af0e:a512/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

ip a show wlp6s0
4: wlp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 94:b8:6d:a1:a1:ad brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.186/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp6s0
       valid_lft 68354sec preferred_lft 68354sec
    inet6 fe80::2b13:6c42:349:9d82/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

And:

net.ipv6.conf.eno1.disable_ipv6 = 0
net.ipv6.conf.enp5s0.disable_ipv6 = 0
net.ipv6.conf.freddie.disable_ipv6 = 0
4

Neither of those are wireguard, the freddie interface is the one that matters. I just noticed it has a state of UNKNOWN, which makes me think it’s not connecting properly.

Try running wg from the CLI and see what you get. That output is safe to share, it should show you last handshake time.

5

Thanks!

sudo wg
interface: freddie
  public key: AW44Jb2CRuvnQiFZo+ZDaqCuF7CLznw/kCeAiYIZ+z8=
  private key: (hidden)
  listening port: 49622

peer: lF2/TP+VYu68DQTDgWVr3nE18e5TbnfeATLZ239zNEw=
  endpoint: 51.81.56.218:51820
  allowed ips: fdaa:0:205d::/48
  transfer: 0 B received, 148 B sent
  persistent keepalive: every 15 seconds
6

Oh also, this IP is specific to me @fdaa:0:33::3, you should have a different DNS IP in your wireguard config to try. That one definitely won’t work.

Will you paste your Wireguard config, minus the private key?

7

Really appreciate your patience with me!

sudo more /etc/wireguard/freddie.conf

[Interface]
PrivateKey = [[REDACTED]]
Address = fdaa:0:205d:a7b:ab6:0:a:2/120
DNS = fdaa:0:205d::3

[Peer]
PublicKey = lF2/TP+VYu68DQTDgWVr3nE18e5TbnfeATLZ239zNEw=
AllowedIPs = fdaa:0:205d::/48
Endpoint = 51.81.56.218:51820
PersistentKeepalive = 15

Then:

dig TXT _apps.internal @fdaa:0:205d::3

; <<>> DiG 9.16.1-Ubuntu <<>> TXT _apps.internal @fdaa:0:205d::3
;; global options: +cmd
;; connection timed out; no servers could be reached
8

I’m pretty sure this is our bug and I think I know what’s happening.

If it’s not too much of a pain, can I get you to make a new WireGuard peer, but use region ord instead of sea?

You should be able to wg-quick down current.conf (assuming you saved your current conf in current.conf and then just wg-quick up new.conf.

The configuration will have a DNS server in it (like the one above); can you try, on the new config, ping6 <that-dns-IP>?

If that works, dig _apps.internal <that-dns-IP> should also work.

9

That appears (!?) to work:

wg-quick up chicago
[#] ip link add chicago type wireguard
[#] wg setconf chicago /dev/fd/63
[#] ip -6 address add fdaa:0:205d:a7b:bea:0:a:2/120 dev chicago
[#] ip link set mtu 1420 up dev chicago
[#] resolvconf -a chicago -m 0 -x
[#] ip -6 route add fdaa:0:205d::/48 dev chicago

ping fdaa:0:205d::3
PING fdaa:0:205d::3(fdaa:0:205d::3) 56 data bytes
64 bytes from fdaa:0:205d::3: icmp_seq=1 ttl=64 time=53.4 ms
64 bytes from fdaa:0:205d::3: icmp_seq=2 ttl=64 time=52.8 ms
64 bytes from fdaa:0:205d::3: icmp_seq=3 ttl=64 time=54.0 ms
64 bytes from fdaa:0:205d::3: icmp_seq=4 ttl=64 time=53.2 ms
10

And:

dig TXT _apps.internal

; <<>> DiG 9.16.1-Ubuntu <<>> TXT _apps.internal
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51673
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_apps.internal.			IN	TXT

;; ANSWER SECTION:
_apps.internal.		300	IN	TXT	"green-dust-9098,blue-darkness-7665,ackal"

;; Query time: 51 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Apr 14 13:24:20 PDT 2021
;; MSG SIZE  rcvd: 96

The only app in my org is ackal.

The other 2 may be previously created|deleted apps but the names don’t look familiar.

11

Yeah so, this was us, not you, and I apologize for having besmirched the well-deserved reputation WireGuard has for usability.

Here’s what happened:

We recently made a backend change for flyctl ssh console — which auto-generates WireGuard connections to run SSH over — so that it wouldn’t need to ask people which region to connect to. The code that does that works by computing the nearest neighboring WireGuard gateway to the region you’re asking for (or that your request comes from).

When I merged that change, I forgot that our original beta WireGuard gateway was still in the system and still claiming to be near to Oregon, so people asking for SEA were getting the defunct Oregon endpoint.

That should be fixed on our side, and SEA will probably work as a region again (you won’t get a SEA endpoint; I think you’ll get SJC — but you won’t get an old defunct gateway as punishment for being in Seattle anymore).

Thank you for bearing with us on this!

1 Like
12

Thank you both for helping resolve this issue for me!

By the way, Thomas, your post Incoming! 6PN Private Networks is very good

2 Likes
13

These names are auto-generated, and refer to apps attached to your organization (presumably from an earlier deploy?). Neither are running or exist presently in our system, but DNS has some update lag on that right now.

14

Yes, understood. I tend to remember most of the names but was unsure on those…

Glad they’re mine and just an eventual consistency issue :slight_smile:

BTW: Why can’t I use basic as the DNS name per the docs?

15

There’s probably no good reason for us to enforce uniqueness on that name; our private DNS server won’t let you see other people’s WireGuard names.

(Yours, like freddie, you can see on _freddie.peer.internal — so, for instance, if you set up a WireGuard connection on Digital Ocean and ran MySQL there, you could name the peer mysql-do and your apps running on Fly could reach it at mysql-do._peer.internal.).

We’ll probably fix this uniqueness constraint soon.

1 Like