Date: Mon, 16 Jan 2012 11:53:26 -0800 From: Freddie Cash <fjwcash@gmail.com> To: Michael Sierchio <kudzu@tenebras.com> Cc: vip 71541 <vip71541@gmail.com>, ipfw@freebsd.org Subject: Re: Problem with passive ftp in IPFW! Message-ID: <CAOjFWZ6gH0A9P1k4j_xkRZTHej1GkfFrPuQYCmGLiH3CxfgpVQ@mail.gmail.com> In-Reply-To: <CAHu1Y73y0CQW97RJ0cTw_Gs=dhuTDnXadd6-uiT8qnGayvii8g@mail.gmail.com> References: <CAFuaoCR5eMktyPc0ZRoOTVvMw1QQd4Z7QDe_YkxgR=wMTPXbTw@mail.gmail.com> <CAOjFWZ7N3kZJgEo3OecAFPKejUAWZdu%2BpcD8MFxttNbLuWUxZA@mail.gmail.com> <CAHu1Y73y0CQW97RJ0cTw_Gs=dhuTDnXadd6-uiT8qnGayvii8g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 16, 2012 at 11:40 AM, Michael Sierchio <kudzu@tenebras.com> wrote: > On Mon, Jan 16, 2012 at 11:05 AM, Freddie Cash <fjwcash@gmail.com> wrote: > >> Personally, I don't use skipto rules, as I find them to just cause >> confusion. ... > > skipto rules are essential in numerous instances, especially once you > start using tableargs, or want to partition your ruleset based on > incoming interface. You deleted the part where I mentioned some situations where they are useful. :) When we started implementing FreeBSD-based firewalls (using FreeBSD 4.0), we used skiptos everywhere. Turned into a giant mess that was very hard to follow and to update. We've since moved away from skipto, and just grouped rules according to server (ex: server1 uses 10000-10999, server2 uses 11000-11999, etc). Works great for us. Some firewalls now have several thousand rules (with tables, but not tablearg), and we're considering using skiptos to optimise the path packets take through the rules. It all depends on how you want to manage things. :) But when first starting out, I find that KISS applies best. Which means skipping the skiptos and tables and other fancy features until you have a working ruleset, and a good understanding on how things work in IPFW. >> Personally, I also don't use stateful filter rules ... > > Perhaps not, but they're useful for outbound connections/dns queries/etc. For TCP connections, you just add the "established" criteria to the rules for the inbound packets. Same result, but easier to manage (IMO/IME; YMMV). For UDP, it may be easier to use keep-state, since there's no "established" analogue for UDP. But, when using divert/natd, keep-state is a pain due to the order that the packets are processed. Things may have improved with libalias-based in-kernel NAT. Don't know, never tried, never investigated it. Only this school year that I've started migrating firewalls from divert/natd to "ipfw nat". And all our rulesets are non-stateful. Of course, everyone's use-cases are different. Hence why I prefaced everything with "personally", to show that it's just my experience/opinion, and not "zomg, this is the only way things must be done!1! I am uber!". :) -- Freddie Cash fjwcash@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOjFWZ6gH0A9P1k4j_xkRZTHej1GkfFrPuQYCmGLiH3CxfgpVQ>