On 2/28/06, Adam Gibson <[EMAIL PROTECTED]> wrote:
>
> Just to be sure we are on the same page. I am referring to static port
> mappings. Not static IP NAT mappings. I am pretty sure most
> firewalling filters can do static IP mappings through NAT (1 to 1, etc).
> Basically just making sure that the src port stays the same during the
> NAT traversal.
>
> Where 10.10.10.10 is LAN client behind firewall NAT
> Where 12.1.1.1 is some internet server
> Where Firewall WAN has ip 69.1.1.1
>
> src 10.10.10.10:1000 dst 12.1.1.1:20000
> |
> firewall with IP 69.1.1.1
> |
> src 69.1.1.1:1000 dst 12.1.1.1:20000
>
> The static-port feature only exists in pf from 5.x versions of freebsd.
> I am very confident you wont find that feature in ipfilter on freebsd.
> I looked for an equivalent feature and it just wasn't there.
IPFilter does this by default. To quote the man page:
For map rules, the destination address will be one for which the tuple
combining the new source and destination is known to be unique. If the
packet is either a TCP or UDP packet, the destination and source ports
come into the equation too. If the tuple already exists, IP Filter
will increment the port number first, within the available range speci-
fied with portmap and if there exists no unique tuple, the source
address will be incremented within the specified netmask. If a unique
tuple cannot be determined, then the packet will not be translated.
And the BNF syntax:
map ::= mapit ifname ipmask "->" dstipmask [ mapport ] mapoptions.
map ::= mapit ifname fromto "->" dstipmask [ mapport ] mapoptions.
.
.
.
mapport ::= "portmap" tcpudp portspec .
portmap is not a require parameter.
Also, the ipf howto (dated Dec 11, 2002) on obfuscation.org also
claims this to be default IPFilter behaviour.
http://www.obfuscation.org/ipf/ipf-howto.html#TOC_29
pf can also do it, we could generate the rules to do it by default.
We don't. FWIW, in FreeBSD pf has only been in tree since 5.3, you
won't find it available on m0n0 which is IPFilter based. I can't
speak any more towards m0n0's usage of IPFilter as I don't use m0n0,
never have, never will - nor have I ever seen m0n0's code outside of
what we've imported into our tree (which no longer includes the
IPFilter code).
> > > - Time rules without needing scripts or cron jobs.
> >
> > Yeah, that's never going to happen in PF, nor should it. Cron was
> > designed to schedule jobs to run, it can do a perfectly adequate job,
> > we just need to write the code.
>
> opinions are just that... everyone has one. So you would rather have a
> cron script inject and remove rules than have the filter code take care
> of it? This just works in iptables and works well.
Yes, I would. I don't see the need to make the kernel code more
complex. Stateful inspection code is already complex enough without
contaminating it with time management code that doesn't belong there.
Userland can handle this just fine and should.
> > > - conntrack(nat) modules for irc, amanda, netbiosns, and many other
> > > modules to make protocols work or work better by default without needing
> > > helper applications to get them working behind NAT.
> > The NAT modules just aren't there yet as nobody with the skill and
> > desire has written them. I agree that it's a pain, but I personally
> > find the linux filtering engines to be a pain to work with too.
> >
>
> Hince wanting to use iptables. It has more features that I personal
> need. As far as being a pain, I would disagree. Everyone has their
> opinions and so there is no right or wrong here. As long as we are both
> happy :). That is what choice is all about with Linux, *bsd, etc. It's
> all free and all good. Just have to choose what works for you.
>
> > > - Ability to pick from a bunch of extra features in patch-o-matic for
> > > even more nat modules and such.
> >
> > sounds scary
> >
>
> Not as long as you don't grab alpha quality modules :). Being in
> control of picking them makes the difference.
>
> > > - different logging features. Ability to put a text description in
> > > syslog logging messages for firewall rules.
> >
> > Hrm, that may actually already be doable, we just don't expose it.
> > I've got better ideas along these lines anyway.
> >
>
> Again... this just works the way I want with iptables hince wanting to
> use it for my firewalling needs.
>
> > > - Ability to push accept/drop/reject decisions to userspace using ipq.
> > > Imagine a firewall that blocks everything by default and then when you
> > > run the firewall administration web page, any new connections will be
> > > displayed and allow the user to accept or deny it so that the user can
> > > automatically generate rules based on that information. I mainly use
> > > this for creating zonealarm type functionality on Linux currently where
> > > a gui X windows comes up asking the user to allow are reject any
> > > incoming or outgoing connections.
> >
> > There are good reasons to not do that. With that said, it's trivial
> > to do if anyone wants to write the code - I can give plenty of
> > direction on what needs to be done. What you describe can easily be
> > done with tcpdump and a wrapper on it (or a "create rule" button on
> > the denies log page along with a deny further connections button on
> > the states display page). What I just described I'll actually put on
> > my "if you wanted to be a pfSense dev and dunno what to work on" wiki
> > page, it's something I'd consider an "easy" task for someone
> > interested.
> >
>
> For rule generation I agree that just looking at the logs would be
> doable. Bad example I guess. The benefit of ipq is that the actual
> packets have the choice to be denied or allowed while in transit from
> userspace. The packet that is matched by the rule is stopped inside
> iptables and awaits a deny,pass,reject, etc answer from userspace
> instead of having a static rule. I have not found any way to push rule
> pass/deny to userspace in freebsd firewalling. With ipf or pf you can
> only know if it passes or was denied after the fact. The feature is just
> not there for creating that part of a host based firewall like
> zonealarm, etc it seems. Pfsense is not a host based firewall though so
> it doesn't apply anyway.
There are numerous ways to do this. I won't elaborate as all of them
require coding.
> Opinions aside. My intent was to get access to his code because for my
> purposes I would rather use iptables because it has the features that I
> need without needing a bunch of helper code to get some things working
> or not having an equivalent feature. Not to mention it would be easier
> for me to work on it.
Fair enough. Bringing up iptables on this list however, is just
asking for the conversation that just happened. I'd love to know what
our interface has that the half million gui's for iptables don't have
though, I really don't understand the desire to port it.
--Bill
