I am just assessing whether fly.io is good for our purposes but I got hit by a roadblock. Apparently neither fly deploy nor fly postgres connect work if you only have IPv4 enabled / available. While I hoped this won’t be a problem in 2023 - it looks like apparently although the UK’s biggest home broadband provider still doesn’t provide IPv6 in 2023… https://test-ipv6.com/ gives me a 0/10 score.
Again back to the issue: both of the commands above try to connect to IPv6 hosts which will always time out / fail, as IPv6 access is simply not available at all, example:
fly postgres connect
Connecting to fdaa:3:c1c1:a7a:af75:f531:5542:2... complete
Error: error connecting to SSH server: connect tcp [fdaa:3:c1c1:a7b:be65:e623:2455:2]:22: operation timed out
Is there any way of forcing these commands to run on IPv4, or I am out of luck as these won’t work without having access to IPv6?
(I managed to work around the issue by creating GitHub actions that ran the commands for me, but that’s far from ideal, especially during assessment)
Hmm, that’s strange! It should be working via wireguard tunnelling, which means your ISP shouldn’t need to support IPV6. Mine doesn’t, and I also get 0/10 on that site, but I am able to fly postgres connect.
Can you run fly doctor and see if there are any issues?
WireGuard also doesn’t work for me on networks where IPv6 is not enabled. I have tried on both OSX and Windows boxes without any luck. I have also tried it tethering from my mobile internet to see if my home router might be the problem, but also no luck.
On my EC2 where I could use the deployment commands WireGuard also worked without any issues
That sounds like something different, but I’ll see if I can figure something out. It should ‘just work’ – most of us who work here also don’t have ipv6 supported by our internet providers. So, I wanna see if there’s anything else that can causes issues.
Managed to get this working, and yes, it was not IPv6 related!
So what I did was I connected to the EC2 instance where it was working and obtained the wire_guard_state value from ~/.fly/config.yaml, then copied that verbatim into the fly/config.yaml on my computer. All fly commands work now.
Do note that the EC2 instance has connected to the ams region not lhr, so maybe the problem is that something’s wrong with the lhr wireguard service? If so it’s odd that it doesn’t crop up on the status reports though
Interesting! I’m hitting exactly the same conditions against LHR, also seeing “establish personal” seemingly work, but “ping6 personal” get dropped without reply.
At first I thought it was related to Tailscale conflicting with it somehow, so I uninstalled that completely and restarted. Gone through lots of agent restarting and doctor’ing.
Which region did you run the GCP one? The config I got for the ams region still works for me today, but I still cannot connect through the lhr one I would get by default if I reset the agent or wireguard settings
i got the same issue, just trying fly.io and it’s work great last week, but starting from sunday, i can’t proxy postgres app to my local… fly doctor always give me the same error
Pinging WireGuard gateway (give us a sec)... FAILED
(Error: ping gateway: no response from gateway received)
We can't establish connectivity with WireGuard for your personal organization.
WireGuard runs on 51820/udp, which your local network may block.
i have tried on my home and office network (IPv4 only), and try to connect via VPS that i know for sure it have IPv6 gateway, still got the same issue
This morning it’s working just fine to lhr… It may have just been the incident I see in the status page (Fly.io Status - Elevated deploy errors) that was making this fail last night and it just coincided with me onboarding. Bad luck.
$ flyctl doctor
Testing authentication token... PASSED
Testing flyctl agent... PASSED
Testing local Docker instance... PASSED
Pinging WireGuard gateway (give us a sec)... PASSED
No app provided; skipping app specific checks