From owner-freebsd-questions@FreeBSD.ORG Thu Feb 10 00:54:43 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E25D106564A for ; Thu, 10 Feb 2011 00:54:43 +0000 (UTC) (envelope-from max@mxcrypt.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id DA5FE8FC17 for ; Thu, 10 Feb 2011 00:54:42 +0000 (UTC) Received: by vxa40 with SMTP id 40so402466vxa.13 for ; Wed, 09 Feb 2011 16:54:42 -0800 (PST) Received: by 10.220.81.5 with SMTP id v5mr5654171vck.74.1297299280189; Wed, 09 Feb 2011 16:54:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.77.85 with HTTP; Wed, 9 Feb 2011 16:54:09 -0800 (PST) In-Reply-To: <4D5333E4.7070800@herveybayaustralia.com.au> References: <4D515148.3000009@herveybayaustralia.com.au> <20110208151849.GC3267@catflap.slightlystrange.org> <4D51CD05.8040003@herveybayaustralia.com.au> <20110209111646.GD3267@catflap.slightlystrange.org> <4D527BAC.3080805@herveybayaustralia.com.au> <4D5333E4.7070800@herveybayaustralia.com.au> From: Maxim Khitrov Date: Wed, 9 Feb 2011 19:54:09 -0500 Message-ID: To: Da Rock Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-questions@freebsd.org Subject: Re: pf, binat, rdr, and one ip X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 00:54:43 -0000 On Wed, Feb 9, 2011 at 7:40 PM, Da Rock wrote: > On 02/09/11 22:38, Maxim Khitrov wrote: >> >> On Wed, Feb 9, 2011 at 6:34 AM, Da Rock >> =C2=A0wrote: >> >>> >>> On 02/09/11 21:16, Daniel Bye wrote: >>> >>>> >>>> On Wed, Feb 09, 2011 at 09:08:53AM +1000, Da Rock wrote: >>>> >>>> >>>>> >>>>> On 02/09/11 01:18, Daniel Bye wrote: >>>>> >>>>> >>>>>> >>>>>> On Wed, Feb 09, 2011 at 12:20:56AM +1000, Da Rock wrote: >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> A very quick question. >>>>>>> >>>>>>> PF firewall. One static public IP. About 6 servers on the internal >>>>>>> network (dmz). One server binat in the pf.conf, the rest redirected= . >>>>>>> >>>>>>> Possible? Or would it die in the hole? >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I guess you're concerned about performance and resource usage? If so= , >>>>>> this >>>>>> may be helpful. >>>>>> >>>>>> http://www.openbsd.org/faq/pf/perf.html >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> >>>>> >>>>> Useful info to have, thanks. But no, I'm interested in if the binatti= ng >>>>> will interfere with the rdr's (or vice versa). >>>>> >>>>> >>>> >>>> Ah, I see. I don't know, is the straight answer - I've never needed to >>>> use >>>> both together. A bit of idle googling seems to suggest it's possible, >>>> but >>>> I don't have time right now to dig any deeper. >>>> >>>> >>> >>> Thats exactly what I got too. Nothing definitive to go on. Apparently n= ot >>> a >>> very common arrangement. It *seems* to be working, but there are some >>> weird >>> quirks I can't quite account for. Hence the question to the guys who'd >>> know... :) >>> >> >> According to pf.conf(5): >> >> =C2=A0 =C2=A0 =C2=A0Evaluation order of the translation rules is depende= nt on the type of >> the >> =C2=A0 =C2=A0 =C2=A0translation rules and of the direction of a packet. = =C2=A0binat rules are >> =C2=A0 =C2=A0 =C2=A0always evaluated first. =C2=A0Then either the rdr ru= les are evaluated on >> an >> =C2=A0 =C2=A0 =C2=A0inbound packet or the nat rules on an outbound packe= t. =C2=A0Rules of the >> same >> =C2=A0 =C2=A0 =C2=A0type are evaluated in the same order in which they a= ppear in the >> ruleset. >> =C2=A0 =C2=A0 =C2=A0The first matching rule decides what action is taken= . >> >> The way I interpret this is that when an outside client tries to >> establish a connection to one of your servers, the rdr rules will >> never be evaluated, since the only public IP is translated with binat. >> Outgoing connections shouldn't have a problem, since binat will only >> match one local IP address and the others can be translated with nat >> rules. >> > > Allow me to prefix my comments with the fact that that is not what appear= s > to be happening. > > I read that as well, but my reading between the lines was that it is the > _rules_ that are evaluated. So if I have a block all policy and then open= up > what I need, then only the _ports_ specified for that binat machine are > passed- the rest continue for further evaluation: the rdr rules are then > assessed and the packets are passed accordingly. > > What I see works mostly; I have a binat machine for voip (asterisk), and = the > rest of the jumble gets passed to the rdr's or get blocked. However, wher= e I > come unstuck (and this is why I recreated my firewall rules) is I still > can't get outgoing calls to my voip provider. It still eludes me... So I'= m > not sure if I'm 100% right or not. > > Hence my dilemma... I did get outgoing calls to work somewhere when my > firewall rules were still not quite working, but I couldn't ring in! I ha= ve > used an ata and tried to figure out what I'm missing, but I still haven't > got it figured yet. > > But I digress. At the time when I started this thread I was having some o= dd > issues with my rdr servers, but now they appear to be working as they sho= uld > (after some blood sweat and tears), fingers crossed. So what I will do no= w > is finish this problem and get the voip working (which may or may not be = a > firewall problem), and then see whether it all works as beautifully as it > should; then I will report back on this thread and let people know the > outcome. > Are you using binat specifically for voip or is there some other reason? I used to run a voip appliance behind m0n0wall (FreeBSD 6) using regular nat and port forwarding without any problems. I'm not familiar with asterisk, but I assume there is a way to restrict the port range that is used for incoming and outgoing connections. Binat shouldn't be needed for this if that's your only reason for going that route. - Max