From owner-freebsd-pf@FreeBSD.ORG Fri Jan 11 14:15:09 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A65F16A421 for ; Fri, 11 Jan 2008 14:15:09 +0000 (UTC) (envelope-from varga.michal@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id C07CF13C442 for ; Fri, 11 Jan 2008 14:15:08 +0000 (UTC) (envelope-from varga.michal@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so1207713fgg.35 for ; Fri, 11 Jan 2008 06:15:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:organization:date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=BaTt4EIBmXYzSByHycU7J7rLphEv5gzZwpLXGJ18Brk=; b=tkb+XRX8A8R5upqo3GTRGkycwA977p4yJj9111jCHDGYk9Jj973SiJVJiAgdqjfCIi8owJSfVr/CrZFGMcuniohwknZq53ODkSBo1Tszo3skQujWdQDtzuq5Vl25lebidqN1z5s8RXI/gKCdIFvO2lS1Wc5N5xgt3LoFT4LgV4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:organization:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=bWPB7yVKQ/73vPEk4T6Wi1Tty2Zq9rFviuYcLUp6TV9W77IC1vbSyuBNcbHcBXzCFOXkw/q/gIHIZGJ0VQWQpHLt5znVfqzM712AVJl5X8MDgeLDf2VO4CwPqD1eWW0Ee0Zp7DVZBBNPdnckXhx+cCz+Vl3b7d1Ivncz8oJBiFU= Received: by 10.86.4.2 with SMTP id 2mr3004650fgd.43.1200060907699; Fri, 11 Jan 2008 06:15:07 -0800 (PST) Received: from ?10.0.100.2? ( [89.176.79.57]) by mx.google.com with ESMTPS id e20sm3176808fga.1.2008.01.11.06.15.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 11 Jan 2008 06:15:06 -0800 (PST) From: Michal Varga To: Rodrique Heron 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> Content-Type: text/plain Organization: Stonehenge Date: Fri, 11 Jan 2008 15:15:05 +0100 Message-Id: <1200060905.36543.106.camel@xenon> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: Forwarding another host X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 14:15:09 -0000 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 Stonehenge