Forwarding another host

[Michal Varga]

On Fri, 2008-01-11 at 08:18 -0500, Rodrique Heron wrote:

>         Ok, so if I understand this correctly, you are trying to
>         redirect 
>         incoming connections from the internet through HOSTA to HOSTB.
>         The
>         problem I see is that you don't translate your packets on the
>         way back,
>         so something like this happens (we will call the INTERNET/PIX
>         as
>         HOST-X):
>         
>         1. HOST-X sends ssh request to HOST-A
>         
>         2. HOST-A redirects the request to HOST-B
>         
>         3. HOST-B sees that there is a request to ssh from HOST-X
>         (remember, the
>         packet was redirected, not translated to look as if it
>         originated from 
>         HOST-A)
>         
>         4. So HOST-B opens the ssh connection and sends a reply to
>         HOST-X - I'm
>         ready.
>         
>         5. HOST-X now sees that HOST-B is replying with "here is your
>         ssh", but
>         HOST-X contacted HOST-A in the first place, no HOST-B, so it
>         discards 
>         this connection, he doesn't know why some HOST-B is sending
>         him
>         anything.
>         
>         
>         It's 4.15 AM here so I hope I didn't get the scenario wrong,
>         but if this
>         is the case, I think your problem is obvious..
> 
> Yep! I understand perfectly, now is there anything I can do on the pix
> side to allow the traffic back to HOST-A ?
> 
> Thanks
>  
On the PIX side probably nothing, it's the HOST-B that decides who to
reply. But there is a number of solutions. For example, if you will ever
care only for one or two (or just a few) ports to forward, I'd go for
"redir" (port net/redir) solution. Attach it on HOST-A, let it redirect
(actually, what it does is really a TCP proxy) traffic to HOST-B, create
a rc/cron script to check and restart the service in case it crashes,
and forget.

But for a much cleaner infrastructure, I'd personally put HOST-B
somewhere behind the HOST-A. If HOST-A already acts as the intermediate
points between your business clients (HOST-X) and ssh server (HOST-B),
you probably do not want them (or will not want to let them at some
point in time) to be able to directly access HOST-B from HOST-X. So I'd
put HOST-B physically behind HOST-A, this way you can redirect traffic
to HOST-B as you're trying to do now, set HOST-A as HOST-B's gateway and
let HOST-A NAT the HOST-B's traffic out. Then the flow will be:

[HOST-X] <--> SWITCH <--> iface1[HOST-A]iface2 <--> SWITCH
                                                       |--> [HOST-B]
                                                       |--> [HOST-C..]
                                                       +--> [HOST-D..]

1. HOST-X contacts HOST-A for ssh.
2. HOST-A redirects (PF rdr) packet to HOST-B.
3. HOST-B gets the packet and sends a reply to HOST-X, but:
4. HOST-A (PF nat) is a gateway for HOST-B, so HOST-B sends the packet there
5. NAT on HOST-A translates the packet, now the packet looks like it came from HOST-A and continues to HOST-X
6. HOST-X gets the packet, it contacted HOST-A for ssh, the ssh reply came from HOST-A, everything is ok, connection estabilished.

This also has some additional benefits that later if you decide, you can
use HOST-A for better security, internal network partitioning (everyting
from the internet will talk to HOST-A and it will decide who to contact
on the local network, etc.), you can use HOST-A for traffic shaping, and
many other things.

Of course there are other alternatives, you can use HOST-A as a gateway
even if you don't move HOST-B and leave them both in the same switch, as
they are now. The only major point is that if HOST-X contacts HOST-A for
ssh, it doesn't care what will HOST-A do with that packet and where it
sends it, but it will always expect reply originating from HOST-A. So
you can't let HOST-B to reply directly. It must send its reply back
through HOST-A and HOST-A must rewrite the packet originator, so HOST-X
sees it is talking to ssh on HOST-A.

m.

> 
-- 
Michal Varga <varga.michal at gmail.com>
Stonehenge