Anyone works on a nDPI support?

I have seen that there is a proposal about ndpi support at:
http://vyos.net/wiki/Proposed_enhancements

But I have tried to compile the GitHub - betolj/ndpi-netfilter and it leaks like hell and crashed my and others kernels…(CentOS, OpenSUSE and probably others).
I started testing: GitHub - vel21ripn/nDPI: Open Source Deep Packet Inspection Software Toolkit which seems to be more updated and tested.
It seems to work fine on OpenSUSE.
If anyone works on any level of support for nDPI let me know so I won’t waste my time.

Just to add some build instructions as an example from arch linux:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ipt_ndpi

I had some grand plans last year to get ndpi working but life got in the way :frowning:

ntop are likely the primary developers on ndpi these days, and I don’t think the netfilter module is important to them since they implement their own traffic control in ntop.

I’ve tracked ndpi for a few years now and have always been excited about the possibilities of iptables L7 firewalling but the module is definitely problematic and frequently breaking as either the kernel or ndpi itself moves forward, whilst there is no strong backing to keep the ndpi-netfilter working.

I haven’t re-evaluated it for about a year, so maybe someone else has done yet another fork to make it temporarily work for an indeterminate amount of time before they lose interest :slight_smile:

You may not be aware but Ubiquiti’s firewall product (which is a fork of Vyatta) does some L7 firewalling & reporting these days, although I haven’t reviewed it to see if it’s nDPI based.


I also wanted to say I think having L7/nDPI support in VyOS would be a major boon for people evaluating products as it is nearly a prerequisite in firewall products these days.

Another option is Snort & Openappid, although there is no direct iptables support, but I think you can leverage snort to mark the traffic based on app detection, and use traditional packet mark matching to reject.

A challenge all of these implementations have is flows often need to be established and packets sent back and forth for a while before an classifier can detect the application. That gets tricky when the use of RELATED,ESTABLISHED rules in iptables bypass lookups.

Depends on the scenario (Work, Business, Home, Cafe, Jail) it a feature and I know that ZeroShell has it’s support for some nDPI module.
I believe that compared to a kernel module a good proxy software will serve better.
The open source product’s mainly uses kernel and GPL\BSD compatible code but in the general products like FortiGate\Net and many other’s there is a usage of a proxy and not a kernel module since like forever.(and it performs better in the userland then the kernel.