Proxy Server

Hello,

I have a video streaming application that utilizes a WebSocket for the server <-> client communication. My goal is to make the video streaming service available over the internet in the cases where neither the server nor client have public IPs.

One way to do this is over a VPN connection, but I prefer not to use a VPN at all. That's why I decided to try and forward the communication over an SSH server via remote port forwarding.

However I am facing an issue - forwarding the server socket is pretty straight-forward, but I have no way to know in advance what the randomly allocated client port will be, so the traffic will flow only in the direction client -> SSH server -> streaming server.

When the SSH relay point receives the responses from the streaming server it does not automatically route them back to the client and the WebSocket handshake cannot be completed.

Do you think it is possible to overcome this issue or should I drop the WebSocket altogether and revert to a normal HTTP / TCP connection?

Thanks!

Be more specific please. What, exactly, does the WebSocket try to connect to?

The setup is quite simple actually - there is a WebSocket server and a WebSocket client connecting to it.

My idea is to be able to indirectly access the WebSocket server by forwarding it's listening port to a machine with a real IP address. (in the case when the server is behind a router or firewall and using standard NAT forwarding / routing is not an option - e.g. on two devices accessing the Internet through a mobile data connection)

The problem is that the WebSocket client will always allocate a random port when initializing the communication and the SSH-relay point has no idea how to handle the responses coming from the server on that port.

What makes it even worse is that SSH will open yet another TCP socket (again on a random port) which will be then used to forward the client's request to the actual WebSocket server over the SSH tunnel.
So, if I want to make this work I will have to build a second SSH tunnel from the WebSocket client, in an attempt to bridge the SSH generated client socket to the original one, which makes this a somewhat complicated task...

An SSH tunnel might not be the right tool for the job then, a VPN sounds more suitable. The VPN itself will communicate on a predictable IP and port, but to the applications on either side, can generate traffic that appears to come from another subnet, as if you had two new network cards and a miles-long cable connecting you two directly. Hence 'virtual', 'private', and 'network'.

Yes, I completely agree.

Also, I am well aware of what a VPN is and how it functions, but as I said in my original post I would like to avoid using it. I am trying to achieve a functionality similar to what TeamViewer does, but now it seems that the easiest way to do that would be through a regular TCP socket connection over application-configurable port numbers.

You asked for forwarding when you knew it wouldn't work, and now want teamviewer?

VNC. Though if you can't arrange port forward forward for that you'll need VPN too.

Unfortunately VNC is not an option as most VNC clients use a similar networking mechanic where the client side will open a random port for the outgoing requests, which basically presents the same issue as I have with my solution...

Also, I want to use this on an Android device and grabbing frames from the FrameBuffer in Android (which VNC does) is painfully slow at 4-5 frames per second. The application that I am developing utilizes one of the newer APIs in Android, that allows streaming of the screen content much more effectively (~30 frames per second).

I investigated what TeamViewer does and it seems that they have a server side application that actively forwards the communication between the streaming server (remote controlled device) and client based on unique user IDs.

This is starting to look like my only viable solution as well, although I was hoping that there would be an easier way to achieve the same functionality...

Also, although it'll be a nice clean way to solve the connectivity problem, VPNs are not allowed in some countries. Many mobile operators nowadays have policies that force corporate users to purchase licenses for private APNs, in order to be able to use VPN connections.

I don't know what the exact reason for that is, but it has something to do with their security concerns and maybe even some old-fashioned greed. Some operators have pretty strong firewall rules and may even go as far as to block SSH tunnels (or any other type of encrypted traffic for that matter - although far less common). Exceptions are made only for well known applications like Skype, Hangouts, etc.