Skip to content

OPNsense Firewall

Current State

The active firewall is OPNsense, not pfSense.

Verified on June 22, 2026:

  • Proxmox VM: 100 router
  • SSH alias: ssh router
  • SSH-reported hostname: OPNsense.internal
  • Kernel: FreeBSD 14.3 release line as reported by uname -a
  • Role: perimeter firewall, router, DHCP/NAT policy point, and DNS enforcement point

The repository still contains pfSense documentation and redacted pfSense exports as historical recovery material. Do not use those references as the source of truth for new firewall changes unless explicitly restoring an old pfSense state.

Validation update on July 1, 2026:

  • ssh pvessh verified VM 100 router is running.
  • Proxmox pve has 192.168.2.10/24 on vmbr0.2 and its default route via 192.168.2.1.
  • QEMU guest agent is not configured for VM 100 router; qm guest exec 100 cannot be used for OPNsense inspection.
  • From pve, 192.168.2.1 resolves at layer 2 to the router VM's virtio MAC, but ICMP/SSH/HTTP/HTTPS to that address were blocked or timed out.
  • 192.168.100.1 is Starlink, not the current OPNsense LAN gateway. Do not use 192.168.100.0/24 as current LAN documentation without a fresh OPNsense export or UI validation.
  • User-confirmed context: Starlink was moved to bridge mode, and Starlink's 192.168.100.0/24 use conflicted with KH3's old internal .100 subnet.

Implemented Migration State

As recorded during the Caddy/Technitium work:

  • Active DHCP service is Dnsmasq.
  • LAN Dnsmasq DHCP option 6 was set to 192.168.2.2.
  • On June 30, 2026, Dnsmasq was also enabled for the DMZ interface so DMZ infrastructure hosts can use DHCP reservations instead of in-guest static IP configuration.
  • Technitium at 192.168.2.2 resolved internal records such as git.kh3group.com -> 192.168.2.3.
  • Public HTTP/HTTPS ingress is intended to terminate on Caddy CT 103 at 192.168.2.3.
  • Client DNS bypass enforcement is still pending unless a later change record says otherwise.

Validation update later on July 1, 2026:

  • DMZ DHCP leases for CTs 101 through 105 carried DNS option domain-name-servers 192.168.2.1, not 192.168.2.2.
  • The affected CTs could route to public IPs, but name resolution through 192.168.2.1 hung or failed. This caused package installation to appear like an internet failure even though IPv4 egress was working.
  • CTs 101 through 104 were locally mitigated by adding supersede domain-name-servers 192.168.2.2; to /etc/dhcp/dhclient.conf and writing nameserver 192.168.2.2 to /etc/resolv.conf. CT 105 already had that mitigation.
  • After the mitigation, CTs 101 through 105 resolved deb.debian.org and vpn.kh3group.com; IPv4 HTTP checks to deb.debian.org succeeded.
  • The still-needed OPNsense fix is to set Dnsmasq DHCP option 6 for the DMZ interface to 192.168.2.2, then renew DMZ leases one host at a time and remove per-CT DNS overrides after validation.

Migration Responsibilities

OPNsense is the policy point for the Caddy and Technitium migration:

  • Route LAN, DMZ, VPN, and WAN traffic.
  • Hand out Technitium DNS at 192.168.2.2 through DHCP where applicable.
  • Redirect or block client DNS bypass attempts.
  • Block or control DNS over TLS on 853/tcp.
  • Maintain practical DNS over HTTPS controls using aliases, blocklists, and endpoint/device policy.
  • Forward public HTTP/HTTPS traffic to Caddy after Caddy is deployed.
  • Restrict admin surfaces such as Technitium console, Dozzle, and Adminer until OIDC, VPN, or source-IP rules are validated.
  • Preserve break-glass access for approved admin and recovery hosts.

See Caddy and Technitium Migration for the staged plan.

Change Rules

Before changing OPNsense:

  1. Export the current OPNsense configuration from the UI.
  2. Store raw exports outside the documentation repository.
  3. Redact any shareable export before committing it.
  4. Change one alias, NAT rule, firewall rule, DHCP option, or port forward at a time.
  5. Validate gateway health, DNS, Caddy ingress, and CT 101 app reachability after each change.
  6. After DHCP reservation changes, verify reserved DMZ services still hold the expected addresses, especially Technitium at 192.168.2.2.

Validation

From the administration workstation:

ssh pvessh 'qm list | grep router'
ssh pvessh 'qm config 100'

Use ssh router 'hostname; uname -a' only when a working local router SSH alias has been confirmed. In this workspace on July 1, 2026, there was no router entry in /home/papa/.ssh/config.

After Technitium is live:

dig @192.168.2.2 example.com
dig @1.1.1.1 example.com
nc -vz 1.1.1.1 853

The direct Technitium query should succeed. External DNS and DoT tests should be redirected or blocked according to the final OPNsense rules.

If LAN clients report "no internet" but direct IP tests work, check DNS first. During the June 30, 2026 Dnsmasq DMZ/reservation change, the failure mode was:

  • OPNsense gateway 192.168.2.1 was reachable.
  • Public IP connectivity, such as 1.1.1.1, worked.
  • Queries to 192.168.2.2:53 timed out.
  • CT 102 technitium-dns was running but had lost its expected IPv4 address.

Restoring the Technitium reservation/address restored DNS for clients using DHCP option 6 = 192.168.2.2.

If DMZ hosts have IP connectivity but package installs or name lookups hang, check the lease for option domain-name-servers 192.168.2.1. That indicates the DMZ Dnsmasq option 6 setting is still missing or not applied.