# IPFW or PF?



## vadimk (Jun 2, 2014)

Hi,

Probably this question has been asked already, but I can't find it here - too many hints. I have a production server that does not need to do NAT. It would be good to have a kind of DOS protection against clients that send too many requests (to slow them down). The external link is 100 Mb. Do these two types of FW firewall equally do this? Which one is preferable? 

Thanks,

Vadim.


----------



## SirDice (Jun 3, 2014)

vadimk said:
			
		

> Do these two types of firewall equally do this?


Yes.



> Which one is preferable?


That's personal. Use them both and choose the one _you_ like.


----------



## vadimk (Jun 3, 2014)

I saw that PF has ALTQ and the ability to dynamically change (or block) incoming traffic. Take as an example the chapter "Using Overload Tables to Protect SSH" from  https://www.freebsd.org/doc/handbook/firewalls-pf.html. Can IPFW do this?


----------



## SirDice (Jun 3, 2014)

vadimk said:
			
		

> Can IPFW do this?


Yes, using dummynet(4).


----------



## kpa (Jun 3, 2014)

I have used both and I have to say IPFW has a few more capabilities like L2 filtering but it's quite hard to get it to do what you want because the whole rule formalism is very ad-hoc compared to the elegance of PF. Just to get stateful filtering with outbound NAT you have to resort to rule structures that resemble the classic don't-do-this spaghetti code with GOTO-statements.


----------



## vadimk (Jun 3, 2014)

Thank you for your answers. I have chosen to use PF because:
it is a new experience for me;
laconic configuration;
sysutils/pftop.


----------



## Oko (Jun 5, 2014)

vadimk said:
			
		

> Hi,
> 
> Probably this question has been asked already, but I can't find it here - too many hints. I have a production server that does not need to do NAT. It would be good to have a kind of DOS protection against clients that send too many requests (to slow them down). The external link is 100 Mb. Do these two types of FW firewall equally do this? Which one is preferable?
> 
> ...



PF on OpenBSD in general as a firewall solution but if you must use FreeBSD for firewall IPFW would be a natural choice. PF is not really portable software and the version which comes with FreeBSD is obsolite.


----------



## kpa (Jun 5, 2014)

Oko said:
			
		

> vadimk said:
> 
> 
> 
> ...



It uses the older (OpenBSD 4.5 I think?) syntax but internally it has many improvements over the original implementation. For example on FreeBSD 10 it is no longer locked to a single core but can fully make use of multiple cores.


----------



## Oko (Jun 5, 2014)

kpa said:
			
		

> Oko said:
> 
> 
> 
> ...



PF depends on OpenBSD network stack which is very different from FreeBSD network. While getting PF to work on multi cores on FreeBSD is an admirable attemt to add the features which will eventually be added to the real PF the fact remains that IPFW is only native firewall for FreeBSD. As an OpenBSD users I would certainly welcome native PF like syntax implementation of new firewall on FreeBSD. Updating PF on FreeBSD is I am afraid lost battle due to PF design.


----------



## vadimk (Jun 5, 2014)

Does that mean PF has flaws at FreeBSD implementations or it just have less features than one at OpenBSD? From your words I understood, that PF was ported to FreeBSD and it's development under FreeBSD is not going well ?


----------



## SirDice (Jun 5, 2014)

vadimk said:
			
		

> Does that mean PF has flaws at FreeBSD implementations or it just have less features than one at OpenBSD? From your words I understood, that PF was ported to FreeBSD and it's development under FreeBSD is not going well ?


Development is going excellent, just look at the changes in PF on FreeBSD 10.0. But you have to keep in mind that FreeBSD used the PF from an older version of OpenBSD. It's not the latest version we have.


----------



## vadimk (Jun 5, 2014)

I am not so mature to benefit from the latest PF version in use. Features that I use right now at 10 are enough for me. More important is to have stable version that is still going to be improved. If there is plan to support PF at FreeBSD - it is OK.
But thank you for comments - in a case I feel PF is old for me - can look into alternative distribution.   :h


----------



## Oko (Jun 5, 2014)

Pf might be developing rapidly but that doesn't change the fact that is a rapid development of the 5 year old version of pf  which had so many new features and optimization added in the mean time on OpenBSD. I am afraid that this time NetBSD guys got it right by developing new firewall from ground up optimized for mult threading.


----------



## free-and-bsd (Aug 17, 2018)

Oko said:


> I am afraid that this time NetBSD guys got it right by developing new firewall from ground up optimized for mult threading.


Not necessarily. Quite often this development of new software meant to replace the old but working one ends up in product that doesn't do the same old job much better than the old one does it -- though it may have some "new features"... and always a bunch of bugs to fix. And then... some people still use IPFW and prefer it over everything else, as you can see.


----------



## kpa (Aug 17, 2018)

Multithreading hasn't been shown to be that benefical for packet filtering. Sure, some of the load can be spread over multiple cores if you have multiple interfaces but you very quickly run into a wall because the incoming packets have a natural order and you can't process any of them out of order because in TCP for example there are sequence numbers and you can't break the bounds set by them.


----------



## SirDice (Aug 17, 2018)

free-and-bsd Keep in mind you are responding to a 4 year old post.


----------



## free-and-bsd (Aug 17, 2018)

Right  Started up looking up new posts, but then...


----------



## jsika (Feb 13, 2020)

I think that PF would be a better option for the situation, when some your server wants to add quickly and effectively a long list of IPs to block temporarily, i.e. for 3 hours or so and later drop it. This could happen during something like DDoS attack, if I'm not mistaken, is it right? However, IPFW has a better and clear syntax, suitable for shorter rules.


----------



## SirDice (Feb 14, 2020)

jsika said:


> This could happen during something like DDoS attack, if I'm not mistaken, is it right?


Think of your internet connection as a funnel. Think of a DDoS as someone that fills that funnel faster than it can empty at the bottom. As a result the funnel starts to overflow. Even if you put your finger on the bottom hole (closing your local firewall) the funnel would still be completely full and overflow.


----------



## PMc (Feb 14, 2020)

jsika said:


> I think that PF would be a better option for the situation, when some your server wants to add quickly and effectively a long list of IPs to block temporarily, i.e. for 3 hours or so and later drop it.



I must say I started off with IPFW and stayed with it, never used PF. But I think it is easy to do this with IPFW with the "table" construct: a table can hold an arbitrary number of IPs and can be changed dynamically at any time, without touching any rules.

The other statement further above, that IPFW tends to create spaghetti code: indeed I see many people starting to write IPFW rules and then creating more and more of spaghetti (which I think is very dangerous because one must be able to logically verify a firewall).
I think this is mostly caused by conceptional mistakes: people tend to think of a firewall as a "wall", which implies that it has exactly two sides (an inside and an outside), and then they know they want to block certain traffic and start to code from that point onwards.

I achieved better results by first understanding where in the system IPFW sits and how it works, and then devising some primitives to handle e.g. statefulness, nat, forwarding, etc in a general way.
The desired rules can then be written in a pseudocode and automatically converted into the proper IPFW commands: no problems, no spaghetti, and no need to even look into the actual rules.

As an example, for statefulness I use such a construct (assuming that incoming and outgoing flows have already been properly separated):

```
/sbin/ipfw add 1350 set 16 call 65525 all from any to any
/sbin/ipfw add 65525 set 16 count tag 1 tcp from XXXXX to YYYYY setup keep-state :f13rd
/sbin/ipfw add 65526 set 16 return all from any to any
/sbin/ipfw add 1360 set 16 ACTION1 untag 1 all from any to any tagged 1
[...]
/sbin/ipfw add 380 set 16 call 410 all from any to any
/sbin/ipfw add 390 set 16 ACTION2 untag 1 all from any to any tagged 1
/sbin/ipfw add 400 set 16 skipto 430 all from any to any
/sbin/ipfw add 410 set 16 check-state :f13rd
/sbin/ipfw add 420 set 16 return all from any to any
```


----------



## SirDice (Feb 14, 2020)

PMc said:


> The other statement further above, that IPFW tends to create spaghetti code: indeed I see many people starting to write IPFW rules and then creating more and more of spaghetti (which I think is very dangerous because one must be able to logically verify a firewall).


It's usually just bad organization. I've seen this happen with any and all firewalls I've ever managed, not just the software ones from FreeBSD. Even something like Checkpoint's Firewall/1 (which had a really nice GUI) can result in an extremely disorganized mess if it's not managed properly.


----------



## free-and-bsd (Apr 3, 2020)

You guys have inspired me to study IPFW. Up to now I thought it was archaic, but your comments seem to make it worth looking into. Thankfully, I"ve found some interesting paper about it.


----------



## PMc (Apr 3, 2020)

Great. 
Maybe that's correct, it is somehow 'archaic', in a way that there is no full-featured GUI ready to employ.
But then it is also archaic in a way so that you could easily write such a GUI for your specific purposes and attach it, and that would perfectly work.

(I started to write such a GUI recently - it now sits somewhere half-ready on my webserver, after I got bored fighting the bootstrap CSS stuff...)


----------



## free-and-bsd (Apr 3, 2020)

PMc said:


> Great.
> Maybe that's correct, it is somehow 'archaic', in a way that there is no full-featured GUI ready to employ.
> But then it is also archaic in a way so that you could easily write such a GUI for your specific purposes and attach it, and that would perfectly work.
> 
> (I started to write such a GUI recently - it now sits somewhere half-ready on my webserver, after I got bored fighting the bootstrap CSS stuff...)


That's it, getting bored with it... that's why I only get to learn things when there's a real application for my needs. BTW, they promised bootstrap 4 would be better.


----------



## priyadarshan (Mar 9, 2022)

It seems if_bridge(4) favours the use of IPFW for some filtering functionality.

For example,



> IPFW can filter Ethernet types using *mac-type* so all packets are passed to the filter for processing.



Note: I am aware the thread's last post is from 2 years ago, but it still seems relevant, according to search engines.


----------



## Deleted member 67862 (Mar 9, 2022)

I use both. I like to use PF for a server where I only want to open certain ports and on my desktop PC I just prefer to use IPFW since you can use the preset "workstation".


----------



## priyadarshan (Mar 14, 2022)

Michael W. Lucas opinion (youtube)


----------



## PMc (Mar 14, 2022)

priyadarshan said:


> Michael W. Lucas opinion (youtube)


Wow - he wants something that is "readable" and where he doesn't need to understand what it does. 

I, for the contrary, wanted something where I precisely understand what it does, so that I can make it do exactly what I want to be done. And even with IPFW, which is native to FreeBSD, I need three kernel patches to make it actually do what one would expect it to do. I wonder how many fixes it might need to make a foreign import like PF work correctly...


----------



## priyadarshan (Mar 15, 2022)

I guess it depends also on what kind of "config language" bests suits a sysadmin's mind-map.

It is like programming, one may favoured C or Perl, one Haskell, or Erlang, etc.

To me, in the end, features do count a bit more than language. If I may ask, what kind of extra functionality requiring kernel patches you need to have from IPFW?


----------



## PMc (Mar 28, 2022)

priyadarshan said:


> If I may ask, what kind of extra functionality requiring kernel patches you need to have from IPFW?


You're welcome.
As it just ruined my sunday (and was probably the first time I had to fully abandon and revert a planned change), take this one, for starters,


			Different PATHs in /etc/rc and /etc/rc.shutdown
		

plus subsequent mails, plus a couple of bugreports, eg. 256828 (bottomline is, this is just broken throughout R.13).

What I originally meant, is e.g. bug 165190 or 260796, among others.

Now You may ask, what am I specifically doing. In fact, I am just using the features, to maintain flows throughout arbitrarily weird network topologies. Here is a demo ipfw config in JSON format:

```
{"name":"demo","skiplines":10,"startline":10,"icmptypes":"0,3,8,11,12","icmp6intf":"1,133,134,143","icmp6regn":"128,129","created_at":"2021-09-15T00:04:27.257Z","updated_at":"2022-03-28T11:20:28.877Z","discarded_at":null,"connects":[{"id":62,"name":"lo0","local":true,"icmp6":false,"icmp6types":"","created_at":"2021-09-15T00:05:42.098Z","updated_at":"2021-09-15T00:08:59.542Z","discarded_at":null,"regions":[{"id":140,"name":"self.all","icmp":true,"icmptypes":"","icmp6":false,"icmp6types":"","me":true,"notme":false,"me6":false,"notme6":false,"created_at":"2021-09-15T00:06:25.021Z","updated_at":"2021-11-09T10:11:09.991Z","forward_id":null,"discarded_at":null,"filtercalls":[],"networks":[],"tableentries":[],"_vv":"001.000"}],"netifs":[],"_vv":"001.000"},{"id":63,"name":"tun0","local":false,"icmp6":true,"icmp6types":"","created_at":"2021-11-17T10:05:40.697Z","updated_at":"2021-11-17T10:05:40.697Z","discarded_at":null,"regions":[{"id":141,"name":"lan","icmp":true,"icmptypes":"","icmp6":true,"icmp6types":"","me":false,"notme":false,"me6":false,"notme6":false,"created_at":"2021-11-17T10:05:46.351Z","updated_at":"2021-11-17T10:05:46.351Z","forward_id":null,"discarded_at":null,"filtercalls":[],"networks":[{"id":256,"addr":"192.168.0.0/22","negate":false,"created_at":"2021-11-17T10:05:55.573Z","updated_at":"2022-03-28T11:24:02.550Z","discarded_at":null,"_vv":"001.000"}],"tableentries":[],"_vv":"001.000"},{"id":150,"name":"portfwd","icmp":true,"icmptypes":"","icmp6":true,"icmp6types":"","me":false,"notme":false,"me6":false,"notme6":false,"created_at":"2021-11-18T11:59:42.785Z","updated_at":"2021-11-18T12:05:01.726Z","forward_id":null,"discarded_at":null,"filtercalls":[],"networks":[{"id":263,"addr":"192.168.3.41/32","negate":false,"created_at":"2021-11-18T12:01:08.751Z","updated_at":"2022-03-28T11:24:14.649Z","discarded_at":null,"_vv":"001.000"}],"tableentries":[],"_vv":"001.000"},{"id":148,"name":"lcnk","icmp":true,"icmptypes":"","icmp6":true,"icmp6types":"","me":false,"notme":false,"me6":false,"notme6":false,"created_at":"2021-11-18T23:27:48.304Z","updated_at":"2022-03-28T11:31:31.335Z","forward_id":null,"discarded_at":null,"filtercalls":[],"networks":[{"id":261,"addr":"198.51.100.3/32","negate":false,"created_at":"2021-11-18T23:28:02.429Z","updated_at":"2022-03-28T11:26:21.092Z","discarded_at":null,"_vv":"001.000"}],"tableentries":[],"_vv":"001.000"},{"id":143,"name":"lcnk.local","icmp":true,"icmptypes":"","icmp6":true,"icmp6types":"","me":false,"notme":false,"me6":false,"notme6":false,"created_at":"2021-11-19T00:05:15.661Z","updated_at":"2022-03-28T11:31:44.181Z","forward_id":null,"discarded_at":null,"filtercalls":[{"id":16,"filter_id":14,"recv":true,"xmit":true,"seq":1,"created_at":"2021-11-19T00:21:00.847Z","updated_at":"2021-11-19T00:21:00.847Z","discarded_at":null,"_vv":"001.000"}],"networks":[{"id":257,"addr":"198.51.100.3/32","negate":false,"created_at":"2021-11-19T00:05:33.228Z","updated_at":"2022-03-28T11:26:58.331Z","discarded_at":null,"_vv":"001.000"}],"tableentries":[],"_vv":"001.000"}],"netifs":[],"_vv":"001.000"},{"id":64,"name":"vtnet0","local":false,"icmp6":false,"icmp6types":"","created_at":"2021-09-15T00:09:50.827Z","updated_at":"2021-11-09T10:14:28.429Z","discarded_at":null,"regions":[{"id":142,"name":"portfwd","icmp":true,"icmptypes":"","icmp6":true,"icmp6types":"","me":false,"notme":true,"me6":false,"notme6":false,"created_at":"2021-11-18T11:54:36.561Z","updated_at":"2021-11-18T11:54:50.844Z","forward_id":null,"discarded_at":null,"filtercalls":[{"id":17,"filter_id":14,"recv":true,"xmit":true,"seq":1,"created_at":"2021-11-18T11:57:48.247Z","updated_at":"2021-11-18T11:57:48.247Z","discarded_at":null,"_vv":"001.000"}],"networks":[],"tableentries":[],"_vv":"001.000"},{"id":144,"name":"internet","icmp":true,"icmptypes":"","icmp6":false,"icmp6types":"","me":false,"notme":true,"me6":false,"notme6":false,"created_at":"2021-10-16T14:15:42.562Z","updated_at":"2021-11-09T10:15:02.226Z","forward_id":null,"discarded_at":null,"filtercalls":[{"id":18,"filter_id":15,"recv":true,"xmit":false,"seq":1,"created_at":"2021-11-18T12:16:03.578Z","updated_at":"2021-11-18T12:16:03.578Z","discarded_at":null,"_vv":"001.000"}],"networks":[],"tableentries":[],"_vv":"001.000"},{"id":147,"name":"internet.lcnk","icmp":true,"icmptypes":"","icmp6":true,"icmp6types":"","me":false,"notme":true,"me6":false,"notme6":true,"created_at":"2021-11-18T23:59:44.664Z","updated_at":"2022-03-28T11:32:32.931Z","forward_id":4,"discarded_at":null,"filtercalls":[],"networks":[{"id":260,"addr":"192.168.0.0/22","negate":true,"created_at":"2021-11-19T00:00:04.441Z","updated_at":"2022-03-28T11:28:05.153Z","discarded_at":null,"_vv":"001.000"}],"tableentries":[],"_vv":"001.000"},{"id":145,"name":"lbnk","icmp":true,"icmptypes":"","icmp6":true,"icmp6types":"","me":false,"notme":false,"me6":false,"notme6":false,"created_at":"2021-11-18T22:32:27.364Z","updated_at":"2022-03-28T11:33:00.915Z","forward_id":null,"discarded_at":null,"filtercalls":[],"networks":[{"id":258,"addr":"203.0.113.142/32","negate":false,"created_at":"2021-11-18T22:32:42.122Z","updated_at":"2022-03-28T11:29:25.974Z","discarded_at":null,"_vv":"001.000"}],"tableentries":[],"_vv":"001.000"}],"netifs":[],"_vv":"001.000"},{"id":65,"name":"gif0","local":false,"icmp6":true,"icmp6types":"","created_at":"2021-11-18T23:31:38.684Z","updated_at":"2021-11-18T23:31:38.684Z","discarded_at":null,"regions":[{"id":146,"name":"remote","icmp":true,"icmptypes":"","icmp6":true,"icmp6types":"","me":false,"notme":false,"me6":false,"notme6":false,"created_at":"2021-11-19T00:00:46.731Z","updated_at":"2021-11-19T00:00:46.731Z","forward_id":null,"discarded_at":null,"filtercalls":[],"networks":[{"id":259,"addr":"10.0.0.150/32","negate":false,"created_at":"2021-11-19T00:00:58.450Z","updated_at":"2022-03-28T11:23:49.957Z","discarded_at":null,"_vv":"001.000"}],"tableentries":[],"_vv":"001.000"},{"id":149,"name":"lbnk.intra","icmp":true,"icmptypes":"","icmp6":true,"icmp6types":"","me":false,"notme":false,"me6":false,"notme6":false,"created_at":"2021-11-18T23:41:33.679Z","updated_at":"2022-03-28T11:30:59.085Z","forward_id":null,"discarded_at":null,"filtercalls":[],"networks":[{"id":262,"addr":"192.168.3.0/28","negate":false,"created_at":"2021-11-18T23:41:42.974Z","updated_at":"2022-03-28T11:23:23.089Z","discarded_at":null,"_vv":"001.000"}],"tableentries":[],"_vv":"001.000"}],"netifs":[],"_vv":"001.000"}],"flows":[{"id":193,"name":"all.local","comment":"","primacy":"normal","orig_ports":"","resp_ports":"","proto":"any","direction":"originate","keepstate":false,"setup":false,"setnr":null,"limitcnt":10,"limsrchost":false,"limsrcport":false,"limdsthost":false,"limdstport":false,"seqnr":1,"origin_id":140,"respond_id":140,"ori_in_shp_id":null,"ori_out_shp_id":null,"rsp_in_shp_id":null,"rsp_out_shp_id":null,"created_at":"2021-09-15T00:08:00.954Z","updated_at":"2021-09-15T00:08:00.954Z","discarded_at":null,"_vv":"001.000"},{"id":187,"name":"INFRA.inet","comment":"pkg-audit (braucht http)","primacy":"normal","orig_ports":"","resp_ports":"https,http,domain","proto":"tcp","direction":"roundtrip","keepstate":true,"setup":true,"setnr":null,"limitcnt":10,"limsrchost":false,"limsrcport":false,"limdsthost":false,"limdstport":false,"seqnr":8,"origin_id":140,"respond_id":144,"ori_in_shp_id":null,"ori_out_shp_id":null,"rsp_in_shp_id":null,"rsp_out_shp_id":null,"created_at":"2021-10-16T14:14:58.046Z","updated_at":"2021-11-09T12:14:54.885Z","discarded_at":null,"_vv":"001.000"},{"id":188,"name":"INFRA.inet","comment":"","primacy":"normal","orig_ports":"","resp_ports":"domain,ntp","proto":"udp","direction":"roundtrip","keepstate":true,"setup":false,"setnr":null,"limitcnt":10,"limsrchost":false,"limsrcport":false,"limdsthost":false,"limdstport":false,"seqnr":23,"origin_id":140,"respond_id":144,"ori_in_shp_id":null,"ori_out_shp_id":null,"rsp_in_shp_id":null,"rsp_out_shp_id":null,"created_at":"2021-11-09T12:15:20.131Z","updated_at":"2021-11-09T12:15:20.131Z","discarded_at":null,"_vv":"001.000"},{"id":185,"name":"INFRA.maint","comment":"","primacy":"normal","orig_ports":"","resp_ports":"ssh","proto":"tcp","direction":"roundtrip","keepstate":true,"setup":true,"setnr":null,"limitcnt":10,"limsrchost":false,"limsrcport":false,"limdsthost":false,"limdstport":false,"seqnr":24,"origin_id":144,"respond_id":140,"ori_in_shp_id":null,"ori_out_shp_id":null,"rsp_in_shp_id":null,"rsp_out_shp_id":null,"created_at":"2021-11-09T12:18:26.244Z","updated_at":"2021-11-17T10:08:46.705Z","discarded_at":null,"_vv":"001.000"},{"id":186,"name":"SVC.VPN","comment":"tunnel anwahl","primacy":"normal","orig_ports":"8111","resp_ports":"8106","proto":"udp","direction":"roundtrip","keepstate":false,"setup":false,"setnr":null,"limitcnt":10,"limsrchost":false,"limsrcport":false,"limdsthost":false,"limdstport":false,"seqnr":25,"origin_id":144,"respond_id":140,"ori_in_shp_id":null,"ori_out_shp_id":null,"rsp_in_shp_id":null,"rsp_out_shp_id":null,"created_at":"2021-11-10T23:47:59.910Z","updated_at":"2022-03-28T11:35:39.961Z","discarded_at":null,"_vv":"001.000"},{"id":192,"name":"INFRA.lan","comment":"","primacy":"normal","orig_ports":"","resp_ports":"bareos-sd","proto":"tcp","direction":"roundtrip","keepstate":true,"setup":true,"setnr":null,"limitcnt":10,"limsrchost":false,"limsrcport":false,"limdsthost":false,"limdstport":false,"seqnr":26,"origin_id":140,"respond_id":141,"ori_in_shp_id":null,"ori_out_shp_id":null,"rsp_in_shp_id":null,"rsp_out_shp_id":null,"created_at":"2021-11-17T10:08:25.541Z","updated_at":"2021-11-17T10:08:25.541Z","discarded_at":null,"_vv":"001.000"},{"id":182,"name":"SVC.bckp","comment":"lokaler client","primacy":"normal","orig_ports":"","resp_ports":"bareos-fd","proto":"tcp","direction":"roundtrip","keepstate":true,"setup":true,"setnr":null,"limitcnt":10,"limsrchost":false,"limsrcport":false,"limdsthost":false,"limdstport":false,"seqnr":27,"origin_id":141,"respond_id":140,"ori_in_shp_id":null,"ori_out_shp_id":null,"rsp_in_shp_id":null,"rsp_out_shp_id":null,"created_at":"2021-11-17T10:09:40.383Z","updated_at":"2021-11-17T10:09:40.383Z","discarded_at":null,"_vv":"001.000"},{"id":184,"name":"SVC.web","comment":"http access mit portforward","primacy":"normal","orig_ports":"","resp_ports":"http","proto":"tcp","direction":"roundtrip","keepstate":true,"setup":true,"setnr":null,"limitcnt":10,"limsrchost":false,"limsrcport":false,"limdsthost":false,"limdstport":false,"seqnr":28,"origin_id":142,"respond_id":141,"ori_in_shp_id":null,"ori_out_shp_id":null,"rsp_in_shp_id":null,"rsp_out_shp_id":null,"created_at":"2021-11-18T11:58:45.589Z","updated_at":"2022-03-28T11:34:52.777Z","discarded_at":null,"_vv":"001.000"},{"id":189,"name":"SVC.GIF","comment":"","primacy":"normal","orig_ports":"","resp_ports":"","proto":"ipencap","direction":"roundtrip","keepstate":false,"setup":false,"setnr":null,"limitcnt":10,"limsrchost":false,"limsrcport":false,"limdsthost":false,"limdstport":false,"seqnr":29,"origin_id":140,"respond_id":145,"ori_in_shp_id":null,"ori_out_shp_id":null,"rsp_in_shp_id":null,"rsp_out_shp_id":null,"created_at":"2021-11-18T22:33:57.102Z","updated_at":"2021-11-18T22:33:57.102Z","discarded_at":null,"_vv":"001.000"},{"id":190,"name":"GW.tunnel","comment":"nach lbnk","primacy":"normal","orig_ports":"","resp_ports":"","proto":"any","direction":"roundtrip","keepstate":false,"setup":false,"setnr":null,"limitcnt":10,"limsrchost":false,"limsrcport":false,"limdsthost":false,"limdstport":false,"seqnr":30,"origin_id":147,"respond_id":148,"ori_in_shp_id":null,"ori_out_shp_id":null,"rsp_in_shp_id":null,"rsp_out_shp_id":null,"created_at":"2021-11-18T23:37:04.817Z","updated_at":"2022-03-28T11:37:03.136Z","discarded_at":null,"_vv":"001.000"},{"id":191,"name":"GW.tunnel","comment":"","primacy":"normal","orig_ports":"","resp_ports":"","proto":"any","direction":"roundtrip","keepstate":false,"setup":false,"setnr":null,"limitcnt":10,"limsrchost":false,"limsrcport":false,"limdsthost":false,"limdstport":false,"seqnr":31,"origin_id":149,"respond_id":141,"ori_in_shp_id":null,"ori_out_shp_id":null,"rsp_in_shp_id":null,"rsp_out_shp_id":null,"created_at":"2021-11-18T23:42:20.277Z","updated_at":"2021-11-18T23:50:09.165Z","discarded_at":null,"_vv":"001.000"},{"id":183,"name":"SVC.lbnk","comment":"nat für tunnelendpunkt","primacy":"normal","orig_ports":"","resp_ports":"","proto":"any","direction":"roundtrip","keepstate":false,"setup":false,"setnr":null,"limitcnt":10,"limsrchost":false,"limsrcport":false,"limdsthost":false,"limdstport":false,"seqnr":32,"origin_id":140,"respond_id":143,"ori_in_shp_id":null,"ori_out_shp_id":null,"rsp_in_shp_id":null,"rsp_out_shp_id":null,"created_at":"2021-11-19T00:07:00.540Z","updated_at":"2022-03-28T11:36:12.460Z","discarded_at":null,"_vv":"001.000"}],"filters":[{"id":15,"name":"blacklist","mode":"rules","rewrite":"norew","port":"","localip_id":141,"entry":10,"size":1035,"blk1918":false,"created_at":"2021-11-18T12:12:33.279Z","updated_at":"2021-11-18T12:12:33.279Z","discarded_at":null,"_vv":"001.000"},{"id":14,"name":"natd.portfd","mode":"divert","rewrite":"natph","port":"8201","localip_id":140,"entry":null,"size":null,"blk1918":false,"created_at":"2021-11-18T11:57:37.511Z","updated_at":"2022-03-28T11:21:45.617Z","discarded_at":null,"_vv":"001.000"}],"forwards":[{"id":4,"name":"lbnk","remoteip_id":146,"responding_id":146,"created_at":"2021-11-19T00:02:28.952Z","updated_at":"2022-03-28T11:31:06.304Z","discarded_at":null,"_vv":"001.000"}],"tables":[],"shapers":[],"_vv":"001.000"}
```

You can upload this to https://flowm.daemon.contact/, optionally edit it, and then you can  use this script to dynamically update it on the target. (The generated rulesets are fully dynamic and updating won't normally drop stateful connections. That works with sets - and using sets with e.g. nptv6 is a fun in itself - that is what bug 260796 is about.)

Have fun.


----------



## astyle (Mar 28, 2022)

I'd like to chime in...

In other threads, it's been noted that the logic of PF and IPFW setups are actually inverses, so there's the pitfall that if you don't set up a rule correctly, it won't work as intended:









						Other - Confusing documentation
					

decuser I think the expectation to get "recipes" just doesn't apply too well to firewalling. For a real firewall, you WILL write a ruleset, and it will be your own.  On my firewall box, supporting several zones (internal clients, internal servers, guests, management and dmz), it currently looks...




					forums.freebsd.org
				



Oh, and I've seen people at my workplace struggle with IPchains about a year ago, they quoted some weird-looking IPchains rules. And it hit me only this past weekend: Yeah, that was a Windows admin who expected that the Windows Firewall logic will translate to IPchains.


----------



## priyadarshan (Mar 28, 2022)

PMc said:


> You can upload this to https://flowm.daemon.contact/, optionally edit it, and then you can  use this script to dynamically update it on the target. (The generated rulesets are fully dynamic and updating won't normally drop stateful connections. That works with sets - and using sets with e.g. nptv6 is a fun in itself - that is what bug 260796 is about.)



Thank you for the thoughtful information, the demo ipfw config in JSON format, and mentioning flowm.daemon.contact and that script. Very useful.


----------



## PMc (Mar 28, 2022)

astyle said:


> Oh, and I've seen people at my workplace struggle with IPchains about a year ago, they quoted some weird-looking IPchains rules. And it hit me only this past weekend: Yeah, that was a Windows admin who expected that the Windows Firewall logic will translate to IPchains.


Same here. I do IPFW and only that. The trick with IPFW is, it is NOT a wall. With the word "wall" you instinctively think two sides, an evil outside and a safe inside. You can do that (and most people actually do), but IPFW is a lot more, and in the ultimate it doesn't make sense anyway, because, you may have a public WLAN (and a secure WLAN) and an uplink and some vpn-links to other places, and so on - so now, where is the inside and outside of the wall?

IPFW copes with that, when we handle each network connection individually. A machine has some network interfaces, and these are enumerable, so that is a good place to begin. And then we decide, which flows to we have going thru that interface (and to which places do they go), and then: should it be filtered, and with which filters? Should it be NATed? Should it be rerouted and along which conditions? Should it be bandwidth-limited? Should it be stateful? etc.
These are just arbitrary building blocks that can be put together in any number; and finally the software does sort it all out and spit out a ruleset that will work.

I am quite certain any other firewall type could do similar just as well, if you know how to do it. But then, it's necessary to dive quite deep into it in order to create a ruleset generating software - and you don't want to do that multiple times.

Anyway, I had to do it, because it can be done. Most people just want a wall, they want to cave in, because outside is where the evil is. (I personally don't believe in evil.) Sometimes that's a problem - I have a plugin for security/suricata; it can run on a divert socket, but suricata folks don't want to support that further, they just want to support walls, and there are quite some performance problems.


----------



## LVLouisCyphre (Jun 3, 2022)

I started out using ipfw before pf was available over two decades ago.  Now I use pf.  It's closer, IMO, to Cisco IOS ACLs which is why I use it plus you can use it for QoS.  Either one will work based on your needs.  I just evolved to needing pf plus it works with how my brain is wired deciphering config files and debugging output.


----------



## hardworkingnewbie (Jun 3, 2022)

When I created my own little FreeBSD router which really does just some basic stuff I first looked at IPFW. It reminded me too much of Linux' iptables, which I really do loathe, so I instead switched over to Pf and never looked back since then. That's the beauty of having a choice.


----------



## tux2bsd (Jun 3, 2022)

priyadarshan said:


> Michael W. Lucas opinion (youtube)


I watched that firewall part, good introductory level stuff for the audience.  He doesn't say anything particularly useful, he just prefers pf and cites an example or two.  I use pf on BSD, seemed like the "go to" at the time I started with FreeBSD.

He mentions "ipchains" in 2018... he was too out of touch with "Linux" to make any mention of it and should have just stuck to the BSD side of his talk. edit: I notice someone above also referred to "ipchains", in 2022...


----------



## Alain De Vos (Jun 4, 2022)

I join PMc on this. More filtering with PF , but more "non-filtering" functionality with IPFW.


----------

