Tunneling UDP over SSH

[DrLex]

It's hard to find a suitable forum for this question, but I suppose this should be one of the more appropriate ones. Mind that this is probably a pretty 'advanced' question ;)

I have this situation: a game server (Enemy Territory) is running inside an isolated network which only has a few access points to the outside world by means of SSH. Someone outside this network wants to play on this game server. If the game would be using TCP for network connections, it would be quite simple: setting up an SSH tunnel should do the trick. However, like most FPS games, ET uses UDP, on port 27960. SSH does not allow tunneling UDP traffic.
However, there are ways to convert (or 'bridge') UDP traffic to TCP traffic and vice versa. For instance, "netcat" on Linux/UNIX can do this. So I tried the following.

'client' is the computer outside the protected network.
'intermediate' is the computer inside the network, which allows SSH access from outside.
'server' is the computer inside the network, on which the ET server runs.
In short, I set up an UDP->TCP bridge on 'client', tunnel the TCP traffic through an SSH tunnel to 'intermediate', where it's converted back to UDP and sent to 'server'.

In more detail: the first thing I do is setting up an SSH tunnel from client to intermediate, on some arbitrary TCP port:

ssh -L 5901:127.0.0.1:5901 intermediate

Next, I set up a TCP->UDP bridge on intermediate, which directs the UDP traffic to server:

netcat -u -L server:27960 -t -p 5901

Finally, I set up an UDP->TCP bridge on client:

netcat -t -L 127.0.0.1:5901 -u -p 27960

So now I would theoretically just need to start ET on the client an connect to 127.0.0.1. However, this doesn't work, it keeps waiting for a connection. Yet, if I connect to UDP port 27960 on the client with netcat, I can talk to the ET server, so the UDP tunnel seems to be working. Does anyone have any idea why it doesn't work with ET itself?

[sashi]

It's hard to find a suitable forum for this question, but I suppose this should be one of the more appropriate ones. Mind that this is probably a pretty 'advanced' question ;)

I have this situation: a game server (Enemy Territory) is running inside an isolated network which only has a few access points to the outside world by means of SSH. Someone outside this network wants to play on this game server. If the game would be using TCP for network connections, it would be quite simple: setting up an SSH tunnel should do the trick. However, like most FPS games, ET uses UDP, on port 27960. SSH does not allow tunneling UDP traffic.
However, there are ways to convert (or 'bridge') UDP traffic to TCP traffic and vice versa. For instance, "netcat" on Linux/UNIX can do this. So I tried the following.

'client' is the computer outside the protected network.
'intermediate' is the computer inside the network, which allows SSH access from outside.
'server' is the computer inside the network, on which the ET server runs.
In short, I set up an UDP->TCP bridge on 'client', tunnel the TCP traffic through an SSH tunnel to 'intermediate', where it's converted back to UDP and sent to 'server'.

In more detail: the first thing I do is setting up an SSH tunnel from client to intermediate, on some arbitrary TCP port:

ssh -L 5901:127.0.0.1:5901 intermediate

Next, I set up a TCP->UDP bridge on intermediate, which directs the UDP traffic to server:

netcat -u -L server:27960 -t -p 5901

Finally, I set up an UDP->TCP bridge on client:

netcat -t -L 127.0.0.1:5901 -u -p 27960

So now I would theoretically just need to start ET on the client an connect to 127.0.0.1. However, this doesn't work, it keeps waiting for a connection. Yet, if I connect to UDP port 27960 on the client with netcat, I can talk to the ET server, so the UDP tunnel seems to be working. Does anyone have any idea why it doesn't work with ET itself?

Hi there,

I don't think you'll be able to connect to <127.0.0.1> as it's the localhost IP address. Am sure you know that <127.0.0.1> doesn't accept any external connection, replace <127.0.0.1> with your external IP address, hope it works. Good luck & Take care.

[DrLex]

Maybe it was't entirely clear, but in this experiment I'm running ET on the same machine as where the UDP traffic is tunneled to. So the local netcat forwards the packets to 127.0.0.1 and I connect with ET to 127.0.0.1. Of course, if someone else would want to use the tunnel, they should connect to my public IP.

After verifying everything, I actually managed to connect to the server, but the game stays stuck at "Awaiting gamestate". I have no idea why, because in theory it should work. The verbose mode of netcat and tcpdump show lots of traffic when connecting, but it suddenly stops. Maybe netcat can't handle some type of packet that's required for the game. Ah well, it was worth a try.

[bdaddy]

That's pretty clever. I don't know anything about the ET UDP protocol, but based on experience with other UDP protocols, I can see at least one potential problem with this strategy. When you bridge a stream of UDP messages to a TCP stream, you will lose the boundaries between UDP messages. So usually UDP protocols implement well-defined messages that will fit into a single UDP packet. If you shove a bunch of small UDP packets through your solution, it may end up showing up on the other side as a single large UDP packet. And and the reciever might not be expecting this, or ready to handle it. You might even end up with a UDP packet getting split as a result of this setup.

What you really need to do is have a client-server protocol on the TCP<->TCP part of your bridge that will package up each UDP packet into a super packet that can be sent out seperately after going through the TCP tunnel.

You could use tcpdump to debug this to see if this kind of corruption is occuring. Even without knowing the specific details of the ET UDP protocol, you could take a network dump of a successful UDP connection, a network dump on each side of your TCP tunnel, and perform a differential analysis between the two. The kind of thing you would want to look for is packet size so see if they are getting corrupted after going through your TCP tunnel.

Hope that helps,