IPF Why does IPF still exist?

[RetroComputingCollector]

When I see people taking about firewalls, they mainly seem to discuss PF and IPFW. I use IPFW and it seems to work fine, and I get why people like PF, but IPF is seldom mentioned, and when they do, people generally find a nice way to say that it is either crap, or worth forgetting about. Why does it suck and if it is so obsolete and useless, then why is it still in base‽

 

[cy@]

Let me ask you. Why do you think it's crap?

 

[RetroComputingCollector]

People just generally say to forget it or that it's on life support. I've never used it so I would assume that it's not the most useful at least. I don't know much about the other firewalls as I started off using IPFW and I have stayed with it because I have no reason to change.

Let me ask you. Why do you think it's crap?

 

[cy@]

First of all it's not on life support. I've taken over maintaining it for not only FreeBSD but sending patches to NetBSD and Illumos have expressed interest that I update their codebase.

People say this because they haven't used it. It's like people tell me FreeBSD is not secure because it's not that BSD or this Linux

Darren stopped working on it when he left the employ of Sun Microsystems. That was when Oracle purchased Sun.

As to performance, IPF and PF perform better than IPFW when NAT is involved. Packets cross kernel userspace barrier and back again through NAT. IPFW NAT is inefficient. In that regard PF and IPFILTER are of similar design.

PF was written by OpenBSD because Theo and Darren had a falling out. Theo ripped IPFILTER out of OpenBSD, writing his own, PF, over the space of a week.

IPFILTER's pools (hashes and tables) are more advanced than PF's. Though PF has gained that capability recently. I don't think it's nearly as useful yet.

As to how IPFILTER an PF operate, both are similar -- remember Theo wrote PF to replace IPFILTER after the dispute.

I've been using IPFILTER for close to 30 years. Initially on Solaris and now on FreeBSD. It does the job quite nicely and IMO I prefer using it over Checkpoint (firewall appliances for enterprises). I chose IPFILTER back in the day because it a) was less cumbersome than IPFW -- there was no PF then -- b) IPFW didn't support NAT (and it still doesn't except you need a userspace daemon), and c) back in the day IPFW rules were shell comands so your rules files were shell scripts. This is not a thing anymore but it was at the time.

As to why people use PF over anything else. I can offer an opionion. My opinion is people believe it's more secure than IPFILTER and IPFW because it comes from OpenBSD. IMO this is subjective.

I've done quite a bit to work out some of the niggling issues in IPFILTER. I've put IPFILTER work on pause for now as I work to import MIT KRB5 to replace Heimdal in base. There are a number of changes in yet to be completed git branches waiting for me to get back at them.

It's as solid as the other two packet filters in FreeBSD. All three are certainly easier to use than iptabes or netfilter in Linux.

Oh and BTW, BSD is dying. I've heard this at $JOB. I guess it must be.

 

[RetroComputingCollector]

When I see people taking about firewalls, they mainly seem to discuss PF and IPFW. I use IPFW and it seems to work fine, and I get why people like PF, but IPF is seldom mentioned, and when they do, people generally find a nice way to say that it is either crap, or worth forgetting about. Why does it suck and if it is so obsolete and useless, then why is it still in base‽

First of all it's not on life support. I've taken over maintaining it for not only FreeBSD but sending patches to NetBSD and Illumos have expressed interest that I update their codebase.

People say this because they haven't used it. It's like people tell me FreeBSD is not secure because it's not that BSD or this Linux

Darren stopped working on it when he left the employ of Sun Microsystems. That was when Oracle purchased Sun.

As to performance, IPF and PF perform better than IPFW when NAT is involved. Packets cross kernel userspace barrier and back again through NAT. IPFW NAT is inefficient. In that regard PF and IPFILTER are of similar design.

PF was written by OpenBSD because Theo and Darren had a falling out. Theo ripped IPFILTER out of NetBSD, writing his own, PF, over the space of a week.

IPFILTER's pools (hashes and tables) are more advanced than PF's. Though PF has gained that capability recently. I don't think it's nearly as useful yet.

As to how IPFILTER an PF operate, both are similar -- remember Theo wrote PF to replace IPFILTER after the dispute.

I've been using IPFILTER for close to 30 years. Initially on Solaris and now on FreeBSD. It does the job quite nicely and IMO I prefer using it over Checkpoint (firewall appliances for enterprises). I chose IPFILTER back in the day because it a) was less cumbersome than IPFW -- there was no PF then -- b) IPFW didn't support NAT (and it still doesn't except you need a userspace daemon), and c) back in the day IPFW rules were shell comands so your rules files were shell scripts. This is not a thing anymore but it was at the time.

As to why people use PF over anything else. I can offer an opionion. My opinion is people believe it's more secure than IPFILTER and IPFW because it comes from OpenBSD. IMO this is subjective.

I've done quite a bit to work out some of the niggling issues in IPFILTER. I've put IPFILTER work on pause for now as I work to import MIT KRB5 to replace Heimdal in base. There are a number of changes in yet to be completed git branches waiting for me to get back at them.

It's as solid as the other two packet filters in FreeBSD. All three are certainly easier to use than iptabes or netfilter in Linux.

Oh and BTW, BSD is dying. I've heard this at $JOB. I guess it must be.

Wow, maybe I should try it out! It would be useful to know all three firewalls and if it's faster in some cases then it's definitely worth learning!

I do absolutely hate the BSD is dying crap. It is so patently untrue, (who has ZFS huh) and just feels like a Linux user's way of coping with their lack of Jails and other great features. Never seen a package update or uninstallation break a FreeBSD system, but it definitely can break Linux!

 

[JohnK]

Fascinating! Thank you for that, cy@,

 

[cy@]

Wow, maybe I shoukd try it out! It would be useful to know all three firewalls and if it's faster in some cases then it's definitely worth learning!

I do absolutely hate the BSD is dying crap. It is so patently untrue, (whu has ZFS huh) and just feels like a Linux user's way of coping with their lack of Jails and other great features. Never seen a package update or uninstallation break a FreeBSD system, but it definitely can break Linux!

They don't have jails. They have something comparable. Cgroups and namespaces, the Linux kernel constructs used to implement containers work differently to attempt to implement what we have with jails. Unfortunately splitting of namespaces (a container's visibility of the host) and cgroups (think of this as permissions) IMO is inferior to jails. However what namespaces and cgroups do provide is the API to run Linux containers, which has become a defacto standard.

Package uninstalls on Red Hat Linux have yet to break RHEL. And I work on 1400 Red Hat Linux servers at $JOB. The few Debian based Linux at $JOB have been trouble, as you have noted. Which distro have you had problems with?

 

[RetroComputingCollector]

Mostly Debian-based stuff (Ubuntu)* which I agree with you is rather problematic. If I was't turned away from Linux by the lack of cohesion, among other nitpicks, I never would have found FreeBSD! Even though Linus's bullshit about ZFS is hard to listen to, at least it means that Linux will never have a good OpenZFS implementation, which is another thing that (in my opinon) is great at converting people to the Church of FreeBSD!

*Seriously, why does ANYONE use Ubuntu? It is just the Windows of Linux and just seems to have so many beyter alternatives! If I need to run Linux software, I just use Linuxulator with emulators/linux-rl9 so I can run RHEL without actually having to leave FreeBSD!

 

[audioeric]

First of all it's not on life support. I've taken over maintaining it for not only FreeBSD but sending patches to NetBSD and Illumos have expressed interest that I update their codebase.

People say this because they haven't used it. It's like people tell me FreeBSD is not secure because it's not that BSD or this Linux

Darren stopped working on it when he left the employ of Sun Microsystems. That was when Oracle purchased Sun.

As to performance, IPF and PF perform better than IPFW when NAT is involved. Packets cross kernel userspace barrier and back again through NAT. IPFW NAT is inefficient. In that regard PF and IPFILTER are of similar design.

PF was written by OpenBSD because Theo and Darren had a falling out. Theo ripped IPFILTER out of NetBSD, writing his own, PF, over the space of a week.

IPFILTER's pools (hashes and tables) are more advanced than PF's. Though PF has gained that capability recently. I don't think it's nearly as useful yet.

As to how IPFILTER an PF operate, both are similar -- remember Theo wrote PF to replace IPFILTER after the dispute.

I've been using IPFILTER for close to 30 years. Initially on Solaris and now on FreeBSD. It does the job quite nicely and IMO I prefer using it over Checkpoint (firewall appliances for enterprises). I chose IPFILTER back in the day because it a) was less cumbersome than IPFW -- there was no PF then -- b) IPFW didn't support NAT (and it still doesn't except you need a userspace daemon), and c) back in the day IPFW rules were shell comands so your rules files were shell scripts. This is not a thing anymore but it was at the time.

As to why people use PF over anything else. I can offer an opionion. My opinion is people believe it's more secure than IPFILTER and IPFW because it comes from OpenBSD. IMO this is subjective.

I've done quite a bit to work out some of the niggling issues in IPFILTER. I've put IPFILTER work on pause for now as I work to import MIT KRB5 to replace Heimdal in base. There are a number of changes in yet to be completed git branches waiting for me to get back at them.

It's as solid as the other two packet filters in FreeBSD. All three are certainly easier to use than iptabes or netfilter in Linux.

Oh and BTW, BSD is dying. I've heard this at $JOB. I guess it must be.

interesting. would you recommend i try out IPF for my laptop setup? that's one thing I haven't done is set up a personal firewall yet.

 

[covacat]

ipfw has in kernel nat since a while
and kernel libalias

 

[VladiBG]

last time when i check libalias doesn't have an option to show the list of the dynamic translations it only show a total count of them and the syntax of separating ingress and egress traffic in order to use dynamic states in IPFW + in-kernal nat is awful. The only clean way is to use nat with deny_in and rely on the dynamic nat translations.

 

[teo]

I have never understood firewalls and their rules, they seem like a head breaker to me. I wonder why there is no graphical firewall like gufw...

In the image below you can see how nice is that firewall that with a click is activated and its basic rules, and you don't spend hours and hours trying to configure it without understanding anything, and the worst if you don't understand it time lost for the user that tries to test the BSD world.

 

[RetroComputingCollector]

Something like that would be nice, especially if it lets you configure the firewall, change rules, and view logs, all in one place! A firewall GUI is rather low in my list though as I still am constantly opening the terminal a million times a day, even when I am in X.

 

[SirDice]

I have never understood firewalls and their rules, they seem like a head breaker to me.

To be able to configure a firewall you first have to know a bit more about TCP/IP in general. Know how packets are sent and received. Once you know those details configuring a firewall is actually fairly straightforward. But lots of people attempt to configure a firewall without knowing even the most basic TCP/IP principles.

 

[RetroComputingCollector]

To be able to configure a firewall you first have to know a bit more about TCP/IP in general. Know how packets are sent and received. Once you know those details configuring a firewall is actually fairly straightforward. But lots of people attempt to configure a firewall without knowing even the most basic TCP/IP principles.

Yeah, maybe someone should add basic TCP/IP man pages or something in the handbook, so you can actually tell someone to read the manual and be able to provide a specific man page without coming off as a "look somewhere, I dunno where, just look" type of jerk!

 

[teo]

... as I still am constantly opening the terminal a million times a day, even when I am in X.

It is for the scandal that you are opening the terminal a million times a day ....
Personally, just looking at the screen for a while makes my eyes tired, my eyes are stressed, my eyes get red, and tears start to come out of my eyes, my physical body gets tired, it's overwhelming. I prefer to spend some time and not an eternity looking at the horrible glare emanating from the screen. For that you need graphical applications and not to spend an eternity in the terminal with settings or stupid commands.

 

[diizzy]

First of all it's not on life support. I've taken over maintaining it for not only FreeBSD but sending patches to NetBSD and Illumos have expressed interest that I update their codebase.

I think it depends on the definition of "life support". To my knowledge there's no active upstream or joint development as in improving it in terms of performance or enhancements. Unless I'm looking that wrong directory over at NetBSD that seems to reflect on my personal observations of where ipf(ilter) development is today. Looking at bsdrp.net ipfw(2) performance in general seems to be ipfw(2) > pf > ipf(ilter) however that may be a different story on your system and workload. ipf(ilter) is also to my knowledge still single threaded compared to all other options and is one of the major reasons why pf and/or npf as were imported/written including a more modern codebase.

Reference:

History for external/bsd/ipf - NetBSD/src

Automatic conversion of the NetBSD src CVS module, use with care. Please submit bugs/changes via https://gnats.netbsd.org - History for external/bsd/ipf - NetBSD/src

github.com

https://www.netbsd.org/~rmind/pub/npf_presentation_netbsd_6.pdf

 

[gotnull]

I have never understood firewalls and their rules, they seem like a head breaker to me. I wonder why there is no graphical firewall like gufw...

In the image below you can see how nice is that firewall that with a click is activated and its basic rules, and you don't spend hours and hours trying to configure it without understanding anything, and the worst if you don't understand it time lost for the user that tries to test the BSD world.

View attachment 21863

I've never tried it but here there is a solution for you:

GitHub - bsdlme/ipfwGUI: A very simple ipfwGUI for FreeBSD

A very simple ipfwGUI for FreeBSD. Contribute to bsdlme/ipfwGUI development by creating an account on GitHub.

github.com

 

[RetroComputingCollector]

I don't like to install software outside of the ports tree because of updating and dependencies. But someone (maybe me) could port it!

 

[cy@]

I think it depends on the definition of "life support". To my knowledge there's no active upstream or joint development as in improving it in terms of performance or enhancements. Unless I'm looking that wrong directory over at NetBSD that seems to reflect on my personal observations of where ipf(ilter) development is today. Looking at bsdrp.net ipfw(2) performance in general seems to be ipfw(2) > pf > ipf(ilter) however that may be a different story on your system and workload. ipf(ilter) is also to my knowledge still single threaded compared to all other options and is one of the major reasons why pf and/or npf as were imported/written including a more modern codebase.

It is multi-threaded and has been for quite a few years.

pf was written by OpenBSD due to a licensing dispute with Darren Reed. IPF is BSD licensed for *BSD systems and GPL for non-BSD systems. But when the license was first changed (when he became a Sun employee) OpenBSD didn't ask questions. They simply replaced it with a rewrite.

We will not import any updated PF from OpenBSD. The OpenBSD version of PF is single threaded. FreeBSD has put in a lot of work to make PF multi-threaded. We cannot and will not undo that work by importing an updated PF from OpenBSD. FreeBSD is upstream for our PF. This was made abundantly clear in the mailing lists.

Reference:

History for external/bsd/ipf - NetBSD/src

Automatic conversion of the NetBSD src CVS module, use with care. Please submit bugs/changes via https://gnats.netbsd.org - History for external/bsd/ipf - NetBSD/src

github.com

https://www.netbsd.org/~rmind/pub/npf_presentation_netbsd_6.pdf

That is in my queue.

 

[cy@]

To be able to configure a firewall you first have to know a bit more about TCP/IP in general. Know how packets are sent and received. Once you know those details configuring a firewall is actually fairly straightforward. But lots of people attempt to configure a firewall without knowing even the most basic TCP/IP principles.

I know too many firewall admins who have no understanding of TCP/IP beyond IP addresses and ports. Lucky for them Checkpoint has canned objects one can apply. Linux has implemented this same paradigm with netfilter. Just pick an object (rule) from a pick list and apply it. This lowers the bar for who can manage a firewall. But creating one's own rules from scratch becomes a little more onerous.

 

[RetroComputingCollector]

Wow! Yet another reason to not use OpenBSD besides no kernel modules and no Nvidia support!

 

[cy@]

I've never tried it but here there is a solution for you:

GitHub - bsdlme/ipfwGUI: A very simple ipfwGUI for FreeBSD

A very simple ipfwGUI for FreeBSD. Contribute to bsdlme/ipfwGUI development by creating an account on GitHub.

github.com

This looks like the Linux netfilter interface or the Checkpoint interface. It's designed for firewall admins who have no concept of TCP/IP beyond IP addresses and port numbers.

Firewall Builder (fwbuilder) was a nice object oriented interface. It was in ports but I removed it because it didn't support IPv6. FirewallBuilder rule files for IPFW, IPF, and various firewall appliances and routers, including Cisco IOS.

 

[cy@]

Wow! Yet another reason to not use OpenBSD besides no kern el modules and no Nvidia support!

You can tell if we use an upstream. If it's in /usr/src/contrib or /usr/src/sys/contrib, it's maintained by an upstream.

I've made too many changes to IPF that glebius@ requested I move it from crontrb to netpfil. You will notice that all of our packet filters are in netpfil. We are upstream for all of them.

Personally, I still use IPF on Solaris and FreeBSD. I use some ansible to create, manage, and distribute the same or similar rules across our farm at $JOB.

 

[teo]

This looks like the Linux netfilter interface or the Checkpoint interface. It's designed for firewall admins who have no concept of TCP/IP beyond IP addresses and port numbers.

Firewall Builder (fwbuilder) was a nice object oriented interface. It was in ports but I removed it because it didn't support IPv6. FirewallBuilder rule files for IPFW, IPF, and various firewall appliances and routers, including Cisco IOS.

Not everyone uses IPv6, too bad they removed it, please put it back in the binary packages, maybe later on down the road while using it as a firewall with IPv4 they will implement support for IPv6 .