Skip to content

Network Architecture

Overview

The live network is centered on OPNsense VM 100 router as the routing and policy boundary. The only currently validated internal service segment is the DMZ/server network 192.168.2.0/24. Older pfSense references and the old 192.168.100.0/24 LAN material remain historical until recaptured from OPNsense.

The current upstream hardware stack includes a Starlink Gen 3 dish and a Wi-Fi 6 router; the exact handoff mapping to the OPNsense WAN interfaces still needs a final capture.

Office network diagram /// caption Office network diagram retained from the repository. Use the verified segment table below as the source of truth. ///

Segments

Segment CIDR Gateway Purpose
WAN1 10.0.0.0/24 10.0.0.1 Primary upstream circuit
WAN2 192.168.1.0/24 192.168.1.1 Secondary upstream circuit
DMZ 192.168.2.0/24 192.168.2.1 Service and server network

Deprecated 192.168.100.0/24 References

Do not treat 192.168.100.0/24 as a current internal LAN or Headscale subnet route without a fresh OPNsense export/UI validation. On 2026-07-01, validation from pve showed:

  • 192.168.100.1 answered as SpaceX User Terminal over SSH and returned Starlink web UI content over HTTP.
  • 192.168.100.250, formerly documented as the Synology NAS, did not respond to ping from pve.

The user confirmed the cause on 2026-07-01: Starlink was moved to bridge mode, and Starlink's use of 192.168.100.0/24 conflicted with the old internal .100 LAN, so KH3 changed the internal subnet away from that range.

The current client/admin LAN CIDR is therefore a configuration gap, not 192.168.100.0/24 by default.

Verified Addressing

Updated June 30, 2026: service hosts are configured to use DHCP on their interfaces, with stable addresses supplied by OPNsense Dnsmasq reservations. Treat the addresses below as reserved service addresses, not necessarily static IP configuration inside each guest. If a reservation is removed or mismatched, the service may lease a different address or lose IPv4 entirely.

Host Address Notes
Proxmox host pve 192.168.2.10/24 DMZ management address; reserved in OPNsense/Dnsmasq
Rootless Podman CT 101 192.168.2.20/24 Live DHCP reservation/lease on July 1, 2026; restored application services on high ports
Technitium DNS CT 102 192.168.2.2/24 DHCP reservation; replaces the historical Pi-hole/Cloudflared resolver address
Caddy ingress CT 103 192.168.2.3/24 DHCP reservation; terminates HTTP/HTTPS and proxies to CT 101 high ports
khysite CT 104 192.168.2.5/24 DHCP reservation; running separate site workload; needs full service documentation
Subnet-router CT 105 ts-router 192.168.2.120/24 DHCP lease on DMZ; dedicated Headscale/Tailscale subnet router; reserve in OPNsense/Dnsmasq if not already reserved
OPNsense DMZ interface 192.168.2.1/24 Active policy boundary; interface details pending recapture

Proxmox Bridges

Bridge Physical NIC Notes
vmbr0 enp0s31f6 VLAN-aware; carries the OPNsense LAN-side/DMZ path
vmbr1 enp1s0f0 Historical pfSense WAN1 attachment; recapture OPNsense mapping
vmbr2 enp1s0f1 Historical pfSense WAN2 attachment; recapture OPNsense mapping

Core Services

Service Host Address Notes
Firewall OPNsense VM 100 router 192.168.2.1 on DMZ; WAN/LAN details pending recapture Active router and policy boundary
DNS CT 102 technitium-dns 192.168.2.2 Replaces Pi-hole/Cloudflared; see Caddy and Technitium Migration
Ingress CT 103 caddy-ingress 192.168.2.3 Caddy with Cloudflare DNS-01 and security module
Apps CT 101 podman-lxc 192.168.2.20 Rootless Podman services on high ports
Site CT 104 khysite 192.168.2.5 Current role needs fuller documentation
Tailnet subnet router CT 105 ts-router 192.168.2.120 and tailnet 100.64.0.3 Serves Headscale route 192.168.2.0/24 with Tailscale SNAT enabled
Logs Logging target pending recapture formerly 192.168.2.20:5140 Confirm OPNsense remote syslog destination during migration

Traffic Handling

DNS

  • LAN clients should be pointed at Technitium 192.168.2.2 after migration
  • DMZ DHCP reservations are managed through OPNsense Dnsmasq after the June 30, 2026 change; keep reserved infrastructure addresses out of dynamic pools
  • On July 1, 2026, CTs 101 through 105 on the DMZ were receiving DHCP DNS option 192.168.2.1; CTs 101 through 104 were locally mitigated with dhclient.conf superseding DNS to 192.168.2.2, matching CT 105. The OPNsense Dnsmasq global fix is still to set DHCP option 6 for the DMZ interface to 192.168.2.2 and then renew leases one host at a time.
  • OPNsense should enforce DNS redirection or blocking on client VLANs
  • Direct DNS access to any non-Technitium resolver should be blocked or redirected except approved infrastructure exceptions
  • DoT and practical DoH bypass controls are part of the OPNsense policy plan

Web and App Traffic

  • Caddy is the target replacement for Traefik and should terminate HTTP and HTTPS on 80 and 443
  • Historical notes say pfSense redirected LAN HTTP/HTTPS traffic to Squid at 192.168.2.60:3129; confirm whether OPNsense should retain any transparent proxy behavior.
  • Historical app routes previously published through Traefik and to be recreated in Caddy include:
  • drone.kh3group.com
  • mgmt.kh3group.com
  • dbgui.kh3group.com
  • mongodb.kh3group.com
  • ims.kh3group.com
  • pdf.kh3group.com
  • receipt.kh3group.com
  • website.kh3group.com
  • kh3.kh3group.com
  • khy.kh3group.com
  • khysite.kh3group.com
  • docs.kh3group.com

Remote Access

  • WireGuard ingress is allowed on UDP 51420
  • The WireGuard subnet 172.16.16.0/24 is translated out through hybrid outbound NAT
  • WireGuard status and startup behavior must be recaptured from OPNsense
  • Headscale/Tailscale access to the DMZ uses CT 105 ts-router, which serves only 192.168.2.0/24. Do not advertise broad private ranges or 192.168.100.0/24.

Firewall Policy Shape

Interface Policy Shape
WAN Inbound WireGuard allowed; everything else remains externally constrained
LAN Default allow exists, plus alias-based rules for admin and service access
DMZ A permissive allow-all rule is present

Routing Notes

  • Default IPv4 gateway is the WANFailOver gateway group
  • The group contains WAN1GW and WAN2GW
  • Trigger mode is downlosslatency

Alias Groups

Alias Type Use
AdminPCs host Admin workstations
ClientDMZ host Selected DMZ hosts
DNSPorts port DNS-related ports
SPStack host SharePoint-related hosts
WANPCs host WAN-side workstation group
InternalDNS host 192.168.2.2; replace historical PiHole alias during migration
http_s port 80 and 443
kh3websiteteam host Website collaboration group

Configuration Gaps

  • WAN provider names and ownership
  • Current client/admin LAN CIDR and DHCP scope
  • Whether Squid remains the intended transparent proxy
  • Whether DMZ should remain permissive or be segmented further
  • Whether additional VLANs are planned beyond the current LAN and DMZ
  • Current NAS address and route, replacing stale 192.168.100.250 references
  • Confirm and reserve final Dnsmasq host mappings for CT 105; 192.168.2.15 and 192.168.2.25 did not answer ping from pve on July 1, 2026, but OPNsense leases must be checked before reuse

Operational Procedures

  • Check gateways and interfaces in OPNsense.
  • Test DNS with dig @192.168.2.2 example.com.
  • When changing DHCP reservations, confirm Technitium still has 192.168.2.2 before judging LAN internet access.
  • Test a DMZ host by IP before testing its hostname.
  • Record every firewall, VLAN, DHCP, or static-address change on this page.

Troubleshooting

  • No internet for all clients: check OPNsense gateways and upstream hardware.
  • IP access works but names fail: check Technitium and OPNsense DNS redirection. On June 30, 2026, LAN clients lost name resolution after the DMZ interface was added to Dnsmasq and DHCP reservations were changed; 1.1.1.1 was reachable, but 192.168.2.2:53 timed out because CT 102 technitium-dns no longer had its expected IPv4 address.
  • One published app fails: check Caddy and the CT 101 target service.
  • DMZ host unreachable: check VLAN tag 2, bridge vmbr0, and firewall policy.

References

  • Historical redacted pfSense configuration and runtime inventory, June 2026
  • OPNsense identity verified with ssh router on June 22, 2026
  • 192.168.100.1 identified as Starlink, not OPNsense LAN, from pve on July 1, 2026