Unable to connect to personal org via fly proxy or fly ssh

,
1

When running fly proxy or fly ssh to apps/postgres databases on a personal org, this error occurs:

Connecting to tunnel 🌏Error: tunnel unavailable: Error contacting Fly.io API when probing "personal": connect tcp [fdaa:7:ba29::3]:53: connection was refused

Output from running fly doctor:

Testing authentication token... PASSED
Testing flyctl agent... PASSED
Testing local Docker instance... PASSED
Pinging WireGuard gateway (give us a sec)... PASSED
Testing WireGuard DNS... FAILED
(Error: wireguard dialer: failed to lookup _api.internal: connect tcp [fdaa:7:ba29::3]:53: connection was refused)

Accessing machines on shared orgs however work nicely. This also occurs on both fly.io-accounts I have tried (personal fails, shared org works), and also regardless if I try connecting from different local computers.

3

Hm… It looks like you can get packets through to the gateway, but perhaps not any farther. If you go to the dashboard, can you see (fresh) “live logs” for any of the machines in your personal organization?

https://fly.io/apps/<app-name>/monitoring

(Those logs maybe can’t even flow if the .internal network itself isn’t working…)

If things do look alive in there, it might be worth trying to SSH in via the numeric fdaa:* address:

https://community.fly.io/t/networking-problem-in-release-command/22980/2

Hope this helps a little!

4

Yes, everything else works (at least that I can tell), except for fly ssh & fly proxy.
This means live logs, deploying/restarting/suspending/stopping machines and so on.

Even fly pg connect works :man_shrugging:

Trying to connect via fly ssh to the same machine ips that fly pg connect uses, doesn’t work…

fly doctor passes for the other non-personal org.

5

That’s very strange, since fly pg connect and fly ssh console are both SSH sessions…

(I only recall seeing those two diverge in behavior in one other case before.)

The following are just some ideas, in case you haven’t seen them already, mostly in the “try turning it off and on again” vein:

1. Remove the existing agent and gateway(s).

$ fly agent stop
$ fly wg remove personal  # may have to be repeated several times.

2. Toggle flyctl’s user-mode WireGuard between websockets and UDP.

3. Fall back to the older kernel-mode WireGuard style.

6

Yes, I’ve also exhausted all the “usual” options with removing all wg-peers, restarting the agent, enabling websockets, etc, still the same result, personal org(s) are inaccessible but other orgs works just as expected.

These orgs are also on the Hobby-plan, and changing to Pay As You Go apparently won’t take effect until Jan 1st, so I can’t apply for any support plans until then apparently, which leaves me with machines that I’m unable to reach the rest of this month, which is not sustainable really :sweat_smile:

7

I don’t think this is really intentional… Try emailing billing@fly.io; they were able to resolve a very similar case recently:

https://community.fly.io/t/launch-plan-not-applied/22400

(Unlike the other addresses, any user can send to this one. You don’t need an active support plan.)

8

Contacted Fly via the billing email, which converted the org plan on the spot, so I could sign up for a support plan.

Thanks for trying to help out!

1 Like
9

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