There is a gateway in London. You can see all the regions + gateways with flyctl platform regions.
We’ll have gateway in all regions over the next few months, too.
Is it possible to make all the traffic from my workstation go through the vpn?
Nope, you’ll only be able to reach addresses on your private network through the WireGuard gateways we generate; we did that not because we have strong opinions about VPNs but because it provides a simple strict security rule for locking down traffic into our network.
Ok I’m not a big network nerd(though I would love 2) but I like to try weird stuff. I want to deploy an HAProxy app on @flydotio as a LoadBalancer to my theoretical homelab nomad cluster. Given this development with wireguard 6PN(as you like to call it:grinning_face_with_smiling_eyes:) how would you suggest I proceed. My theoretical cluster runs consul/HAProxy (fabio) for internal service discovery. How do I get traffic from the internet facing flyio app to my blog at “consul.service.blog”? Does this whole premise even have a leg to stand on or should I choose another career(
imposter syndrome kicking in)
Yes this works! I have a similar setup (though not with nomad). It’s going to take some tweaking, though.
The big problem you’re going to have is getting the allocations in Nomad exposed on a Fly 6PN IP. Your best bet might be to run HAProxy on your nomad cluster, then a really slim haproxy on Fly that just forwards requests to it.
What you’ll need is a WireGuard gateway configured on your nomad node. flyctl wireguard create will generate this config for you. This is what my config ended up looking like:
kurt@nuc:~$ cat /etc/wireguard/wg0.conf
[Interface]
PrivateKey = <private-key>
Address = fdaa:0:5f4:a7b:bea:0:a:2/120
DNS = fdaa:0:5f4::3
[Peer]
PublicKey = RKAYPljEJiuaELNDdQIEJmQienT9+LRISfIHwH45HAw=
AllowedIPs = fdaa:0:5f4::/48
Endpoint = ord1.gateway.6pn.dev:51820
PersistentKeepalive = 5
Start that interface with sudo wg-quick up wg0.
The Address in there is what you’ll need to forward requests to. You can configure your Fly haproxy to connect to it with something like this:
backend blog-backend
balance leastconn
server nomad nomad._peer.internal:80 check inter 1000
2 Likes
This confirms what I had found during my research this afternoon. I was just reading this: IPv6 WireGuard Peering · Fly, Load Balancing with HAProxy Service Discovery Integration | Consul - HashiCorp Learn. And it appears that haproxy is my best bet. The only difference with my own theory is I was planning to use fly’s internal DNS as the resolver since every time you add a wireguard peer the DNS server picks it up. But this suggestion does seem better. Thanks. What’s your setup like anyway? k3s?
Don’t you have to define a resolvers node here though? In which case you will have to indicate where your consul service is running?
No nothing even that complex. I have some services running on a home server for … managing video files. The server runs a wireguard peer, the services all bind to the 6pn address for that peer on different ports.
And then I run Ombi on Fly pointing to specific ports on my home server:
1 Like
Ah, that was a bad example. It should be like:
server nomad nomad._peer.internal:80 check inter 1000
At first I was trying to figure out how to let your Fly based haproxy resolve consul directly, but it probably won’t work out since you only really have one IPv6 address to point at.
The exact line I have been turning around in my head. It seems after going through all your networking blog posts I have peeked a few things myself .
If I’m interpreting this right. This peer is the nomad node that is also running a consul instance right. I would have to add more entries of the same kind if I had more nomad client nodes. Which would be inconvenient if nodes joined and left randomly. I was hoping flyio’s internal dns would help with that by making it the resolver for all _peers.internal entries.
Yeah, the big limitation of our wireguard peers is that they’re single IP/node only.
Making _peer.internal return all the AAAA records is an interesting idea, though. Right now dig txt _peer.internal returns a list of peer names.
You could also just create several and let haproxy on fly detect if they’re alive or not.
I’m gonna have to test the waters first and narrow down the possibilities.