Can I connect to remote database via wireguard, and if so, how?

1

I need to connect to a client’s remote database on an Amazon EC2 instance. The client wants to use an IP whitelist and I understand that a fly does not offer stable outbound IPs. My question is:

Would it be possible to connect to the db using wireguard?

My thought would be to use fly wireguard create and share the resulting config with the client, but I may be misunderstanding how these connections work.

Forgive my ignorance on this topic and thanks for your help!

2

You’re not far off!

You’d want something like a “bastion” host that you run in the AWS account that runs wireguard so you can make a connection to the database.

There is some prior art. You wouldn’t need to do exactly what these folks do but hopefully this illustrates some of the key parts.

3

This is very helpful, thank you!

4

Is it possible to set up a Wireguard VPN the other way around with fly as the “client”, i.e. from a config file? From what I can tell it’s not.

5

I’m trying to connect with wireguard the other way around. The wireguard gateway is running somehwere else I and I want connect to it from within fly rather than a bastion connecting to a fly gateway. I tried to run wg-quick up in the apps entrypoint and I am getting this error.

sudo: error while loading shared libraries: libsudo_util.so.0: cannot open shared object file: No such file or directory

  1. Is it even possible to make a wireguard connection this way?
  2. If so, why is sudo breaking here?
6

Hi @bgaudino

Yeah, it should be possible to setup Wireguard from VM to a gateway running somewhere else. The kernel we use for the virtual machines is built with Wireguard support enabled.

If so, why is sudo breaking here?

Something is wrong with the Docker image. Can you share your Dockerfile?

7

Thanks, @pavel. I’m actually using a heroku buildpack. Here is my fly.toml. I was getting a wg-quick: command not found so I tried installing it via the “fagiani/apt” buildpack . Maybe using a Dockerfile is a better approach?

app = "wordbank-dev"
primary_region = "dfw"
kill_signal = "SIGINT"
kill_timeout = "5s"

[experimental]
  auto_rollback = true

[build]
  builder = "heroku/buildpacks:20"
  buildpacks = ["fagiani/apt", "heroku/python"]

[deploy]
  release_command = "python manage.py migrate"

[env]
  DJANGO_SETTINGS_MODULE = "ch2.settings_dev"
  PORT = "8080"

[processes]
  web = "wg-quick up wg1.conf && gunicorn ch2.wsgi:application"
  worker = "wg-quick up wg1.config && python manage.py worker"
  scheduler = "wg-quick up wg1.config && python manage.py scheduler"

[[services]]
  protocol = "tcp"
  internal_port = 8080
  processes = ["web"]

  [[services.ports]]
    port = 80
    handlers = ["http"]
    force_https = true

  [[services.ports]]
    port = 443
    handlers = ["tls", "http"]
  [services.concurrency]
    type = "connections"
    hard_limit = 25
    soft_limit = 20

  [[services.tcp_checks]]
    interval = "15s"
    timeout = "2s"
    grace_period = "1s"
    restart_limit = 0

[[statics]]
  guest_path = "/workspace/static"
  url_prefix = "/static"
8

Yeah, looks like an image generated by buildpacks is missing wg-quick

Yep. Since you need to install some custom tools, I think the only way is to use your own Dockerfile.

1 Like
9

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