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

alfa

alfa

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..
 
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.
 
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.
 
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.
 
alfa said:
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.
Click to expand...
'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.

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

alfa said:
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
Click to expand...
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.
 
hardworkingnewbie said:
Just reload the whole rule set, and it's gone what should be gone.
Click to expand...
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.

hardworkingnewbie said:
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.
Click to expand...
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.
 
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?
 
I am planning to run ipfw3 in userland. With DPDK support, it will be available not only in FreeBSD, but also in Linux.
DPDK is generally great and comes with tons of "originally invented" amazing features which can be found in DragonflyBSD accidentally.
 
OK, the least I can tell you, DragonFly BSD runs perfectly well in bhyve. WiFi support is practically nonexistent, but who would want that stuff on his router (except for myself LOL). So for the time being you just run it in bhyve and use IPFW3 all you like.

If you don't have VT-d supported on that host, you can bridge all the NICs and give each one's tap part over to the VM, then leave all the filtering to VM itselfn (by disabling forwarding between the NICs on the FreeBSD level). I have this setup working for me currently (for testing purposes).
 
You must log in or register to reply here.
Back
Top