Date: Fri, 11 Jan 2008 15:15:05 +0100 From: Michal Varga <varga.michal@gmail.com> To: Rodrique Heron <swygue@rodhouse.org> Cc: freebsd-pf@freebsd.org Subject: Re: Forwarding another host Message-ID: <1200060905.36543.106.camel@xenon> In-Reply-To: <1a5f1a2d0801110518i398793a9u84a4c8924f62bcde@mail.gmail.com> References: <4784F7E3.3060508@rodhouse.org> <1199919114.59461.10.camel@xenon> <1a5f1a2d0801100501j664f6b81sebe866b986a05500@mail.gmail.com> <1199977668.36543.12.camel@xenon> <1a5f1a2d0801100910r1316d24dibb2b12720dfda207@mail.gmail.com> <1200009515.36543.27.camel@xenon> <1a5f1a2d0801101837r338b5453m7a8f673e3b03833e@mail.gmail.com> <1200021436.36543.40.camel@xenon> <1a5f1a2d0801110518i398793a9u84a4c8924f62bcde@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@gmail.com>
Stonehenge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1200060905.36543.106.camel>