0

I am looking to forward a game server (Minecraft) port 25565 with UDP and TCP from one Ubuntu Server to another. I can easily do this with SSH -R option, but it only works for tcp, what can I do to make this work with udp?

Dequarious Mavik
  • 11
  • 3

1 Answers1

0

The easiest way is to use nc and a FIFO on both sides:

  • First set up another TCP tunnel with ssh -R on port 25566

  • on the source side: connect UDP port 25565 of the target server with TCP port 25566

    mkfifo /some/path/to.fifo nc -l -p 25566 < /some/path/to.fifo | nc -u target.server.ip 25565 > /some/path/to.fifo

  • on the target side: Connect TCP port 25566 with UDP port 25565

    mkfifo /some/path/to.fifo nc -l -u -p 25565 < /some/path/to.fifo | nc source.server.ip 25566 > /some/path/to.fifo

So UDP traffic is encapsulated into TCP on another port and so forwarded via ssh

You might also want to look into ssh -w to create a dead simple VPN via SSH with only two participants. This can then transport any traffic via a tun virtual device.

Eugen Rieck
  • 19,950
  • 5
  • 51
  • 46
  • Could you link to some good examples on how to use ssh -w and create a tun device? – Dequarious Mavik Jun 29 '19 at 04:36
  • 1
    I think `nc` approach is very limited. It will fix on the source address and port of the first UDP packet it handles. Also it's unclear what "source side", "target side", `source.server.ip` and `target.server.ip` are. I guess I got it: not only `source.server` is not the "source side", it's reachable from the "target side". Quite confusing. – Kamil Maciorowski Jun 29 '19 at 05:09
  • 1
    Oh, and [this](https://superuser.com/q/53103/432690#comment344670_53109): *TCP streams are not guaranteed to preserve message boundaries, so a single UDP datagram may be split in parts, breaking any protocol.* – Kamil Maciorowski Jun 29 '19 at 05:15
  • @KamilMaciorowski - did you read the OQ? It is a **Minecraft** Server! Minecraft UDP needs no message boundaries, it is used just as a streaming protocol, a usage pattern of *like TCP but without reliable transmission*. – Eugen Rieck Jun 29 '19 at 09:17
  • If you consider the fact confusing, that the **source server,ip** is reachable by the **target side** you might want to read up on the server-client model. – Eugen Rieck Jun 29 '19 at 09:18
  • How can the server-client model explain the difference between "source *server*" and "target *server*"? I mean there is no "client" in your answer at all. The question mentions "one server" and "another", so probably these are the servers. Phrases "source side" and "target side" contain neither "server" no "client", it's not obvious the server-client model even applies and how. But "source server" and "source side" share the crucial word, it's natural to think they are related. Only they are not. *This* is confusing. Source-target model might help (but what is it?), not server-client. (cont'd) – Kamil Maciorowski Jun 29 '19 at 19:26
  • (cont'd) I think I was able to "decipher" your commands. I can see they helped the OP. Still I believe good answers should add to the knowledge base this site is, so future users with *similar* problems can find them helpful as well. My comments were in the gist of this premise (which you may not share). In my opinion elaborating common concerns (e.g. "in general there's this issue … but for you it will work because Minecraft …") would boost the quality of the answer. Note no hostile action against the answer was taken. I don't understand why the rollback to revision 1, but so be it. – Kamil Maciorowski Jun 29 '19 at 19:26