IPFW is there a way to Port DragonflyBSD's IPFW3 to FreeBSD

alfa

Member

Reaction score: 4
Messages: 25

Hi,
I am planning to move on IPFW from PF i have mentioned why in this topic.

DragonflyBSD's IPFW3 has below pros which are IPFW2 has not

1)Load-balancing
forward-option can be `round-robin' or `sticky'.
Code:
ipfw3 add forward 192.168.1.1:80,192.168.1.2:80 round-robin tcp from ....
Above example can forward the traffic to 2 destination in round-robin.

2)States can be added/deleted using the ipfw3 utility.
Code:
ipfw3 state delete rulenum

3)States can be expire after some time
Code:
ipfw3 state add rule 1000 udp 192.168.1.100:0 8.8.8.8:53 expiry 600
...
bycn82

These are some hard problems to me when i try to completely move on IPFW.
So is there a way to port IPFW3 to FreeBSD.
Thanks for any help and suggestions..
 

mer

Aspiring Daemon

Reaction score: 337
Messages: 551

That's an interesting thought.
"Could it be?" Maybe, probably, I don't know.
"How hard would it be?" I think is the real question to ask. It may be worth it to look at the freebsd mailing lists, the security, hackers and arch in particular and ask there.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,348
Messages: 38,870

I don't think it's going to be easy. DragonFlyBSD was forked from FreeBSD 4.8, that's before the major overhaul of 5.0. 5.0 had significant changes with regards to a more granular kernel locking that replaced the 'old' giant lock. Both DragonFlyBSD and FreeBSD have diverged quite a lot since then.
 

jammied

Member

Reaction score: 16
Messages: 34

Almost certainly possible. I think a better question would be: is it possible with the level of effort you wish to put into it and the skills you have for the task.
 

hardworkingnewbie

Active Member

Reaction score: 171
Messages: 175

1)Load-balancing
forward-option can be `round-robin' or `sticky'.
Code:
ipfw3 add forward 192.168.1.1:80,192.168.1.2:80 round-robin tcp from ....
Above example can forward the traffic to 2 destination in round-robin.
'sticky' is the default in FreeBSD's ipfw. So adding it would make only sense when round-robin gets added.

And I don't see the need for round-robin here at firewall level, because there are enough reverse proxies being available like nginx or Apache which you can use to implement just that in userland. On top of that in an even more reliable manner probably as well.

2)States can be added/deleted using the ipfw3 utility.
Code:
ipfw3 state delete rulenum
Just reload the whole rule set, and it's gone what should be gone.

3)States can be expire after some time
Code:
ipfw3 state add rule 1000 udp 192.168.1.100:0 8.8.8.8:53 expiry 600
I don't see so much the purpose of that example. Aside that ipfw has dynamic states, which get deleted after a certain time, which though more is a builtin thingamabob.
 

PMc

Daemon

Reaction score: 676
Messages: 1,358

Just reload the whole rule set, and it's gone what should be gone.
I don't think that would work. If you reload properly (that is, reload into a different set, then swap the sets), nothing will be gone (which is the purpose, to keep the stateful sessions up), and if you flush, everything is gone (including the connection where you are logged in).
There are probably means to achieve the exact behaviour as desired, like swapping the rule against a new one then deleting it, and such could be nicely scripted - but its not so straightforward obvious.

I don't see so much the purpose of that example. Aside that ipfw has dynamic states, which get deleted after a certain time, which though more is a builtin thingamabob.
Thats the problem: as long as your hacker sends repeated packets, the rule won't get deleted. TCP rules probably won't at all, because ipfw sends keepalives - that's configureable. (There is lots and lots of niceties within there.)

I would agree those features could be implemented, and they don't look like a big issue or design change. The problem is, ipfw source appears not as the most transparent of it's kind (at least to me). And, if you mend with these things, they are by their nature intertwined with all the networking stuff, and while coding these features might be 5% of the work, sufficiently understanding the whole IP and packethandling and networking scheme as it currently is implemented makes up for the other 95%. :(

Wherea, the round robin thing, as I mentionend already here, that should be doable with probabilities, with the additional benefit that you can fine-grain the amounts.
 

free-and-bsd

Daemon

Reaction score: 164
Messages: 1,000

Why won't you, then, run Dragonfly BSD on your gateway for its own sake? It seems to have its own advantages in many ways.
It also has its ports system with ports for this and that. 'Assuming you're not going to use your gateway as your office desktop/development machine... are you?
 
Top