On Tue, 2006-02-28 at 13:53 -0600, Bill Marquette wrote:
On 2/28/06, Adam Gibson <[EMAIL PROTECTED]> wrote:
- static UDP source ports by default. No need to create
special NAT
mappings with pfsense which is cumbersome. This solves
problems hosting
game servers(where the master server uses the source port that it
receives from the game server when listing the game server to
others.
Note that m0n0wall can't support this at all from all the
information I
have found currently because the packet filter in 4.x bsd doesn't
support it. The static-port option was created as a pf feature
in some
version of 5.x bsd and not ipf.
I believe that's incorrect. I'm reasonably confident that IPFilter
can do static mappings on it's NAT.
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.
This just works with iptables for UDP connections through NAT.
With pf
you have to specify an advanced NAT mapping and it applies to TCP
too.
I want TCP to keep a semi-random source address when going
through nat.
To keep from TCP being affected I have to specify a dst IP with
the NAT
mapping so that it only affects connections to that one server. The
advanced NAT mapping is just one more thing to have to configure
with
pf/pfsense.
- 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.
- 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.
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.
