Suppose you are running on your laptop (box A) some Java code in your
browser that talks to a remote server (box B). All is fine until you find
yourself in a hotel that blocks the relevant ports (say, 8100-8120). OK,
at least SSH is not blocked and you do have an account on a more open
remote box (C) - so a trivial, but not very elegant, solution is to run
the browser on C and "fetch" the display with VNC through an SSH tunnel.
From a bandwidth / responsiveness point of view, however, this is a total
overkill. All you have is a trickle of data (mouse clicks and keystrokes),
why bloat it with graphics.

Is there some networking solution that can help? I tried tunneling through
SSH (SSH port forwarding) but it did not help - as I could not redirect the
A->B connection request. On top of that, even if I managed to make the incoming
connection to the server seem to come from C, upon connection the server will
directly ask the Java client for its IP number and use that to open a
separate direct B->A channel. To me it looks like the only solution would
be to make the code on A think that the local IP is that of C, and map
all A->B requests (now C->B requests) to go through C.

If anyone knows a fix, or has some ideas, please let me know - either here
or at mc2718@gmail.com.

------------------


P.S: the only strategy I see at the moment is to run an "outpost" (proxy,
if you wish) on C and modify the local Java VM on A to direct networking
through that one. By modifying an open source VM code this is doable, but
looks like a LOT of work. A dirty alternative is to hack the Linux kernel
to map ethernet connections to/from certain IPs to go through some fixed
local ports. Does not look very appealing either...

Install an OpenVPN server on "C" and connect through it to the server.

Many thanks for the quick reply. Since OpenVPN costs money, I must ask one more thing before playing with it. Will "connecting through it" imply that ALL internet traffic, whether generated by the browser or any other code that happens to be running on my box, will have to go through the VPN? Or is using the VPN a per application option?

In any case, thanks to your post I learned that the relevant keyword is NAT, which would solve the entire problem except the issue of server reliance on the local IP reported by the client.

Let me post a partial solution here since others might find it useful. This redirects traffic to the remote server through an SSH tunnel through an open remote computer.

In the example below, we want to connect to the server server.company.us at port 8500, which is however blocked by the local firewall. To circumvent this, we direct all traffic going to port 8500 on server.company.us through a local SSH tunnel on port 8123. The tunnel is between the local box and a remote open computer (computer.far.away) where we have an account (username "user").

-----

i) In the iptable config file add section

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# redirect traffic to local port
-A OUTPUT -p tcp -d server.company.us -m multiport --dports 8500 -j REDIRECT --to-ports 8123
COMMIT


ii) restart iptables


iii) open SSH tunnel via

ssh -L 8123:server.company.us:8500 user@computer.far.away


This works, as long as all communication with the server goes through the same socket through which we initiate the connection (i.e., the usual listen/connect stuff).