Re: [pfSense-discussion] licience of php interface ?

[Nick Buraglio]

Isn't a lot of this substantially lower layer feature?  A lot (not  
the static udp stuff) of what you're wanting is pf level development  
work.  That said, last time I had looked at the pf list (which was a  
whiile ago) they were not interested in adding a lot of "goo" into  
pf, but instead keeping it as thin and clean as they could.  Adding  
things like mac filtering, l7 filtering, timing functions are not  
pf's core competency and, in my opinion, are better handled by  
userland code.  Jumbling a lot of extra features into the filtering  
system is a very easy way to make it hard to debug and cumbersome to  
configure.   Like I said, just my opinion.

nb



On Feb 28, 2006, at 4:23 PM, Adam Gibson wrote:

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.