fly proxy 1234 doesn’t seem to forward UDP traffic. It doesn’t listen on UDP ports. Is that intentional?
Glancing through the source code, this does look pretty intentional, yeah… My guess is that it is generally mimicking the more familiar ssh -L, which supports only TCP and Unix-domain sockets.
(fly proxy also supports the latter, actually, e.g., fly proxy /home/debian/ock:5556. That ability is not documented anywhere that I’ve been able to find, though.)
This command is super-handy but as a whole has long been described as “not very documented”, etc., so probably it’s just an oversight that its limitations were never stated explicitly.
Aside: We users were invited a while back to file bugs against the official docs’ GitHub repository…
I don’t have a GitHub account myself, so I haven’t tried, but that might be easier for people to keep track of than here in the community forum, 
.
1 Like
Interesting. It is possible to forward UDP using unix socker?
Unix-domain sockets are a separate kind of local-only communication mechanism (not Internet), and they aren’t very related to UDP. I was just mentioning them out of nerdy completeness, pretty much, 
.
(And also, I use that feature of SSH and spiped a lot, myself, for forwarding various kinds of stream-style communication. It was neat to see it in flyctl, too!)
There are other mechanisms that can tunnel UDP across streaming protocols, but they come with caveats, so they’re best avoided whenever it’s possible to do so.
Do you perhaps have a firewall in the way that’s blocking UDP?
flyctl indeed does not listen on UDP when the proxy command is used, though it’s probably not due to ssh. I don’t think this is really intentional rather than just not yet implemented.
I do agree this probably needs to be documented if it’s not implemented 
So it should be possible to use netcat to listen for UDP traffic and forward it through local socket to remote server (with Tarsnap - The spiped secure pipe daemon ) where reverse netcat is running. What are the caveats here?
Can you use kernel-mode WireGuard instead?
(I should have directly cited that as the first choice above.)
That would give you the best of both worlds: UDP-over-UDP plus authentication and encryption.
(And then you wouldn’t need netcat, spiped, fly proxy, or any other extra.)
Yes, this is what I am trying to do at the moment. There is some fear and uncertainty about MTU mentioned here Running apps on UDP and TCP · Fly Docs And I don’t know how to check if I am fine.
I also not sure how it is going to play with existing VPN. Maybe GNOME allows to switch on several VPNs simultaneously, but if I do something wrong, that would be impossible to debug.
That wasn’t at all meant to be scary, though, merely a brief “you may bump into this if you’re doing things that are atypical”. Either way, I don’t think it really pertains. That document is about UDP apps that you run yourself within the interior of the Fly.io platform, thus incurring an additional 12 bytes of overhead, whereas the link that I gave above is for the WireGuard gateways at the edges that Fly.io themselves manage.
Perhaps I’m misunderstanding what you’re trying to do with all this.
Could you say more about what final server or service you’re trying to connect to, once communication has passed through the entire chain of tunnels, VPNs, etc.? UDP is the hardest feature of Fly.io, so it’s best to choose a different architecture when possible…
Without claiming much knowledge of GNOME, when working on Linux more broadly, 
, a person can use network namespaces to avoid clashes. You can think of that as an isolation or partitioning mechanism that’s a partial container, separating network aspects only. WireGuard has particularly nice support for those:
(I’m typing this from within a network namespace currently, actually, although not WireGuard-related.)
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.