Updating pfsense

05-Jun-2016 13:03

The short version is that pfsense packages will be more closely aligned with free BSD packages. Documentation: https://doc.pfsense.org/index.php/Developing_Packages Hi, I'm a Free BSD committer and I was also going to look at the port, on Luca's request. We should choose if we want to keep the net/ndpi port and update it and use that or just go for the bundled one.

Seems like this a perfect time to look at getting ntopng and pfsense working together. I can help you and, if you get something working, I can test it and commit it to the official tree once ready. I have not touched the included startup script, it should be tested by someone actually using it. You can find the port here: extract it while in /usr/ports/net and you should get the new port in there ready for testing.

With the new shaper, one could define easily a queue per n DPI protocol ID, and shape traffic with Thanks for your work on this.

It looks from this issue that the intention is to integrate ntopng with pfsense so that ntopng's packet inspection can be used in firewall rules.

That's useful but I can see there's a fair amount of work in it, hence it being fed into the ntopng 2.3 release.

What we do is mark traffic with the n DPI protocol ID but this is not probably what people need/want.

In essence we need your feedback on this so that we can complete the development (unless somebody wants to contribute) field.

ntopng can be integrated with pfsense to acts as a passive flow classifier so that the firewall can know the application protocol and thus implement security policies based on it. It build and packages fine here, but I have not run tested it.

I have created a fixed port based on the old deprecated one.

@numeronove You need to use the 2.3 code for latest changes.

The two of them, Free BSD ipfw and Open BSD pf, are quite different.

In pf Sense the main firewall is pf(4), while ipfw(4) is used with dummynet(4) to shape traffic, in Open BSD the traffic shaper is embedded in pf(4), since a post-ALTQ refactoring in version 5.5.

From here, the packet is back in the firewall, where it could be assigned to one of the queues, with a match rule based on the sin_port value. I have tested it on Free BSD and it works as expected.

I'm not sure that it can be done this way, because divert(4) man page also reads "Writing to a divert socket [...] will skip pf(4) filters to avoid loops" ( be diverted again ). The point is that you cannot set a queue per n DPI protocol ID but the configuration must be simpler IMHO, and this is where I need input.