Accessing a database on my network over Wireguard link

Using fly wireguard create org-name lhr gateway-machine production.conf I have created a wireguard conf file. I edited the file to add the network I want to access.

The file looks like this:

[Interface]
PrivateKey = My private key
Address = address for my gateway machine
DNS = DNS for gateway machine

[Peer]
PublicKey = My public key
AllowedIPs = [ip address],10.144.0.0/27
Endpoint = lhr2.gateway.6pn.dev:51820
PersistentKeepalive = 15

I added it to my Wireguard conf folder and brought the interface up. Connection goes up, I can ping _api.internal fine, and when I ping the IPv6 address assigned to my gateway it responds (tcp dump confirms it recevies packets)

What I want to do, is connect to a database on my 10.144.0.0/27 network. I though adding it to the AllowedIPs line would somehow tell fly.io to send traffic from my private network to the gateway. But when I ping something on that network, the gateway receives no packets.

Does anyone know how to let fly.io know it needs to send packets destined for the /27 to the gateway?

Thanks

If I’ve understood your question properly, the issue could likely be that the 10.144.0.0/27 network listed in the AllowedIPs field is only under the [Peer] section, when it should be added under the [Interface] section as well.

The [Peer] section simply tells Fly which allowed IP ranges are routed to the specific peer. However, traffic from your local machine to 10.144.0.0/27 is not getting routed through Wireguard tunnel. You could modify your .conf file to include the allowed IP range in [Peer] section which would look like this:

[Interface]
PrivateKey = My private key
Address = address for my gateway machine
DNS = DNS for gateway machine
AllowedIPs = [ip address],10.144.0.0/27

Save the following changes and restart your Wireguard interface. Ping your database again and this should allow the packets to be routed through the tunnel to your gateway machine.

Hope this helps!

Thanks for responding ashitag. It turns out this would never have worked. There’s no way to affect the routing in the Fly.io network so packets would never get pushed to my gateway.

I solved this in the end by putting an nginx reverse proxy on the gateway and telling all the apps to use its Fly.io IPv6 address as the database in my peered network. Worked a treat.

Thanks

Seems like a practical workaround.Was searching through some answers within the community and I found this excellent guide Connect on-premise networks to Fly via Wireguard

You might want to check this out.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.