NAT your own packets

I’ve been talking about network address translation here for a while, including instructions on building your own NAT device with MirageOS. The library behind those posts, mirage-nat, went on to back talex5’s unikernel firewall for QubesOS, but was unreleased and essentially unmaintained between late 2015 and early 2017.

At the March 2017 MirageOS hack retreat in Marrakesh, talex5 convinced me to do some much-needed maintenance on this library. After having let it age between March and October, I was persuaded to release a version with the hippest latest build system last week. It comes with an example of how you might use it in a MirageOS unikernel that does no additional firewalling. A more compelling example of how you might use mirage-nat (and MirageOS) is still available in qubes-mirage-firewall, which I recommend highly if you’re using QubesOS.

mirage-nat provides helper functions for building a NAT on top of OCaml modules that fulfill the module signature it expects for storage. There’s currently only one such implementation provided with mirage-nat, which uses the lru library to provide an in-memory store that dynamically ages out entries as the table fills. The module Mirage_nat_lru provides this implementation. You can see Mirage_nat_lru in action in the included example, or by standing outside my house and connecting to SSID “free wifi for humans not a trap”.

mirage-nat used to also have an Irmin backend, but it was developed before Irmin 1.0’s set of breaking changes and would have required significant effort to port. I wasn’t inspired to do this work, because mirage-nat’s primary user suffers from memory usage growing without bound, and Irmin is still “the database that never forgets”: without garbage collection or another mechanism for limiting memory use, Irmin can’t satisfy that requirement. If Irmin learns how to forget, or if a user for mirage-nat appears that considers its infinite storage to be a feature, the current design of mirage-nat should be amenable to building a new Irmin backend. (Indeed, mirage-nat should be accommodating of persistent storage, remote procedure calls, and all manner of other exotic things.)

The MirageOS hack retreat is directly responsible for the continued existence of mirage-nat. If you’re interested in breathing new life into an old project, starting something new and exciting, tightening the bolts on something that’s starting to vibrate loose, helping to make the MirageOS world easier to understand, or getting started yourself, you might be interested in the next iteration of the MirageOS hack retreat, which is coming up in late November through early December of 2017. Come hack with us!