NGFW is one step forward FreeBSD?


Aspiring Daemon

Reaction score: 211
Messages: 646

Hi , before anything I dont think that FreeBSD is become "behind" in this subjet, case is this:

In my work(300/400) users , my boss called a guy who coworked with me for improve the actual network infraestructure
so far so good

the guy dont have anything against FreeBSD but allways call it Linux 🤣 ..after I explain to it multiple times the diference

anyway, the things is that whe need to put NGFW in some critical points of the network
and here I think..
in the future FreeBSD will can

-dissamble a tcp/udp package
-procesing it against acl or rules
-and reinserting it into the FW ?

song time along I try to do this,
with PF , but the version is old compared to OpenBSD,
and the funcion diver-to-reply
is not in FreeBSD PF
( is needed for reinsert the packet into PF after ,for ex Snort analize it)

So, maybe I'am too old for accept this fact and go on
but I am right? a FreeBSD server cant do it?

I hate put a closed litle box instead of a server


Aspiring Daemon

Reaction score: 211
Messages: 646

thanks, but I dont find anything with examples



Reaction score: 819
Messages: 1,224

Do you need deep packet inspection for HTTPS traffic as well? In case yes, you want to install a transparent squid proxy and add an ICAP daemon which would do the actual inspection and filtering. Squid is needed for unwinding the TLS traffic and rewinding it into TLS for final delivery.

Transparent HTTPS Proxy on the FreeBSD Server
Using c-icap for proxy content antivirus checking on-the-fly

In case you don’t need/want to fiddle with TLS, you may get away with ipfw(8) + divert(4).

You would need to run a divert daemon to which ipfw would pass packets for filtering, and the daemon would filter on it, then either drop the packet or apply changes if needed and pass back the packet to ipfw for final delivery. Of course at this level you won’t see the content of encrypted traffic.

The first incarnation of my sysutils/ipdbtools employed a divert daemon for IP filtering based on a geo-location dataset. Although, my ipdbtools(1) now employ ipfw tables for geo location filtering, and the divert daemon is no more used, it is still available in my GitHub repository. Perhaps you could reuse the daemon part and replace the IP filtering by your filtering requirements.