Zedmos

6. Use cases

⌘K

Worked examples, each written as the order to do things in. They assume you have finished First configuration: a working uplink, an internal network, and clients that reach the internet.

Addresses in the examples use the documentation ranges. Substitute your own.

Publishing a server

A web server on 192.168.1.10 should be reachable from the internet on the appliance's public address.

  1. Give the server a fixed address. Either statically on the server, or as a reservation in Services → Kea DHCP → Kea DHCPv4 so it always gets the same one. A forward to an address that changes is a forward that breaks.
  2. Create the forward. Firewall → NAT → Destination NAT, add a rule: Interface*: WAN Protocol*: TCP Destination*: the WAN address, port 443 Redirect target*: 192.168.1.10, port 443 * Let it create the matching firewall rule.
  3. Narrow the source if you can. If only your branch offices need it, put their addresses in an alias (Firewall → Aliases) and set the rule's source to that alias instead of any. A service published to everyone is a service you have to defend from everyone.
  4. Test from outside. Not from inside: a client on the LAN reaching the WAN address is a different path (and needs reflection). Use a phone on mobile data, or Network → Diagnostics → Port Probe from another site.

When it does not work, in order: does Firewall → Log Files → Live View show the arriving packet? If not, it never reached you — the provider or an upstream device is blocking it. If it shows it blocked, the firewall rule is missing or below a blocking rule. If it shows it passed and the client still gets nothing, the server itself is not listening or has its own firewall.

Segmenting with VLANs

Guests, cameras and the office should not be on one network.

  1. On the switch, make the port to the appliance a trunk carrying the tags you will use. This step is outside the appliance and is the one people forget.
  2. Create the interfaces. Network → Interfaces → Create new, Type: VLAN, the parent interface, the tag, Role: LAN. Give each one an address (192.168.20.1/24 for guests, say) and its own DHCP range — one form per network.
  3. Write the rules. A new interface allows nothing until you say so. For a guest network, the usual shape is: Block guest → any internal network* (put your internal ranges in an alias and block traffic to it) Allow guest → DNS on the appliance, if guests use it Allow guest → any (the internet)

In that order: the block must come first, because the first match wins.

  1. Check from a guest device that it reaches the internet and cannot reach the office network. Test the "cannot" as carefully as the "can".

A second line should take over when the first fails.

  1. Bring up the second uplink as its own interface with Role: WAN (Network → Interfaces).
  2. Give both gateways a monitor address in Network → Gateways → Configuration — something reachable beyond the provider's router, such as a public resolver. Monitoring the gateway itself proves only that the router is alive, which is not the question.
  3. Group them. Network → Gateways → Group: the primary in tier 1, the secondary in tier 2. Two members in the same tier share the load instead; that is load balancing, not failover, and it breaks anything that requires a stable source address.
  4. Point the traffic at the group. In the LAN rule that allows outbound traffic, set Gateway to the group.
  5. Test it by pulling the cable. Watch Network → Gateways change state and confirm that traffic keeps flowing. Existing connections will drop — they were established through the other line — and new ones succeed.

Site-to-site VPN with WireGuard

Two offices, 192.168.1.0/24 and 192.168.2.0/24, joined.

On each appliance:

  1. VPN → WireGuard → Instances, add an instance: a listen port (51820), a tunnel address (10.10.0.1/24 on side A, 10.10.0.2/24 on side B). Note the public key it generates.
  2. VPN → WireGuard → Peers, add the other side: its public key, its public address and port as the endpoint, and allowed IPs covering the other side's tunnel address and internal network — 10.10.0.2/32, 192.168.2.0/24 on side A, mirrored on side B.
  3. Firewall → Rules on WAN: allow UDP to the listen port from the other site's address.
  4. Firewall → Rules on the tunnel interface: decide what the far side may reach. "Everything" is a decision, not a default.

Check VPN → WireGuard → Status: a recent handshake on both sides and counters that move. No handshake means the two ends are not talking — check the WAN rule and the endpoint address. A handshake with no traffic means the tunnel is up and the routing or the rules are wrong: look at allowed IPs first, since it is both the route and the filter.

Remote workers

People at home need to reach the office.

With WireGuard — simplest, best performance:

  1. Add an instance for remote users, with a tunnel network of its own (10.20.0.1/24).
  2. For each person, use VPN → WireGuard → Peer generator: it produces the client configuration and a QR code for the phone app. Their allowed IPs decide what they can reach; a /32 for their tunnel address and the office network they need.
  3. WAN rule for the listen port; rules on the tunnel interface for what they may reach.

With OpenVPN — when clients must traverse hostile networks:

  1. System → Trust: a certificate authority and a server certificate.
  2. VPN → OpenVPN → Instances: a server instance, TCP on 443 if you need to survive restrictive networks, with the tunnel network and the routes and DNS it pushes.
  3. A user per person (Access → Users) with a client certificate.
  4. VPN → OpenVPN → Client Export gives each person their profile. It contains their key — send it over something you trust, not an unencrypted mail.

For both: remove access when someone leaves. WireGuard — delete the peer. OpenVPN — revoke the certificate in System → Trust → Revocation.

Guest Wi-Fi with a captive portal

Visitors get internet, on your terms, without an account.

  1. A network of their own — a VLAN for guests (above), with rules that let them out and keep them away from everything internal.
  2. A portal zone — Hotspot → Administration: the guest interface, the portal page's text, and session and bandwidth limits.
  3. How they authenticate — click-through with terms for a café, vouchers for a hotel, a directory or RADIUS server where guests are known.
  4. Vouchers, if you use them: Hotspot → Vouchers generates a batch with a validity period and prints them. The clock starts at first use.
  5. Watch it work — Hotspot → Sessions lists who is on, and Hotspot → Log File records every attempt.

If the law where you operate requires you to keep records of who used the network, see System → Compliance — and read the caveat there.

Intrusion detection and the security engine

See what is on the network, then act on it.

  1. Install and configure the engine (Security and Policy → Settings): which interfaces it inspects, and its deployment mode.
  2. Watch first. Leave the Default policy permissive, switch IDS/IPS on in detection mode, and let it run for a day.
  3. Read what it found — Security and Policy → Reports and the engine's dashboard cards. Expect false positives; they are the reason for step 2.
  4. Then let it block. Turn on prevention for the rule categories you have confirmed, not all of them at once.
  5. Give yourself an exclusion list before you need it: the payment terminal, the backup appliance, the machine that talks to the accounting provider — Exclusions in the policy.

TLS inspection

Inspecting encrypted traffic — what it costs and how to do it properly.

Most traffic is encrypted, so a scanner that cannot see inside it sees little. Inspection works by terminating TLS on the appliance and re-issuing the certificate from an authority of your own — which means every client must trust that authority, and every client that does is trusting the appliance with its traffic.

  1. Create the authority — System → Trust → Authorities. A long-lived CA whose name says what it is.
  2. Distribute it to clients — by group policy, MDM, or by hand. A client that does not trust it sees certificate errors on every site, which looks exactly like an attack, because technically it is one.
  3. Enable the TLS proxy — Security and Policy → Settings → TLS Proxy, with that CA.
  4. Turn inspection on in a policy — TLS & Transport in the policy that covers the devices concerned.
  5. Exclude what must not be inspected — banking, health, government sites, and anything using certificate pinning (which will fail regardless).

Inspection is a decision with legal and ethical weight. In many jurisdictions employees must be informed, and some categories of traffic must never be intercepted. Decide the policy with your organisation before you enable the feature, not after.

A high-availability pair

Two appliances, so a failure is invisible.

  1. Build them the same way: same version, same interfaces, same cabling.
  2. A dedicated link between them for synchronisation.
  3. CARP addresses — Network → Virtual IPs on each interface clients use. Clients point at the CARP address, never at a node's own.
  4. State synchronisation over the dedicated link, so connections survive a failover.
  5. Configuration synchronisation — High Availability → Settings, on the master only, pointed at the backup.
  6. Test the failover: reboot the master and watch High Availability → Status on the backup. Then fail back.

A pair that has never been failed over on purpose has not been tested.

DNS blocklists

Block advertising, tracking and known-malicious domains, network-wide.

Services → Unbound DNS → Blocklists: subscribe to the lists you want, add your own entries, and save. Clients that use the appliance as their resolver are covered with nothing to install.

Two caveats worth knowing: a client using its own DNS-over-HTTPS resolver bypasses this entirely (block or redirect outbound DNS if that matters), and a blocklist will eventually break a site someone needs — keep an allow list and tell people how to ask.

Previous5.12 PowerNext7. Maintenance