Solved Questions about Firewalls (enable PF or IPFW or both together)

[blackfoxx]

Hello.
I'm using FreeBSD 13 release at my home-network with one server and some workstations/clients for about 2 years now.
Everything's fine so far.
In the beginning I enabled IPFW and PF on all systems, because I thought these 2 firewalls are using different technologies.
Now, after reading the whole manual and books like "Absolute FreeBSD 3rd edition" several times, it seems to me that both are using the same technology.
The only differences are "list-based" for IPFW and "object-oriented" for PF as well as their kind of configurations and logging.
Now my questions are: Does it make sense to run both together? Or would it be better to use only one of them? If so, which one and why?
Thank you!

 

[SirDice]

Use one or the other, not both.

 

[Kristof Provost]

it seems to me that both are using the same technology

Only in the sense that they're both bits of C code running in the FreeBSD kernel. They have made very different design choices, and share very little code. The closest thing to shared code they have is that they can both use dummynet for traffic shaping.

Use one or the other, not both.

As SirDice says, use one or the other. Do not enable both. Down that path lies madness. Do not expect to be supported if you enable both. You will be on your own with all of the strange issues you will eventually run into. Pick one, not both.

 

[blackfoxx]

Thank you so far... understood.
This would save some administration effort too.
But which one of them should I choose?
Is there a "better" of one over the other in case of doing their jobs?

 

[SirDice]

But which one of them should I choose?
Is there a "better" of one over the other in case of doing their jobs?

They're both good. Just try one, then try the other and pick the one you like. This is more a personal choice than a technical one.

 

[blackfoxx]

Okay. Thank you for quick reply! So all of my questions about that matter are answered now.

 

[Alex Seitsinger]

Go with PF. Better syntax.

 

[blackfoxx]

Go with PF. Better syntax.

That's also my impression. Furthermore all configuration is done in only one file and it has the capability to force reassembly and normalization of fragmented packets before sending them through the firewall.

 

[Alex Seitsinger]

That's also my impression. Furthermore all configuration is done in only one file and it has the capability to force reassembly and normalization of fragmented packets before sending them through the firewall.

Among a number of other fizzeatures, too. Happy packet filtering, friend.

 

[Whattteva]

I do want to point out though. Even though I definitely prefer pf for the syntax. It seems to me that FreeBSD treats IPFW more as a first-class citizen over pf. And pf on FreeBSD isn't the same pf that's on OpenBSD which supports newer syntax.

 

[mer]

And pf on FreeBSD isn't the same pf that's on OpenBSD which supports newer syntax.

That is not inaccurate, since technically pf on FreeBSD is a port. Kristof Provost can provide much more detail than I can, but pf on FreeBSD has diverged, I think mostly due to SMP differences on OpenBSD vs FreeBSD. I don't know how much effort is involved bringing in newer syntax, but if it were trivial I think it'd be done.
As long as one is aware of the differences, it's easy to follow popular tutorials.

IPFW vs pf as a first class citizen? I think they are treated equally, IPFW is native FreeBSD but most folks seem to consider them as equals, just getting there in different ways.

 

[Alex Seitsinger]

I do want to point out though. Even though I definitely prefer pf for the syntax. It seems to me that FreeBSD treats IPFW more as a first-class citizen over pf. And pf on FreeBSD isn't the same pf that's on OpenBSD which supports newer syntax.

I was actually happy to see that FreeBSD provides three different packet filtering options: IPF, IPFW, and PF.

 

[Alex Seitsinger]

IPFW vs pf as a first class citizen? I think they are treated equally, IPFW is native FreeBSD but most folks seem to consider them as equals, just getting there in different ways.

I think its fair to assume it's not considered first-class if your looking at the releases since FreeBSD's copy of PF uses an outdated syntax, and has for a while.

 

[Alex Seitsinger]

Use one or the other, not both.

Be a real man and use all three. When you include TCPWrappers, you've got yourself the quad-fecta of filtering fun.

 

[BaronBS]

Be a real man and use all three. When you include TCPWrappers, you've got yourself the quad-fecta of filtering fun.

LOL

 

[Kristof Provost]

I think its fair to assume it's not considered first-class if your looking at the releases since FreeBSD's copy of PF uses an outdated syntax, and has for a while.

That's not a accurate description at all.

FreeBSD's pf is indeed based on an OpenBSD version prior to their syntax change, which we've not imported (because, you know, breaking user configurations is bad), but pf in FreeBSD is maintained, and has a number of features (e.g. SMP scalability, vnet, L2 capabilities, dummynet integration) OpenBSD pf doesn't have. It's more useful to think of it as a fork at this point.

"When was it last imported" is also not a useful way to figure out if something is a first class citizen or not. All three firewalls in FreeBSD are maintained, all three are documented in the handbook.

 

[mer]

Kristof Provost thanks for the details, I knew it was alot but didn't realize how much. I agree that "fork" is a much better description than port.

 

[smithi]

Go with PF. Better syntax.

That's also my impression. Furthermore all configuration is done in only one file and it has the capability to force reassembly and normalization of fragmented packets before sending them through the firewall.

See ipfw(8) /reass

"Usually a simple rule like:

# reassemble incoming fragments
ipfw add reass all from any to any in

is all you need at the beginning of your ruleset."

As for syntax, that's entirely down to personal preference.

For this old assembly language hacker (NCR, IBM mainframes '68-'72; Signetics 2650 '77-'83, some 6502, Z80 and MC68010 later '80s, more recently Atmel tiny45), ipfw is very comfortable.

ipfw is in essence a virtual machine, executing its pre-compiled instructions very efficiently. For some, its source code is a good read.

Others prefer more abstract, object-oriented languages, and I admit to ignorance of pf just on that basis, though I'm assured that it's fine code.

I doubt there's much in it performance-wise or we'd have heard more about it.

Try what suits your nature, no need for any contests.

 

[mer]

smithi

IPFW can do simple or complex just as well as PF, so a lot boils down to which is easier for "You" to understand when writing rules, testing them and fixing the problems.

The "testing" of the requirements is something a lot of people forget, they simply complain "it's not working".

Too many people forget that the first step should always be come up with the requirements, which is why I start with boxes and arrow on a whiteboard representing a packet into/out of an interface, then "rules" become pass/deny and "why". Starting with a default deny makes it easier to write the rules because then all you have to do is determine what goes through.

 

[Kristof Provost]

I doubt there's much in it performance-wise or we'd have heard more about it.

ipfw is slightly faster than pf, in terms of packets per second: https://github.com/ocochard/netbenc...s/results/fbsd14-c276570-BSDRP1.991/README.md
The stateful performance is the relevant bit here, and the difference is small enough to not really be a major consideration.

Both are much, much faster than ipf.

I'd generally say to go with whatever feels best to you, unless you have specific requirements that only one of them supports. For example, ipfw can do NAT64, but pf can sync states for a failover setup.

 

[Argentum]

Use one or the other, not both.

Seems that I have been a heretic many years and always used them both at the same time - ipfw(8) for fast and simple blocking of incoming garbage and pf(4) for NAT, traffic routing to VM-s and other more complex things.

... a matter of taste of course ...

 

[smithi]

ipfw is slightly faster than pf, in terms of packets per second: https://github.com/ocochard/netbenc...s/results/fbsd14-c276570-BSDRP1.991/README.md

Thanks for that, interesting.

The stateful performance is the relevant bit here, and the difference is small enough to not really be a major consideration.

I tend to favour stateless connections where suitable, such as on the server side of TCP services, so it's gratifying to see ipfw's stateless performance exceeds its stateful, nearly forwarding speed - even if it's academic.

OTOH, pf's stateful performance exceeds stateless, which isn't surprising: I've never felt quite comfortable with ipfw's stateful implementation, if only because packets and bytes counting merges in- and outbound streams - needing extra 'count' rules if extracting traffic dats - but also because keep-state / check-state handling feels a bit tacked on compared to pf and has led to some strange example rulesets, especially in the handbook.

Both are much, much faster than ipf.

At least ipf's ipv6 performance matches ipv4, but off a pretty low base ...

I'd generally say to go with whatever feels best to you, unless you have specific requirements that only one of them supports. For example, ipfw can do NAT64, but pf can sync states for a failover setup.

Yep. Good that we have the choice. Cheers.