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 <[EMAIL PROTECTED]>
Stonehenge
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
