From owner-freebsd-pf@FreeBSD.ORG Thu May 27 14:02:29 2010 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 377AA106579D for ; Thu, 27 May 2010 14:02:29 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (core.vx.sk [188.40.32.143]) by mx1.freebsd.org (Postfix) with ESMTP id 6E4498FC08 for ; Thu, 27 May 2010 14:02:28 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 813A6B49FC; Thu, 27 May 2010 16:02:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3CzEzQ1htHW3; Thu, 27 May 2010 16:02:25 +0200 (CEST) Received: from [127.0.0.1] (chello089173000055.chello.sk [89.173.0.55]) by mail.vx.sk (Postfix) with ESMTPSA id 22C86B49F5; Thu, 27 May 2010 16:02:25 +0200 (CEST) Message-ID: <4BFE7B74.4050709@FreeBSD.org> Date: Thu, 27 May 2010 16:02:28 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Max Laier References: <4BFE5A26.8030301@FreeBSD.org> <201005271534.27006.max@love2party.net> In-Reply-To: <201005271534.27006.max@love2party.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 8bit Cc: freebsd-pf@freebsd.org Subject: Re: Base import proposal: relayd 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: Thu, 27 May 2010 14:02:29 -0000 Well, what relayd actually provides is level 3 and level 7 reverse proxy (with transparency support) and a load-balancer. We could say that this can be seen as a "frontend to pf", but also as a level 7 reverse proxy like varnish or pound. I have experience with all of these. The configuration file syntax matches pf.conf(5). People with pf(4) skills can take a benefit of it, for me it was the daemon I was searching for a long time. Why putting it in base? We could provide an out-of-the box load-blancing solution with service availability checking. This is indeed very useful when FreeBSD is used as a (load-balancing) firewall. In addition, the code is quite small and easy to integrate. On the other hand, the current port (dating december 2007) is in a very buggy state and I do not recommend using it, as it might easily confuse your pf. The bugs are major, e.g. not cleaning pf rules/tables/anchors on exit or segfault on reloading a mistyped configuration file. As an alternative I would like to maintain the port, I am already trying to get in touch with Jun Kuriyama. Cheers, mm Dňa 27. 5. 2010 15:34, Max Laier wrote / napísal(a): > Hello Martin, > > On Thursday 27 May 2010 13:40:22 Martin Matuska wrote: > >> Comments and suggestions are welcome. >> > first off, thank you for your interest in pf - more hands are greatly > appreciated! > > On the $subj, I'm not sure what the added benefit of relayd in base is. > Having it in ports makes it easier to pull in new features/releases. The same > could be said for (t)ftp-proxy, but it was decided that ftp NAT support is a > *basic* function of any firewall and therefore should be in the base system. > > Can you share your reasons for wanting it in base as opposed to ports? > > On the nitpicking side of things - from a quick glance: The build of > relayd/ctl should probably be conditional on WITHOUT_PF. > > Thanks, > Max >