Tunneling UDP

[BlackSails]

Ive looked online, and I can only find guides for a linux client and linux server. I have a windows client with an ssh tunnel to a linux server. I want to tunnel the connection from a program called teamspeak3 (a voice chat client) through the ssh link.

The problem is that the teamspeak program uses port 9988, and my firewall blocks that. The firewall that the linux computer is behind does not block it. How can I do this?

[Meteorswarm]

I'm not sure how you'd set it up, but in principle you should be able to get this working through your firewall unless teamspeak expects to be able to connect to YOUR computer at 9988. SSH tunneling shoves all the communication over its connection.

Is your firewall a software one on your computer, or something external? It's possible that whatever tool you wind up using to ssh proxy could do it on a lower level than a local firewall, which could then still block ports.

[archeleus]

You can try wrapping the program in another program such as proxychains which will take _all_ of its connections and send them through the SSH tunnel. I don't know if proxychains is available for windows though, you can google it.

[hotaru]

try this: http://www.google.com/search?q=ssh+udp+tunnel

[keeperofdakeys]

You can try wrapping the program in another program such as proxychains which will take _all_ of its connections and send them through the SSH tunnel. I don't know if proxychains is available for windows though, you can google it.

The windows equivalent would be proxifier. I've never used it, but I think I've heard some chatter about it. PuTTY can setup the proxy for your, then proxifier will force all internet traffic to go through this proxy to the remote computer. The equivalent ssh command is "ssh -D 1080", which sets up a socks5 proxy on localhost port 1080.

[BlackSails]

Ive tried all that. SSH doesnt natively support UDP, and neither does proxifier.

[hotaru]

Ive tried all that. SSH doesnt natively support UDP, and neither does proxifier.

try what i suggested. i just did, and it works.

[Carnildo]

Ive tried all that. SSH doesnt natively support UDP, and neither does proxifier.

try what i suggested. i just did, and it works.

Your suggestion is a Google search on UDP tunneling over SSH. Is there a particular search result you had in mind?

[hotaru]

Ive tried all that. SSH doesnt natively support UDP, and neither does proxifier.

try what i suggested. i just did, and it works.

Your suggestion is a Google search on UDP tunneling over SSH. Is there a particular search result you had in mind?

the third, fifth, and sixth results all give basically the same solution, using netcat and a fifo, or using socat. the fourth one gives a different solution, which is probably better if your ssh client and server both support it.

[phlip]

Or, alternatively, you could be less useless and actually give links to said pages, instead of saying things like "the third result" when referring to a list of results that commonly appears in wildly different orders for different people...

[Carnildo]

Ive tried all that. SSH doesnt natively support UDP, and neither does proxifier.

try what i suggested. i just did, and it works.

Your suggestion is a Google search on UDP tunneling over SSH. Is there a particular search result you had in mind?

the third, fifth, and sixth results all give basically the same solution, using netcat and a fifo, or using socat. the fourth one gives a different solution, which is probably better if your ssh client and server both support it.

Are you aware that different people get different results for the same Google search? For example, I get one of

http://superuser.com/questions/53103/udp-traffic-through-ssh-tunnel
http://www.debianadmin.com/howto-perform-udp-tunneling-through-ssh-connection.html
http://www.qcnetwork.com/vince/doc/divers/udp_over_ssh_tunnel.html
http://www.ip-phone-forum.de/showthread.php?t=108316

as the fourth result, depending on my choice of browser and remote proxy. Which one (if any) is your fourth result?

[hotaru]

Or, alternatively, you could be less useless and actually give links to said pages, instead of saying things like "the third result" when referring to a list of results that commonly appears in wildly different orders for different people...

the point is that that there are at least two very simple solutions to this problem in the first page of results on google. posting links to those pages would just perpetuate the widely held misconception that posting on a forum and waiting several hours (or even days) for what any decent search engine can deliver in seconds is a good idea.

[Dthen]

Or you could not be a dick and post the links and then (nicely) mention how much time they would have saved by searching on Google.

[hotaru]

Or you could not be a dick and post the links and then (nicely) mention how much time they would have saved by searching on Google.

i'm the only person so far who posted any working solution to Blacksails's problem. if that's being a dick, what does that make everyone else who has replied to this thread?

[Carnildo]

Or you could not be a dick and post the links and then (nicely) mention how much time they would have saved by searching on Google.

i'm the only person so far who posted any working solution to Blacksails's problem. if that's being a dick, what does that make everyone else who has replied to this thread?

That's the point: you have not posted a solution. You have posted hints that you have found a solution, and then refused to say what that solution is.

[TimeHorse]

First of all, I got here via google, this was the second link. The first link was to someone trying to tunnel an admin server but the link to the actual instructions was also a dead link. So, to put it bluntly, $@^$@^@$%^@$%^@$^% you for not posting links to your oh so precious solution. I did google, that's how I got here so google sucks because it doesn't point to the solution only a bunch of people having the same problem. >roll<

[Red Hal]

Who were you, denvercoder9? What did you see?!

Oh, you saw this: http://www.qcnetwork.com/vince/doc/dive ... unnel.html

More precisely, and less facetiously, you can't get there from here. UDP over SSH is not trivial, and a better solution - if you have access to the remote server - is to use something like openvpn set to use a port that is allowed through the firewall. Depending on the client/server you use, you may also be able to set up a dTLS tunnel in parallel to preserve the low-latency characteristics. This really is the only option unless you want to screw around with Cygwin to get a proper SSH client running on windows, and even then it's by no means guaranteed.