Date: Fri, 31 Oct 2008 12:35:30 -0400 From: Lowell Gilbert <freebsd-questions-local@be-well.ilk.org> To: Jeremy Chadwick <koitsu@FreeBSD.org> Cc: Jack Barnett <jackbarnett@gmail.com>, Freebsd questions <freebsd-questions@freebsd.org>, mdh_lists@yahoo.com Subject: Re: Firewalls in FreeBSD? Message-ID: <444p2sd8od.fsf@be-well.ilk.org> In-Reply-To: <20081031160949.GA36045@icarus.home.lan> (Jeremy Chadwick's message of "Fri\, 31 Oct 2008 09\:09\:49 -0700") References: <367168.61424.qm@web56806.mail.re3.yahoo.com> <490A4487.8020101@gmail.com> <20081030233933.GB16747@icarus.home.lan> <448ws4da2f.fsf@be-well.ilk.org> <20081031160949.GA36045@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeremy Chadwick <koitsu@FreeBSD.org> writes: > On Fri, Oct 31, 2008 at 12:05:28PM -0400, Lowell Gilbert wrote: >> Jeremy Chadwick <koitsu@FreeBSD.org> writes: >> >> > On Thu, Oct 30, 2008 at 06:34:31PM -0500, Jack Barnett wrote: >> >> >> >> Ok, I had some progress with this last night. Basically what I do is: >> >> >> >> in natd - redirect_port 1000 to 10000 to the internal windows box. >> >> set ipfw to "open" file wall. >> >> >> >> Obviously this isn't prefect - but gives some idea of what's going on. >> >> >> >> What I'd like to do, is a) keep the nat redirects since that works >> >> pretty well. >> >> b) in ipfw, ONLY allow data back on these ports IF the windows box has >> >> established the connection out first then deny everything else. >> > >> > This is called "port triggering" in the residential router world. I >> > don't know how to do this on FreeBSD. >> >> Stateful rules are the only way to do it. >> In fact, this is the main purpose of stateful rules. > > Read this part of the thread, where I outline protocol flow (based on > what the OP has stated about the protocol, which so far appears to be > accurate): > > http://lists.freebsd.org/pipermail/freebsd-questions/2008-October/thread.html > > Stateful rules will not solve this problem. > > The OP wants a feature that tells ipfw or pf "after the TCP handshake > has completed, dynamically add a port forward for port X on interface Y > to machine A on port Z; when the TCP session is FIN'd cleanly, or > extinguishes, dynamically remove that port forward". Okay, I guess I'm a little confused by the line about "ONLY allow data back on these ports IF the windows box has established the connection out first then deny everything else." I read that as saying that the Windows box had sent a packet on the same connection (4-tuple, at least) that should be later accepted heading *to* the Windows box. That's just a stateful rule, and it seems to be at odds with what you wrote in your first message in the thread. The apparent disagreement was why I said anything in the first place; it sounds like there's more than one model of how the game works. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?444p2sd8od.fsf>