web/README.md

fwlnx

Firewall Linux - A small and simple Linux based Firewall Distribution

It combines a smart Linux distribution (NixOS) with modern network services, a simple web interface and API to configure it. It's not meant to be a replacement to far superiour Appliances like pfSense or OPNSense but as an alternative solution for typical home use.

Target platforms

• QEMU/KVM
• PCEngines APU2/3/4
• Generic AliExpress Router PCs

Planned initial features

• Firewall
  • NAT
  • Rules
  • UPnP
• DynDNS
• VPN
  • OpenVPN
  • Wireguard
• NTP (chrony)
• DHCP (Kea)
• DNS (Knot)
• Auto config backup
• Cron/Timers (Systemd-timers)

Installation

TBD

Design

Partitioning

The partitioning schema is kept simple and will be setup like this:

BIOS/MBR:

/dev/sda:
  /dev/sda1  swap  [SWAP]  # SWAP
  /dev/sda2  ext4  /       # FWLNX

UEFI/GPT:

/dev/sda:
  /dev/sda1  vfat  /boot   # ESP
  /dev/sda2  swap  [SWAP]  # SWAP
  /dev/sda3  ext4  /       # FWLNX

Operating system

As the base operatring system NixOS is used.

Garmr

Backend daemon

Freyja

Web frontend

OLD concept

Update flow

State before the update:

• boot entry last is set to version 1 (last known working version)
• boot entry current is also set to version 1
• on every boot the default boot entry is set to last automatically in early boot

Update process:

• a new version is downloaded as a btrfs snapshot and put into place as version 2

• current boot entry is modified to boot the new version

• current is set as default boot entry

• device reboots into new version 2 via current boot entry

• early boot sets last as default boot entry

• after successful boot:

  • the user marks the system as functional which sets the last boot entry to the current version

• if something goes wrong:

  • the system reboots, now with the last entry being the default booting into the last known working system
  • the user gets displayed an error because last and current is not the pointing to the same version and last is booted indicating an error

Configuration changes

• User changes current config via HTTP API (Web interface)
  • Background process puts changes into ansible variables in /config
• When user discards changes git repo under /config is reset to original state
• When change is ready and user triggers commit via HTTP API
  • Changes form a git commit with name [$VERSION] $username - $change summary
  • Timer is setup to revert to old config in 600s
  • Changes get applied via ansible
• User confirms working state via HTTP API
  • Timer get removed
• If new change is not confirmed and Timer gets triggered
  • git commit is reverted
  • Ansible runs again with old config
  • User get an error message

---

Made with ❤️ and 🪄✨.

Icon partly from stockio