Port forwarding and ssh tunnels

Hello everybody,

I have question about ssh tunnels and iptables port forwarding.

Problem is that i cant connect straight to te server because its firewalled and i think i can connect throught ssh tunnel.

Situation is next, i mean i want to do this but i dont know how:
 
Windows XP(192.168.0.100) --> ssh tunnel --> debian & iptables(123.123.123.123 --> server that i want to be connected..(124.124.124.124)

I use putty in windows machine and i have configured to forward port 2287 -> debian machine:2287, is this right?
And the question is, what i have to do with debians firewall, Some masq of forward rules?
I mean i want that the tcp packects goes from windows machine to the server (124.124.124.124) and comes back :)

BR,
Lauri
SkegeAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

fixnixCommented:
"--> server that i want to be connected.."

Connected how?  FTP? HTTP? SMB? SSH? etc.

I'll explain my tunnel here I use to browse through my home debian box from work:

Doze XP running putty, ssh to my home debian box running an http proxy listening on port 8080
Putty is configured to forward port 8080 traffic to 127.0.0.1:8080
My browser uses 127.0.0.1:8080 as it's web proxy.

So what happens is this:
  1.  I ssh to my home debian machine which establishes the tunnel
  2.  My browser is told to use the proxy 127.0.0.1 (local loopback) on port 8080
  3.  Packets sent to 127.0.0.1:8080 are automagically sent down the ssh connection to the debian box
  4.  The debian box "thinks" the packets came from itself (127.0.0.1) on port 8080, which is where the proxy is listening
  5.  Packets get sent to whatever web page my browser requested
  6.  Replies come back to the debian box, which returns them back up the tunnel to the doze box at work.

Basically, you'll need a proxy running on your debian box that can handle whatever protocol you're trying to use to connect to the remote server.

Since the proxy would handle the routing, nothing needs to be done w/ iptables.

In putty, the tunnels would typically be <port number on windows machine> to <127.0.0.1:port number of proxy/port forwarder listening in the debian box> then all traffic destined for the remote server from the Doze machine would be directed to use the proxy on 127.0.0.1 (even though the actual proxy is running on the debian box).

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

Alternatively, you could set up a port forwarder (which is a separate program, they are typically small and easy to install/configure) on the debian box that listens on, say, port 1234 and forwards all traffic on that port to your pre-configured destination (like 124.124.124.124:2287) then your tunnel in putty would be set up as, say, local port 5678, destination 127.0.0.1:1234.  From then on, any time you access 127.0.0.1:5678 that traffic would get routed to 124.124.124.124:2287.
fixnixCommented:
I suppose what you want could be done w/ iptables as well (instead of a port forwarder).....and that might be the cleaner way to do it...let me check on the syntax you'd need
fixnixCommented:
well, after some googling, it seems you cant use iptables to DNAT back to loopback, so unless someone has a better idea, it looks like you'd need a separate port forwarder from what I can tell.

Does the server you're trying to hit at 124.124.124.124 by chance have an sshd?  if so you could just bypass your debian box and tunnel directly to it:
Assuming 124.124.124.124 is listening on port 2287 for the tcp connection you're wanting to use, you ssh to 124.124.124.124 and have the putty tunnels set up as "Source Port 2287" "Destination 127.0.0.1:2287" and then any time you sent packets to 127.0.0.1:2287 they'd shoot down the tunnel to 124.124.124.124:2287
HTML5 and CSS3 Fundamentals

Build a website from the ground up by first learning the fundamentals of HTML5 and CSS3, the two popular programming languages used to present content online. HTML deals with fonts, colors, graphics, and hyperlinks, while CSS describes how HTML elements are to be displayed.

SkegeAuthor Commented:
Thanks for the help :)
And sorry about my bad english..

>Connected how?  FTP? HTTP? SMB? SSH? etc.

It's basicly http stream, but its not "normally" webserver (apache,iis and so on).
Application server which use tcp port 2287.

First problem is that i can't even use putty witout proxy..so everything that is going outside world is trough proxy.

>Does the server you're trying to hit at 124.124.124.124 by chance have an sshd?

Noup.

I figured that if i  open port 1234 from debian and tell putty to make tunnel from windows: 2287>123.123.123.123:1234 and then i make  DNAT rule which tells that every packets that come to port 1234 is forwarded to server 124.124.124.124:2287

Do you think that might work?

Regs,
Lauri
fixnixCommented:
The way I understand tunnels (and the only way I've ever used them) is to have them arrive on 127.0.0.1 on the sshd machine, and from what I understand about iptables, DNAT rules can't have 127.0.0.1 as an endpoint.

I'm no tunnel expert by any means, though (or iptables for that matter haha), so I don't know what would happen setting it up the way you proposed.  I suspect it won't work even though it sounds good (but don't let that stop you from trying it anyway!)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
decoleurCommented:
I do not think this is going to work without being ably to log into a remote device...

for your putty tunnel to work your are going to have to authenticate to a remote device and then your traffic will get redirected through the remote device as a local service.

i would configure a session to have a tunnel that would associate local port 8995 with the ip address and port of a device that is not normally accessible, liek my icecast server at work on 192.168.1.30:9001...

using that config I would ssh into a publicly facing server on the same subnet as the icecast server and then I would direct my browser to http://localhost:8995 which would get tunneled through the ssh connection to the local server to access the remote resource internally...

HTH

-t
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Networking

From novice to tech pro — start learning today.