Deployment models: choose the shape before the commands

A deployment model is largely determined by the boundaries you control. Before picking a shape, answer these questions in writing. Almost every wrong design we have seen traces back to an unasked question on this list.

• Where does the public IPv4 address terminate; your router, Saphira, or a provider's machine?
• Does the site actually have a public IPv4 address, or is it behind CGNAT (carrier-grade NAT) sharing one address with many customers?
• What IPv6 prefix has been delegated; a /48, /56, /60, or nothing at all?
• Who controls the router? Can inbound ports be forwarded? Can the router be replaced by Saphira entirely?
• Is the WAN PPPoE, DHCP, static addressing, or something else, and does the ISP permit the services you plan to run (mail especially)?
• Who controls reverse DNS for the public address? ( PTR records belong to whoever owns the address: usually the ISP or hoster, never you.)
• Is the public address static or does it change on reconnect?
• Where will DNS be authoritative, and who answers recursive queries internally?
• Which machine sends outbound mail, and which machine receives public HTTP/HTTPS/SMTP?
• Where should administrative access terminate; an office LAN, a VPN, or a management VLAN?
• Which systems must remain reachable when another system fails? What happens when power, the Internet line, one switch, one NIC, or one physical server fails?

Why these matter: every one of them moves a responsibility from one box to another. CGNAT removes your ability to accept inbound IPv4 no matter how perfect the firewall. An ISP-controlled router means your edge is somebody else's firmware. A dynamic address means DNS planning needs updates or a tunnel. Nobody can answer 'is this redundant?' until they have drawn which failures are shared.

Do you control the Internet router?
       |
       +-- No
       |    |
       |    +-- Public IPv4 available?
       |         |
       |         +-- Yes -> port forwarding / exposed host may work
       |         |          (Saphira as dedicated DMZ host)
       |         |
       |         +-- No -> CGNAT: investigate IPv6 delegation,
       |                    provider changes, VPN/tunnel to a
       |                    host that CAN listen, or remote hosting
       |                    for anything that must accept inbound
       |
       +-- Yes
            |
            +-- Can Saphira be the edge/router?
                 |
                 +-- nftables policy at the boundary
                 +-- routing between zones
                 +-- IPv6 RA/PD for the LANs
                 +-- OVS/VLANs for separation
                 +-- VPN for private access
                 +-- selected public services (HAProxy/Dragon services)

One host or separated roles?
       |
       +-- Few users, learning, cost-sensitive
       |    -> one Saphira machine, zones as interfaces/OVS
       |
       +-- Production mail, multi-user, compliance
            -> separated: edge / mail / web / dns / db
               (or VMs separated by OVS zones on one chassis,
                accepting the shared-fate caveat below)

Neither tree has a wrong branch; only uninformed ones. A teenager with an old PC and a sysadmin with a rack both end up on shapes from this page; the difference is which boundaries they can defend and which failures they accept.

'Home' is not one design. The variants below differ in where the NAT boundary sits and who owns the firewall; the packet path shows the difference better than prose.

Variant A: Saphira behind the ISP router

                 public IPv4
                      |
               ISP home router
               NAT / firewall
                      |
             192.168.1.0/24 LAN
                  /           \
             laptops       Saphira  192.168.1.50
                               |
                      MailDragon / webDragon

Variant A is the honest starting point: forward only the ports you published, give Saphira a reserved address, and keep nftables on the host. It inherits the ISP router's firmware as part of your security boundary; you cannot patch it.

Variant B: Saphira as exposed/DMZ host

            public IPv4
                 |
          ISP router  (DMZ/exposed host -> 192.168.1.50)
                 |
   laptops --- LAN --- Saphira DMZ host
                          (nftables is now YOURS)

Variant B moves unsolicited inbound to Saphira: the router still owns NAT and LAN trust, but the DMZ host owns its own firewall. Only ever expose a dedicated interface/machine, never the family PC.

Variant C: Saphira replaces the ISP router

  ONT/modem (bridge)
       |
  Saphira edge  <- owns WAN, NAT, firewall
       |
       +-- users LAN
       +-- servers
       +-- guests
       +-- management

Variant C is where Saphira stops being a guest and becomes the network. Honesty about current support: on FTTP/PPPoE connections this needs a PPP client (pppd + rp-pppoe). That packaging is planned for Saphira; see the network-services chapter's Zen Internet walkthrough for the interim approach, and DHCP-based WANs already work with dhcpcd. Do not claim a PPPoE edge in production until the pieces you run are the pieces you tested.

• Variant D: IPv6-native hosting; publish services on delegated IPv6 with real firewall policy, while IPv4 NAT remains on the ISP router. Increasingly the fastest route to inbound on CGNAT lines.
• Variant E: CGNAT: your IPv4 address is shared with strangers; inbound IPv4 is impossible by design. IPv6 delegation, a VPN endpoint elsewhere, or remote hosting are the workarounds. No firewall setting fixes CGNAT.
• Variant F: the home lab split; public services on a DMZ segment, experiments on a private lab network, with the router (or Saphira in variant C) refusing lab-to-public and public-to-lab crossings by default.

A business network should be described as routed zones, not as one giant trusted LAN. Each zone exists because a different kind of trust lives there:

                      Internet
                         |
                   Saphira edge
                 routing / nftables
                         |
          +--------------+--------------+
          |              |              |
       users          servers       management
       VLAN 10        VLAN 20        VLAN 30
          |              |
          |          OVS / VMs
          |          /       \
          |     MailDragon  webDragon

  internal DNS answers private names; public DNS is separate

What should cross: users -> specific server ports (HTTP, mail submission), management -> device admin from admin workstations only, HAProxy -> servers on published ports. What should not: guests anywhere, users directly to databases, servers initiating into users, backup traffic sharing the users LAN. Internal DNS resolves private names; public DNS never publishes internal addresses. Internet ingress terminates at the DMZ; egress is logged and filtered.

The same architecture can live on one chassis or many. Neither is inherently better; they trade different risks.

One Saphira machine            Separated roles
    |-- firewall                   edge01   firewall / routing / VPN
    |-- DNS                        mail01   MailDragon
    |-- MailDragon                 web01    webDragon
    |-- webDragon                  dns01/02 authoritative DNS
    '-- VPN                        db01     database

Start with one box if that is what you have; it is a completely legitimate design, and every technique in this manual works on it. Split roles when a real reason appears: mail that must survive a web-server rebuild, databases that deserve their own disk, a second machine arriving in the cupboard. Do not split because articles said so; split when the failure you fear demands it.

'Remote server' collapses at least six arrangements that differ in who controls what.

• VPS with the public IP directly on the VM; Saphira owns the host firewall; the provider owns the hypervisor, the address, reverse DNS, and upstream filtering.
• Dedicated physical server: same as above plus sole tenancy of the hardware; BMC/IPMI access becomes your management problem to secure.
• Colocated machine you own: you control hardware lifecycle; the site controls power, cooling, and network.
• Remote server behind a provider firewall; ports you need must be opened in the provider's panel first: their rules are part of your packet path.
• Remote private network reachable only through VPN; nothing public listens; management and internal services traverse the tunnel.
• Migration target: a rented/cloud service being replaced by owned Saphira hardware (see the migration ladder below).

The multi-site chapter holds the WireGuard configuration. Here, choose the topology, because it decides operational cost for years.

Hub and spoke                Site-to-site pair        Mesh

         Branch A
            |                 Office A === VPN === Office B
            |                 
Branch B -- HQ -- Datacentre   
            |
         Home/admin            

A ===== B
|\     /|
| \   / |
|  \ /  |
C ===== D

Hub-and-spoke is simpler to operate than a full mesh because every spoke needs exactly one tunnel and the hub owns policy; a mesh with n sites needs n(n-1)/2 tunnels, each a failure point and a key to rotate. Meshes earn their cost only when direct paths between many sites genuinely matter.

• Unique prefixes per site, always. Overlapping RFC1918 ranges make routing ambiguous; fix the addressing BEFORE installing any tunnel.
• Return routes: both ends must know how to reply. One-way reachability is the classic half-configured tunnel.
• Local versus central Internet breakout: branch traffic may exit locally (simple, policy-light) or ride the hub (central filtering/logging). Decide per site, write it down.
• Central DNS and backups: convenient and dangerous together; make the hub's DNS and backup service reachable over the VPN, but ask what a hub outage does to every branch.
• IPv6 prefixes per site: with a /48 per site from delegation, site addressing becomes trivial and non-overlapping by construction.
• What should remain public: public mail/web listeners usually terminate at each site's own edge rather than crossing the VPN; private administration crosses it.

This is the largest omission in most network planning. Where you place machines decides which failures are shared, and 'we have two servers' is not automatically redundancy.

one server
    failure -> everything stops

two VMs on one physical host
    VM failure -> isolated (good)
    host failure -> BOTH stop (shared fate)

two servers on one switch
    server failure -> survives
    switch failure -> both disappear

two DNS servers in one building
    machine failure -> survives
    building / ISP failure -> both disappear

Redundancy is real only when the failure you fear hits exactly one member of the pair. Ask for every 'redundant' pair: what else do they share? Power circuit, switch, hypervisor, Internet line, building, DNS delegation? Name the shared components and you have named your true failure domain.

This is why the multi-site chapter pairs with authoritative DNS (a second nameserver in another failure domain), why MailDragon backup MX belongs on different hardware and connectivity, and why backups must land outside the failure domain of what they protect; ideally outside the building.

The single most useful habit in network design is walking the path a packet takes; before and after you build. For every architecture, trace:

source
   |
DNS lookup
   |
destination (public or private address)
   |
router
   |
firewall
   |
optional HAProxy / VPN
   |
service
   |
return route

# MailDragon, inbound mail:
Internet -> public IP -> firewall/HAProxy -> MailDragon

# MailDragon, outbound delivery:
MailDragon -> routing/NAT -> public sending IP -> remote MX

The outbound path is where mail reputations are made: remote mail servers ask for the PTR of the PUBLIC address your mail leaves from. If you cannot control reverse DNS for that address (ISP-owned at home, provider panel on a VPS), deliveries will be distrusted no matter how correct the rest of the stack is. Trace the reply path too; a rule that lets traffic out but forgets the return route produces the famous 'connects one way only' mystery.

Design IPv6 alongside IPv4 from the start, and several IPv4 headaches simply vanish; alongside some new responsibilities.

• Delegated prefix versus interface address: the /48 or /56 your ISP delegates is address SPACE for your LANs; the address on the WAN interface is just one lease. Plan subnets from the space, not from the interface.
• One /64 per LAN, always: SLAAC and neighbour discovery assume it. With a /48 there is no reason to be stingy; see the network-services chapter for the dhcpcd ia_pd router configuration.
• RA provides the default route and (optionally) DNS; DHCPv6 provides addresses where you choose stateful allocation.
• Firewall without NAT: every host is globally addressable, so nftables policy, not address hiding, is the security boundary. Global does NOT mean unprotected, and NAT is not a firewall.
• Prefix planning across business and multi-site networks: per-zone and per-site prefixes chosen from the delegation make return routes and firewall sets writable as prefixes rather than host lists.
• When the ISP changes the delegated prefix: RA lifetimes let clients re-address themselves, but firewall sets, DNS records, VPN allowed-prefixes, and static service addresses need a plan. Prefer generating rules from the prefix rather than pasting addresses.

• Obtain and route the delegated /48 (dhcpcd, Unbound)
• IPv6 foundations
• IPv6 Prefix Delegation in depth

Copy this into your site documentation and fill every line before configuring. Writing it down first prevents a remarkable number of later mistakes, and it becomes the map the next administrator (including future-you) will pray for.

Site name: ____________________
Internet provider: ____________
Public IPv4: __________________   CGNAT: yes / no
IPv6 prefix: ___________________  (size and who delegates it)
Router controlled by us: yes/no  Replaceable by Saphira: yes/no
Reverse DNS controlled by: _____

User LAN:    ________________
Server LAN:  ________________
Mgmt LAN:    ________________
Guest LAN:   ________________

Public services: ______________________________
Internal services: ____________________________

Mail sending IP: ____________  Mail hostname: ______________
Authoritative DNS: ____________  Recursive DNS: ______________

VPN required: yes/no  Remote sites: _______________________
Backup destination: ___________  (in a DIFFERENT failure domain?)
UPS: yes/no   Failure tolerance: which single failure must NOT stop mail? ________

Saphira's philosophy is that the first deployment should be small and honest, not a datacentre on day one. Each rung of the ladder below is a working system; migrate when a real reason arrives.

home server behind ISP router
         |
dedicated Saphira edge
         |
separated server network (zones)
         |
second site / remote host
         |
routed multi-site infrastructure

cloud-hosted service
      |
identify dependencies (DNS, mail, storage, TLS)
      |
reproduce locally on Saphira
      |
test with real traffic on alternate names/ports
      |
migrate DNS / lower TTLs / cut over
      |
retain ownership locally (DIY) or hand the
runbook to us (DIFY) - either way, no monthly rental

Both ladders share one rule: change one boundary at a time and verify the packet path at each step. A migration that cannot be walked station-by-station is not a migration; it is a hope.

The reusable questions never change: which address receives traffic, which route carries it, which firewall permits it, which name identifies it, and how does the return traffic get back? The model you pick decides where those answers live.

• Build a text-only home-router design
• Design business zones and VLANs
• Harden a directly addressed remote host
• Route selected networks between sites
• DHCP, RA, Prefix Delegation and RADIUS
• Write the nftables policy between zones

Leave this page with one principle: do not begin by asking which command to type. Begin by deciding where the packet should enter, where it should travel, which boundary should permit it, where the service should run, and how the reply gets home. Write the worksheet. Draw the failure domains. Then configuration becomes the implementation of an understood design rather than experimentation, and every other chapter of this manual becomes a recipe you can follow instead of a guess you must debug.