Hardware Recommendations
Your perimeter firewall plays a critical role in the operation of Sovereign Stack. It provides all the base networking functions for the network underlay. It also provides the basis for isolating your various devices (in combination with VLANs) and enforcing network policy.
A good example device includes Protectli Vault – 6 Port. Consider buying directly from the manufacturer to minimize supply chain risks. Also, depending on your budget, buy the Pro version that comes with support and additional security features such as coreboot.
Get something that has AT LEAST SIX network interfaces. More is better for future use cases. Each port essentially represents one or more physical security domains that network policy (i.e., firewall rules) can be applied and enforced. Note that each port MAY carry multiple VLANs (i.e., 802.1q aka trunk), each of which can represents a distinct DMZ.
Get something that has a reasonable amount of RAM. 4GB+ is probably sufficient unless you plan on using your firewall for more computationally-intensive operations. For the purposes of Sovereign Stack, only basic services are generally used: DHCP, DNS, DDNS, DNS over TLS. As always, more is better.
The following section covers these features and where they are relevant when deploying Sovereign Stack workloads.
Firewall Configuration
Dynamic DNS
It is recommended that you configure DDNS on your external firewall. That way whenever it receives a new public IP address from your upstream ISP, the associated DNS records will be automatically updated with the new IP address. This makes switching ISPs or physically moving easy.
IP Addressing
IP addressing is left up to the network administrator. Dedicating a single /24 (e.g., 172.16.0.0/24 to VLAN-1/mgmt, 172.16.1.0/24 to VLAN-2/SERVERS, etc) to each DMZ/VLAN combination is usually sufficient.
DHCP
DHCP Reservations allow you to create a one-to-one mapping between a physical MAC (ethernet) address to a specific IP address. It is common to create DHCP reservations for eacho VM in a Deployment.
Domain Name Server (DNS)
Many firewalls like pfSense include an internal DNS server. For Sovereign Stack deployments, typically you will define DNS records for VMs which attach to the network underlay (www, btcpayserver, lnplayserver, etc).
You will also need to specify DNS records for each website you intend to deploy.
DNS over TLS
For recursive queries (i.e., if the local DNS Server cannot resolve locally), requests are sent to upstream DNS resolvers. It is best practice to configure DNS over TLS. PFSense allows you to configure DNS over TLS, which has better security and privacy properties than traditional UDP-based DNS.
Choosing your upstream DNS servers is worth considering. Consider choosing DNS servers that filter out adult content, trackers, and malware. This will help block known bad domains from being resolved.
Wireguard
Wireguard allows you to create fast encrypted tunnels between two endpoints. In general, your OUTSIDE interface of the PFSense firewall will accept UDP traffic on a port (e.g., 51820). Wireguard profiles form the basis for securely connecting back to your data center, giving your device a known IP address that can be used for firewall policy and IP whitelists on www/nginx container for each deployment. This is useful for both System Owners and Trusted Mobile Users.
Traffic Policy
The firewall functionality defines your network policy: what traffic can go where. Typically you have a series of "zones" or "DMZs" with varying levels of trust: e.g, MGMT/VLAN, SERVERS, WIRELESS, OUTSIDE.
Aliases
Aliases allow you to create named groups of one or more IP addresses, Networks (CIDRs), Ports, or URLs. These named groups can then be referenced by firewall rules. This results in simplified management of firewall rules. Use them.
NAT
NAT allows you to translate incoming traffic on one interface (typically OUTSIDE) and direct it to a host one a trusted DMZ. This is how you direct incoming traffic from the Internet to your production websites.
Rules
Traffic policy rules are enforced on all packets entering an interface. Unless explicitly allowed, all traffic is blocked. Reference your Aliases rather than specifying IP addresses or CIDR blocks. All rules should be DENY all with EXPLICIT and NARROW rules.