I'm late into this discussion, but I guess I'm glad that ipfilter will continue
in FreeBSD
It has only been since last summer that we've gotten our first production
FreeBSD server. Several of us in the sysadmin team have been behind the
possibility to varying degrees. We had pitched it a
On 19 Apr 2013 10:46, "David Demelier" wrote:
>
> 2013/4/14 Gary Palmer :
> > On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
> >> Is it possible to move ipfilter into a port?
> >
> > That may work short term, but the ENOMAINTAINER problem will quickly
creep
> > up again as kernel AP
On Fri, Apr 19, 2013 at 11:45:57AM +0200, David Demelier wrote:
> 2013/4/14 Gary Palmer :
> > Do we honestly need three packet filters?
>
> No, for me only one should be present. I completely understand that
> some users still use IPFilter and IPFW but why providing three packet
> filters?
>
> Th
2013/4/14 Gary Palmer :
> On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
>> Is it possible to move ipfilter into a port?
>
> That may work short term, but the ENOMAINTAINER problem will quickly creep
> up again as kernel APIs change. If the author has lost interest in
> maintaining
On Mon, 15 Apr 2013 12:15:49 -0700, Cy Schubert
wrote:
> It was pointed out to me that Darren Reed has changed licenses from
> his IP Filter license that's been in IPF since 2005 or so, when he
> joined Sun, to GPLv2 (probably when Darren left when Oracle took over
> Sun). Given that IPF already
On 15.04.2013 19:48, Cy Schubert wrote:
I did consider a port but given it would has to touch bits and pieces of
the source tree (/usr/src), a port would be messy and the decision was made
to work on importing it into base.
Actually it shouldn't touch many if any pieces of src/sys. Everything
In message <20130415212826.ga76...@freebsd.org>, Gleb Smirnoff writes:
> On Mon, Apr 15, 2013 at 04:47:33PM -, c...@sdf.org wrote:
> c> However it would of been better if said person asked me as I already
> c> offered to take it on but whatever.
Sorry, I didn't see your posting. I had a permis
On Mon, Apr 15, 2013 at 01:32:48PM -0600, Scott Long wrote:
S> > Given that IPF already lives in src/contrib and src/sys/contrib, would the
S> > change in License from Darren Reed's own not so BSD friendly IPF license
to
S> > GPLv2 be of concern. I recall there was a lot of concern over IPF's
l
On Mon, Apr 15, 2013 at 04:47:33PM -, c...@sdf.org wrote:
c> However it would of been better if said person asked me as I already
c> offered to take it on but whatever.
More manpower - the better. Why can't you work together?
--
Totus tuus, Glebius.
_
In message <516c58ed.40...@freebsd.org>, Jung-uk Kim writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2013-04-15 15:27:55 -0400, Cy Schubert wrote:
> > In message , Scott
> > Long writes:
> >>
> >> On Apr 15, 2013, at 11:48 AM, Cy Schubert
> >> wrote:
> >>
> >>> In message <18df
It was pointed out to me that Darren Reed has changed licenses from his IP
Filter license that's been in IPF since 2005 or so, when he joined Sun, to
GPLv2 (probably when Darren left when Oracle took over Sun). Given that IPF
already lives in src/contrib and src/sys/contrib due to the 2005 licen
In message <20130415195544.gy76...@freebsd.org>, Gleb Smirnoff writes:
> Cy,
>
> good news that you volunteered to work on this!
>
> On Mon, Apr 15, 2013 at 10:48:43AM -0700, Cy Schubert wrote:
> C> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't
> C> done much with
Cy,
good news that you volunteered to work on this!
On Mon, Apr 15, 2013 at 10:48:43AM -0700, Cy Schubert wrote:
C> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't
C> done much with IPF while employed with Sun. Since then there has been some
C> development that is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-04-15 15:27:55 -0400, Cy Schubert wrote:
> In message , Scott
> Long writes:
>>
>> On Apr 15, 2013, at 11:48 AM, Cy Schubert
>> wrote:
>>
>>> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>,
>>> Rui Paulo writes:
2013/04/15
On Apr 15, 2013, at 1:27 PM, Cy Schubert wrote:
> In message , Scott Long
> writes:
>>
>> On Apr 15, 2013, at 11:48 AM, Cy Schubert wrote:
>>
>>> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo
>>> writes:
2013/04/15 9:55$B!"(BCy Schubert
$B$N%a%C%;!<%
In message , Scott Long
writes:
>
> On Apr 15, 2013, at 11:48 AM, Cy Schubert wrote:
>
> > In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo
> > writes:
> >> 2013/04/15 9:55$B!"(BCy Schubert
> >> $B$N%a%C%;!<%8
> (B:
> >>
> >>> I've been planning on taking on IP Fi
On Apr 15, 2013, at 11:48 AM, Cy Schubert wrote:
> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo
> writes:
>> 2013/04/15 9:55$B!"(BCy Schubert
>> $B$N%a%C%;!<%8(B:
>>
>>> I've been planning on taking on IP Filter for quite some time.
>>> Unfortunately I've left
To my knowledge it is already off by default and you need these options to
enable it
options IPFILTER
options IPFILTER_LOG
so to those that wish to have it removed from base, if it has a maintainer
whats the trouble?
On Mon, Apr 15, 2013 at 2:49 PM, Sam Fourman Jr. wrote:
>
> Thank you to th
The desire to remove it stems from the inability to give it adequate
engineering
service as the network stack evolves. Simply taking it out of a kernel config
file
doesn't address that problem at all. If it's going to stay in FreeBSD at all,
it
needs to be maintained. This could be set about
Thank you to those that have expressed interest in maintaining IP Filter..
My thoughts are, could we consider putting a option in the kernel config,
and leaving it off by default for GENERIC?
I think this is a acceptable compromise, considering some people wish for
it to be removed.
Sam Fourman J
In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo
writes:
> 2013/04/15 9:55$B!"(BCy Schubert
> $B$N%a%C%;!<%8(B:
>
> > I've been planning on taking on IP Filter for quite some time.
> > Unfortunately I've left my src commit bit lapse (my ports commit bit is
> > alive
ACER WMI/ACPI? Sure, i'll mentor you if you're going to do _that_.
Adrian
On 15 April 2013 09:55, Cy Schubert wrote:
> I've been planning on taking on IP Filter for quite some time.
> Unfortunately I've left my src commit bit lapse (my ports commit bit is
> alive and well though) thus I'm look
2013/04/15 9:55、Cy Schubert のメッセージ:
> I've been planning on taking on IP Filter for quite some time.
> Unfortunately I've left my src commit bit lapse (my ports commit bit is
> alive and well though) thus I'm looking for a mentor. In addition I'm
> working on an ACER WMI/ACPI kld. One mentor w
I've been planning on taking on IP Filter for quite some time.
Unfortunately I've left my src commit bit lapse (my ports commit bit is
alive and well though) thus I'm looking for a mentor. In addition I'm
working on an ACER WMI/ACPI kld. One mentor would be preferred but two
would be fine too.
However it would of been better if said person asked me as I already
offered to take it on but whatever.
> In message , Warren Block
> writ
> es:
>> On Sun, 14 Apr 2013, Chris Rees wrote:
>>
>> > On 14 April 2013 01:41, Rui Paulo wrote:
>> >> 2013/04/13 16:01?Scott Long ??:
>> >>
>> >>> May
Ok, seems someone has taken the job.
> In message , Warren Block
> writ
> es:
>> On Sun, 14 Apr 2013, Chris Rees wrote:
>>
>> > On 14 April 2013 01:41, Rui Paulo wrote:
>> >> 2013/04/13 16:01?Scott Long ??:
>> >>
>> >>> Maybe something else, but whatever it is, it should be done. If you
>>
In message , Warren Block
writ
es:
> On Sun, 14 Apr 2013, Chris Rees wrote:
>
> > On 14 April 2013 01:41, Rui Paulo wrote:
> >> 2013/04/13 16:01?Scott Long ??:
> >>
> >>> Maybe something else, but whatever it is, it should be done. If you and
> Gleb don't want to do this, I will.
> >>
> >
On Monday April 15 2013 12:32:37 Lev Serebryakov wrote:
> And, yes, NAT64 will be useful for sure, but it is another story,
> not IPv6<->IPv6 translation.
Fear not, NPT66 prefix translation is stateless,
this is nothing like NAT44 / NAPT.
On Monday April 15 2013 12:51:00 sth...@nethelp.no wrote:
On Mon, Apr 15, 2013 at 1:54 PM, Kimmo Paasiala wrote:
> On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov wrote:
>> Hello, Kimmo.
>> You wrote 15 апреля 2013 г., 14:47:24:
>>
>> KP> I'm however talking about an ftp client behind a very restrictive
>> KP> firewall making an IPv6 connection an ftp
> >> MM> ... and as far as I can tell none of them is currently usable
> >> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard),
> >> MM> none of them supports stateful NAT64, nor IPv6 prefix translation :(
> >> IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will
> >
On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov wrote:
> Hello, Kimmo.
> You wrote 15 апреля 2013 г., 14:47:24:
>
> KP> I'm however talking about an ftp client behind a very restrictive
> KP> firewall making an IPv6 connection an ftp server that uses passive
> KP> mode data ports that can't be kn
Hello, Kimmo.
You wrote 15 апреля 2013 г., 14:47:24:
KP> I'm however talking about an ftp client behind a very restrictive
KP> firewall making an IPv6 connection an ftp server that uses passive
KP> mode data ports that can't be known in advance.
Same solution -- inspection of connections to 21 p
On Mon, Apr 15, 2013 at 1:44 PM, Lev Serebryakov wrote:
> Hello, Kimmo.
> You wrote 15 апреля 2013 г., 14:36:27:
>
>>> And, yes, NAT64 will be useful for sure, but it is another story,
>>> not IPv6<->IPv6 translation.
> KP> You're forgetting set ups where outgoing traffic is controlled by
> KP> f
Hello, Kimmo.
You wrote 15 апреля 2013 г., 14:36:27:
>> And, yes, NAT64 will be useful for sure, but it is another story,
>> not IPv6<->IPv6 translation.
KP> You're forgetting set ups where outgoing traffic is controlled by
KP> filter rules, outgoing passive mode ftp needs help from the proxy to
On Mon, Apr 15, 2013 at 1:32 PM, Lev Serebryakov wrote:
> Hello, Kimmo.
> You wrote 15 апреля 2013 г., 14:26:40:
>
>>> MM> ... and as far as I can tell none of them is currently usable
>>> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard),
>>> MM> none of them supports stateful NA
Hello, Kimmo.
You wrote 15 апреля 2013 г., 14:26:40:
>> MM> ... and as far as I can tell none of them is currently usable
>> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard),
>> MM> none of them supports stateful NAT64, nor IPv6 prefix translation :(
>> IPv6 prefix translation?!
On Mon, Apr 15, 2013 at 1:15 PM, Lev Serebryakov wrote:
> Hello, Mark.
> You wrote 15 апреля 2013 г., 2:25:07:
>
>>> Yes! This is the most clever thought in this thread. Why we need 3
>>> firewalls? Two packet filters it's excess too. We have two packet filters:
>>> one with excellent syntax and f
Hello, Mark.
You wrote 15 апреля 2013 г., 2:25:07:
>> Yes! This is the most clever thought in this thread. Why we need 3
>> firewalls? Two packet filters it's excess too. We have two packet filters:
>> one with excellent syntax and functionality but with outdated bandwidth
>> control mechanism (ak
On Sun, Apr 14, 2013 at 07:55:21PM +0100, Joe Holden wrote:
> wishmaster wrote:
>
> > --- Original message ---
> > From: "Gary Palmer"
> > Date: 14 April 2013, 19:06:59
> >
> >
> >> On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
> >>> Is it possible to move ipfilter into a port
On Apr 14, 2013, at 5:25 PM, Mark Martinec wrote:
> ... and as far as I can tell none of them is currently usable
> on an IPv6-only FreeBSD (like protecting a host with sshguard),
> none of them supports stateful NAT64, nor IPv6 prefix translation :(
pfSense 2.1 has a lot of work to make this h
On Sunday April 14 2013 19:30:22 wishmaster wrote:
> > Do we honestly need three packet filters?
> Yes! This is the most clever thought in this thread. Why we need 3
> firewalls? Two packet filters it's excess too. We have two packet filters:
> one with excellent syntax and functionality but with o
On 2013/04/14, at 12:11, Anton Shterenlikht wrote:
> A migration *guide*, yes. Tools to convert one syntax to another: no.
>
> ok, so what is the brief migraiton advice?
It's still being written.
> The Handbook mentions PF and IPFW.
> I gather from your mails that PF is the recommended c
I agree with this, we dont need 3 packet filters, it seems like we should
focus the people interested in working on packet filters,toward the packet
filter most actively maintained, the fact that there is 3 in base is
overkill, Just depreciate it and be done with it
a new email, asking for help
A migration *guide*, yes. Tools to convert one syntax to another: no.
ok, so what is the brief migraiton advice?
The Handbook mentions PF and IPFW.
I gather from your mails that PF is the recommended choice.
Is that so?
If I choose PF, can I just follow the
Handbook PF section, and once i
wishmaster wrote:
--- Original message ---
From: "Gary Palmer"
Date: 14 April 2013, 19:06:59
On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
Is it possible to move ipfilter into a port?
That may work short term, but the ENOMAINTAINER problem will quickly creep
up again as k
Odhiambo Washington writes:
> 2. PF is being felt to be part of FreeBSD, but it too lags far behind
> OpenBSD implementation - almost like it's unmaintained. There has been
> debates about this which were never concluded. Most of you will agree with
> me on this.
FreeBSD's version of pf is active
--- Original message ---
From: "Gary Palmer"
Date: 14 April 2013, 19:06:59
> On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
> > Is it possible to move ipfilter into a port?
>
> That may work short term, but the ENOMAINTAINER problem will quickly creep
> up again as kernel API
Hi,
I will see what I can do when I come back from work. PF is based on
ipfilter so having 3 is indeed a bit much.
Chris
> On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
>> Is it possible to move ipfilter into a port?
>
> That may work short term, but the ENOMAINTAINER problem wil
On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
> Is it possible to move ipfilter into a port?
That may work short term, but the ENOMAINTAINER problem will quickly creep
up again as kernel APIs change. If the author has lost interest in
maintaining the FreeBSD port of ipfilter then
On 14 April 2013 16:48, Warren Block wrote:
> On Sun, 14 Apr 2013, Chris Rees wrote:
>
>> On 14 April 2013 01:41, Rui Paulo wrote:
>>>
>>> 2013/04/13 16:01?Scott Long ??:
>>>
>>>
Maybe something else, but whatever it is, it should be done. If you and
Gleb don't want to do this, I
It's NOT possible, because someone has to handle the kernel hooks, which is
the contention.
Mark as deprecated, remove the HandBook section, but only for 10.x
On 14 April 2013 18:48, Warren Block wrote:
> On Sun, 14 Apr 2013, Chris Rees wrote:
>
> On 14 April 2013 01:41, Rui Paulo wrote:
>>
On Sun, 14 Apr 2013, Chris Rees wrote:
On 14 April 2013 01:41, Rui Paulo wrote:
2013/04/13 16:01?Scott Long ??:
Maybe something else, but whatever it is, it should be done. If you and Gleb
don't want to do this, I will.
I already started writing a guide. See here for a very incomple
I do not stand in any good stead to comment on this, but I have used
IPFilter more extensively than PF when it comes to FreeBSD and packet
manipulations. As a user, what I can say is this:
1. The only firewall that seems 'native' to FreeBSD is ipfw and I believe
it works very well for some users w
On Apr 14, 2013, at 7:20 AM, Joe wrote:
> Rui Paulo wrote:
>> On 2013/04/12, at 22:31, Scott Long wrote:
>>> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
>>>
On 2013/04/11, at 13:18, Gleb Smirnoff wrote:
> Lack of maintainer in a near future would lead to bitrot due to change
Rui Paulo wrote:
On 2013/04/12, at 22:31, Scott Long wrote:
On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
On 2013/04/11, at 13:18, Gleb Smirnoff wrote:
Lack of maintainer in a near future would lead to bitrot due to changes
in other areas of network stack, kernel APIs, etc. This already
Rui Paulo wrote:
> 2013/04/13 16:01、Scott Long のメッセージ:
>
>> Maybe something else, but whatever it is, it should be done. If you and
>> Gleb don't want to do this, I will.
>
> I already started writing a guide. See here for a very incomplete version:
>
> http://people.freebsd.org/~rpaulo/ipf-d
On 14 April 2013 01:41, Rui Paulo wrote:
> 2013/04/13 16:01、Scott Long のメッセージ:
>
>> Maybe something else, but whatever it is, it should be done. If you and
>> Gleb don't want to do this, I will.
>
> I already started writing a guide. See here for a very incomplete version:
>
> http://people.fre
2013/04/13 16:01、Scott Long のメッセージ:
> Maybe something else, but whatever it is, it should be done. If you and Gleb
> don't want to do this, I will.
I already started writing a guide. See here for a very incomplete version:
http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html
___
On Apr 13, 2013, at 11:43 AM, Rui Paulo wrote:
> On 2013/04/13, at 5:03, Scott Long wrote:
>> You target audience for this isn't people who track CURRENT, it's people who
>> are on 7, 8, or 9 and looking to update to 10.x sometime in the future.
>
> Yes, I'm aware of that, but the problem re
On 2013/04/13, at 5:03, Scott Long wrote:
> You target audience for this isn't people who track CURRENT, it's people who
> are on 7, 8, or 9 and looking to update to 10.x sometime in the future.
Yes, I'm aware of that, but the problem remains. If ipfilter is broken or gets
broken because of the
Scott,
On Fri, Apr 12, 2013 at 11:31:09PM -0600, Scott Long wrote:
S> One thing that FreeBSD is bad about (and this really applies to many open
source projects) when deprecating something is that the developer and release
engineering groups rarely provide adequate, if any, tools to help users
On Sat, Apr 13, 2013 at 3:03 PM, Scott Long wrote:
>
> On Apr 13, 2013, at 12:33 AM, Rui Paulo wrote:
>
>> On 2013/04/12, at 22:31, Scott Long wrote:
>>
>>> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
>>>
On 2013/04/11, at 13:18, Gleb Smirnoff wrote:
> Lack of maintainer in a n
On Apr 13, 2013, at 12:33 AM, Rui Paulo wrote:
> On 2013/04/12, at 22:31, Scott Long wrote:
>
>> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
>>
>>> On 2013/04/11, at 13:18, Gleb Smirnoff wrote:
>>>
Lack of maintainer in a near future would lead to bitrot due to changes
in other
On 2013/04/12, at 22:31, Scott Long wrote:
> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
>
>> On 2013/04/11, at 13:18, Gleb Smirnoff wrote:
>>
>>> Lack of maintainer in a near future would lead to bitrot due to changes
>>> in other areas of network stack, kernel APIs, etc. This already happ
On Fri, Apr 12, 2013 at 11:31:09PM -0600, Scott Long wrote:
>
> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
>
> > On 2013/04/11, at 13:18, Gleb Smirnoff wrote:
> >
> >> Lack of maintainer in a near future would lead to bitrot due to changes
> >> in other areas of network stack, kernel APIs,
On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
> On 2013/04/11, at 13:18, Gleb Smirnoff wrote:
>
>> Lack of maintainer in a near future would lead to bitrot due to changes
>> in other areas of network stack, kernel APIs, etc. This already happens,
>> many changes during 10.0-CURRENT cycle were
On 2013/04/11, at 13:18, Gleb Smirnoff wrote:
> Lack of maintainer in a near future would lead to bitrot due to changes
> in other areas of network stack, kernel APIs, etc. This already happens,
> many changes during 10.0-CURRENT cycle were only compile tested wrt
> ipfilter. If we fail to find m
Hello,
here is brief status on ipfilter(4) packet filtering facility,
written by Darren Reed, that is shipped with FreeBSD kernel.
o The version of the software is v4.1.28. The license is BSD, .. erm
the license is very close to BSD, but with some additions, most
notable is:
> The licen
68 matches
Mail list logo
