UDP Port Forwarding/Tunneling [SOLVED]

[naeg]

Explanation of the solution:
If you're inside a network with a firewall that blocks pretty much all (UDP) ports and you can't play PlaneShift, this solution could help you. Port 80 TCP most likely is open, because it's HTTP. The idea is to forward the packets to a remote_server outside that network with that firewall and let it create the connection to the PlaneShift server.

Game running on localhost has PlaneShift Server with ip=127.0.0.1 port=7777

localhost listens on udp :7777 and forwards this to tcp remote_server:80 (HTTP)

remote_server listens on tcp :80 and forwards to udp 209.59.234.149:7777

First of all, you have to install zebedee on your localhost and the remote_server: http://www.winton.org.uk/zebedee/index.html

On your localhost go to the PlaneShift directory and add a server with ip=127.0.0.1 port=7777 to data/servers.xml.

After installing zebedee on localhost and remote_host you launch zebedee on the remote_server like this:

Code: [Select]

zebedee -U -T 80 -s 209.59.234.149:7777
And on the localhost:

Code: [Select]

zebedee -U 7777:remote_server:7777 -T 80
Now start PlaneShift, select the server with 127.0.0.1:7777 and enjoy!

The original post:
Hello,

let me come straight to my problem:

I'm inside a network with a firewall that blocks pretty much all (UDP) ports, but port 80 on tcp is open because this is HTTP. My idea was to forward the packets using netcat to a remote server, which again forwards those packets to the PlaneShift server. Localhost and remote_server are both running linux. The setup is as follows:

Game running on localhost has PlaneShift Server with ip=127.0.0.1 port=7777

localhost listens on udp :7777 and forwards this to tcp remote_server:80 (HTTP)

remote_server listens on tcp :80 and forwards to udp 209.59.234.149:7777

What I actually execute on my localhost, before starting PlaneShift and trying to connect to server with ip=127.0.0.1 port=7777:

Code: [Select]

ssh remote_server 'mkfifo /tmp/planepipe &> /dev/null; nc -lvvp 80 0</tmp/planepipe | nc -u 209.59.234.149 7777 1>/tmp/planepipe &'

mkfifo /tmp/planepipe &> /dev/null
nc -ulvvp 7777 0</tmp/planepipe | nc remote_host 80 1>/tmp/planepipe &

All the netcats are running, no permission problems or things like that.

On my localhost I get the following output from netcat when trying to connect to the server with PlaneShift:

Code: [Select]

Listening on any address 7777 (cbt)
Received packet from 127.0.0.1:49186 -> 127.0.0.1:7777 (local)
Looks like it is from PlaneShift, because when I don't try to connect to the server it doesn't output anything.

On the remote_server I get this from netcat:

Code: [Select]

listening on [any] 80 ...
connect to [remote_server] from my_localhost_name [my_localhost_ip] 60393

PlaneShift actually lets me trying to connect, seeing the ping of the server, but after some time a window pops up saying "The server is not running or is not reachable. Please check the website or forums for more info". The netcat pipe actually has to work, because without it PlaneShift doesn't even let my try to connect nor do I see the latency.
Is it possible that PlaneShift uses another port for connecting or after connecting?

Any help is appreciated - also completly new ideas, which would allow me to play PlaneShift inside a network with a firewall that blocks pretty all UDP traffic.


Greetings, naeg

EDIT0: added my localhost' ip address + a name to the /etc/hosts on my remote_server. Output before doing this on remote_server netcat:

Code: [Select]

listening on [any] 80 ...
my_localhost_ip: inverse host lookup failed: Unknown host
connect to [remote_server] from (UNKNOWN) [my_localhost_ip] 20543

EDIT1: changed the IP address in the PlaneShift data/servers.xml to the inside IP address of my localhost, instead of 127.0.0.1 - same behaviour, still getting that message box. Only the output from netcat on the localhost changes:

Code: [Select]

Listening on any address 7777 (cbt)
Received packet from <inside_ip_address_localhost>:53566 -> <inside_ip_address_localhost>:7777 (local)
EDIT2: It seems like I used different implementations of netcat on the localhost and the remote_host. On the localhost I used gnu netcat, and on the remote_host debian's netcat-traditional. Installed openbsd-netcat on both machines, which resulted in no packet loss, but still the message box when trying to connect. Same for gnu netcat on both machines.

EDIT3: Due to netcat most likely not being able to correctly forward the UDP packets for PlaneShift, I searched for other solutions. I found this udptunnel software: http://www.cs.columbia.edu/~lennox/udptunnel/
On the remote_server:

Code: [Select]

# udptunnel -vv -s 80 209.59.234.149/7777
Listening for TCP connections on port 80
TCP connection from <my_localhost_ip>/65139
Received packet on TCP, length 23; sending as UDP
Received packet on TCP, length 18; sending as UDP
Received packet on TCP, length 18; sending as UDP
...
On the localhost:

Code: [Select]

# udptunnel -vv -c <remote_host_ip>/80 127.0.0.1/7777
Connected TCP to <remote_host_ip>/80
Received 23 byte UDP packet from 127.0.0.1/53038
Received 23 byte UDP packet from 127.0.0.1/53038
Received 18 byte UDP packet from 127.0.0.1/53038
...But I can't even see the latency when selecting the server, just the text "Failed". Trying to connect just results into the "The server is not available!"-message.

EDIT4: SOLVED! See http://www.hydlaaplaza.com/smf/index.php?topic=40724.msg457115#msg457115
Hope this helps. Regards - naeg

[Sen]

Nice! I used exactly this setup several years ago to play planeshift. Unfortunately, I forgot about all of it again after the "Whee, it works"

The first thing I'd check is, that all involved IPs are resolvable (DNS reverse lookup) on the local and remote host. For example, if your remote_host has IP 26.234.65.3, a 'nslookup 26.234.65.3' should return a name.
I got this idea from 'my_localhost_ip: inverse host lookup failed: Unknown host'

[naeg]

Hi Sen

Thanks for you reply.
I added the ip address and a name to the /etc/hosts file of my remote_server and that message about "inverse host lookup failed" disappeared. Nothing more changed tough, still see the latency while being able to try to connect, but not to establish a connection (same window with message "The server is not running or is not reachable. Please check the website or forums for more info").

(As you probably noticed I'm logging everything I change, so this solution can be put into a wiki or something as soon as it's working )

[BoevenF]

What happens if you specify the ip address of your eth0 instead of loopback address as planeshift server?

[naeg]

Hi BeovenF,

nice idea, but sadly it didn't help much. It results in the same behaviour: I'm seeing the latency, but trying to connect just yields that message box. The only thing that changes is the output from netcat on the localhost - inside ip address instead of 127.0.0.1.

I just realized that when selecting a server there is some percentage next to the latency (latency is about 200 btw). This percentage is right after launching the client at about 20% and goes down to about 5%. What does this percentage mean? Someone on the IRC channel thought it could be packet loss.

EDIT: Talked to weltall on IRC. Bad news, this seems not going to work. He also tried this setup and the netcat seems to damage the udp packages somehow (that's why the packet loss is there). I'm searching for other solutions and when I can't come up with one, I'll have to use a VPN.

[naeg]

Solved!

Instead of netcat, which seems to damage the udp packets, I used zebedee: http://www.winton.org.uk/zebedee/index.html

In PlaneShift data/servers.xml I have a server with ip=127.0.0.1 port=7777.

After installing zebedee on localhost and remote_host I launched zebedee on the remote_server like this:

Code: [Select]

zebedee -U -T 80 -s 209.59.234.149:7777
And on the localhost:

Code: [Select]

zebedee -U 7777:remote_server:7777 -T 80
I'm not sure whether it's 100% correct like this, will check that later in order to achieve more security. But for now I'll play PlaneShift

[BoevenF]

Interesting, quick and dirty. 

[Sen]

Very interesting! And I'm surprised that netcat has such problems. Maybe you can report about your experience with this tunnel; e.g. frequent interruptions, lag etc.

[naeg]

This tunnel works nicely for me. Even though the network I'm in is used by a lot of people and the download rate is very low (20-100 KB/s), the game runs fluently and without any big lags or interruptions. But I didn't play too long up to now, will update the original post as soon as I have more experiences.