OpenGFW filters flows with expressions instead of fixed rule tables
OpenGFW sits in a Linux packet path, rebuilds TCP and IP traffic into flows, identifies protocols, and evaluates rules written with the Expr language. The analyzer list covers HTTP, TLS, QUIC, DNS, SSH, SOCKS4 and SOCKS5, WireGuard, OpenVPN, Trojan, and detection of some fully encrypted traffic. Rules can log, permit, block, or modify supported traffic, and a SIGHUP reloads them without replacing the running process. That combination makes the project interesting as a small policy engine rather than a traditional port-and-address firewall.
The repository is compact enough to inspect. Our measured checkout had 74 files, about 8,345 lines of source, and used 0.3 MB. Its current command code registers 10 analyzers and 1 DNS modifier. Multicore flow distribution, connection offloading, IPv4, and IPv6 are part of the stated design. Yet the README labels both machine-learning traffic classification and the web interface as work in progress. You should expect to operate a command-line network component, not click through a finished appliance.
A clean 37-second build does not provide a runnable configuration
Installation at commit 5815180 completed in 29 seconds and resolved 119 packages. The Go build then succeeded in 37 seconds. That is an encouraging result for anyone auditing or extending the engine: there was no compile repair or dependency chase in our fresh Debian container. The repository also has 2 CI workflow files. It does not include a Dockerfile, so there is no official container path to copy into a deployment.
Runtime setup is the harder half. OpenGFW accepts one rules file argument and reads a separate YAML configuration. The command searches the working directory, $HOME/.opengfw, and /etc/opengfw, or accepts a path through --config. Traffic must reach its NFQueue backend, which means the host's packet-routing policy and permissions are part of the installation. The README gives no sample config, sample rules, build command, or NFQueue wiring instructions. You have source-level clues where an operator needs a worked deployment.
What happened when we ran it
Our sandbox installed commit 5815180 in 29 seconds, built it in 37 seconds, and completed go test in 18 seconds. The test result was 10 passed and 0 failed. We ran those checks with 3 CPUs, 8 GB of RAM, the Go 1.24 Bookworm image, no secrets, and no elevated privileges. Our measurement method verifies the checkout's dependency, compilation, and test paths. It does not prove that packets can be captured or filtered on a configured router.
The repository has no top-level tests directory, although the Go test command found and passed 10 tests in package files. That distinction matters when scanning the tree: absence of a dedicated directory did not mean absence of tests. We did not load an NFQueue, exercise live traffic, or judge detection accuracy. No timing or throughput figure should be inferred from the 18-second test duration. It measures the suite on our box, not packets per second.
NFQueue is the only packet backend today
The README calls the analyzer and modifier framework extensible, but it also says NFQueue is the only current I/O implementation. That narrows the practical audience to Linux operators comfortable placing a user-space process in the traffic path. The engine's config exposes queue and socket buffers, worker count, TCP buffering limits, UDP stream limits, and optional GeoIP and GeoSite files. Those controls are useful once you understand the workload, but the repository offers no sizing advice or example values.
Version drift deserves one check before building current master. Our lab commit compiled inside a Go 1.24 image on October 6, 2026. The go.mod now declares Go 1.27, while the repository was pushed on October 4. Use the declaration in the revision you deploy rather than treating the older lab environment as a promise about today's branch. The project is small, yet its operating boundary includes the kernel queue, routing rules, configuration files, and policy expressions.
The maintainers publish fixes without promising active development
The README opens with an unusual and useful disclosure. The maintainers temporarily removed OpenGFW after finding its code used in commercial censorship products. They restored the repository for research, ad blocking, parental control, malware protection, VPN abuse prevention, and traffic analysis, but say they do not plan to continue active development themselves. They will keep it available, accept pull requests, and publish releases when appropriate. That is maintenance by invitation, not a staffed roadmap.
Recent activity prevents a simple abandonment label. Release v0.4.3 shipped on October 4, 2026, fixing QUIC ClientHello detection when a handshake spans multiple packets, and the repository was pushed the same day. GitHub showed 278 stars and 1 open issue, with no open pull request in the first 100 open items. The sole issue asks about moving from MPL-2.0 to AGPLv3, while the repository remains MPL-2.0. OpenGFW is credible source code for a specialist who will own it. It is a poor substitute for a supported firewall product.