Somehow, for reasons I promise you don’t want us to get into, getting DNS open was more complicated than getting 25565/tcp-udp open for Minecraft. If you check this evening, you should be able to run a Minecraft server, though don’t quote me, because I’m not going to try to actually run one until this evening.
There will probably be some wonkiness: 25565/udp will only work on your fly-global-services address (all edge UDP gets directed there). What I’m saying here is: don’t bang your head against the wall too much on it; if you have problems, let us know, and we’ll try to be the ones who spend time debugging, not you.
53/tcp is still not open. In the meantime I recommend running DNS over 25565/tcp.
I KID. 53/tcp should work sometime early next week.
Getting every port working is on our docket. The simple way for us to that is with socket-steering eBPF code, but to make that work we’ll need to do a fleet kernel update, and since we have the luxury, it’ll probably be a couple weeks out.
I can knock out 6443 early next week too, and I’m happy to take requests for other ports if it’s likely that more than 1 person wants it. (I say “I’m happy” but really it’s Steve doing the heavy lifting here and just me taking the credit. Except for DNS-over-Minecraft, an idea I expect full credit for.l)
What are you doing with kubernetes? It weirds me out a little to expose the k8s API publicly. I think for k8s, it’d be better to setup a wireguard peer and connect through the private network (and all ports work over the private network).
You should no longer get this error! I’m able to launch 53/tcp things now.
We also added 8443/tcp (and, of course, the Minecraft port).
(Correction: I spoke too soon on 8443/tcp, that may be a couple hours; it’ll go in with the next fly-proxy deploy. 53/tcp and 8443/tcp are, so far, the weird ones; everything else is a one-liner.)
It’s still in our backlog! The way we want to fix this is with a BPF program to redirect all anycast traffic on any port to our proxy; to get that working, we need to get all our machines on a specific kernel. We’re currently working on fixing an incompatibility between that kernel and our existing BPF code.
We spent a good amount of time last week working on this; it’s definitely being actively worked on, and is annoying the hell out of us.
Hey! 853/tcp should work now (you don’t need fly-global-services for this! You only need that for UDP, so that our XDP code doesn’t mess with the UDP DNS that your VM already generates).
7777/tcp turns out to be slightly tricky for reasons I am too embarassed to report here but will explain once we’ve fixed it, which is the next thing on my docket.
Sorry for the delay on the first port; I added it to our API, but it was waiting on a fleet deploy to actually work. It is very silly that we have to do big deploys to add ports, and that too is something we are working on fixing.