Proxy Management & Cloudflare Tunnels#

What Was Established#

There are multiple layers of proxying available in the homelab, ranging from edge protection (Cloudflare) to local routing (OPNsense/Nginx Proxy Manager).

Nginx Proxy Manager (NPM) Troubleshooting#

• Redirect Loops & Timeouts: Often caused by misconfigured upstream servers or aggressive timeout settings in NPM’s web UI. Resolving a redirect loop may expose underlying connectivity issues that manifest as timeouts.
• Docker Compose Pattern: NPM is deployed with network_mode: host to bind directly to host ports (80, 443, 81), bypassing Docker’s NAT for direct host network access.
• Verification Steps:
  1. Check container health: docker ps | grep nginx-proxy-manager (ensure healthy status).
  2. Verify port bindings: sudo netstat -tulpn | grep :80 / :443 (requires net-tools package).
  3. Inspect NPM Web UI: Access at http://<host-ip>:81 to review Proxy Host settings, specifically timeout values and upstream server addresses.
• Port Conflicts: Use netstat to identify which container owns a specific port (e.g., docker-proxy vs nginx: master). In this setup, port 8000 was observed bound to docker-proxy, indicating another service in the compose stack.
• Co-located Services: The same Docker Compose stack hosts cloudflare-ddns (for dynamic IP updates) and netbird (for mesh networking), requiring careful port management to avoid conflicts.

Key Decisions#

• Use network_mode: host for NPM to simplify port mapping and ensure direct access to host network interfaces.
• Rely on net-tools (netstat) for quick port binding verification in host-networked Docker containers.

Current Configuration#

• Docker Host: iluvatar@proxy (192.168.1.208)
• NPM Web UI: http://192.168.1.208:81
• Ports: 80 (HTTP), 443 (HTTPS), 81 (NPM Admin UI)

Historical Notes#

• Troubleshooting session from 2025-11-17 resolved a redirect loop that subsequently turned into a timeout issue.
• net-tools installation was required to diagnose port bindings on the host.

Open Questions#

• Specific timeout values configured in NPM for upstream services.
• Whether netbird or cloudflare-ddns requires dedicated port exposure or can share the host network.

Related Pages#

• Cloudflare Integration: SSL & DNS
• OPNsense DMZ Firewall Rules for IoT
• Docker Host Configuration

Uptime Kuma - Configuration & Integrations

OPNsense DMZ Firewall Rules for IoT#

What Was Established#

A structured firewall rule set for isolating IoT devices in a DMZ zone. The rules enforce a “high-to-low trust” flow, ensuring IoT devices can reach the internet for cloud services while preventing them from initiating connections to the trusted LAN. This pattern is critical for preventing lateral movement from compromised IoT devices.

Key Decisions#

• Explicit Allow / Implicit Deny: Only allow necessary outbound traffic (HTTP/HTTPS, DNS, NTP) from DMZ to WAN.
• Strict Containment: Explicitly block all DMZ-initiated traffic to the LAN zone.
• Controlled LAN Access: Default deny for LAN-to-DMZ, with specific allow rules only for administration or required services.
• WAN Isolation: Block all unsolicited inbound traffic from WAN to DMZ.

Current Configuration#

Note: The homelab currently uses VLANs (Gandalf 192.168.1.x, Mithrandir 192.168.2.x, Tharkûn 192.168.3.x, Rivendell 192.168.4.x) managed by a UniFi Express gateway (“Olorín”, 192.168.1.1). These OPNsense zone-based rules should be adapted to the homelab’s VLAN structure or applied to a dedicated IoT VLAN (e.g., 192.168.50.x).

OPNsense Interface Reassignment & NIC Troubleshooting#

What Was Established#

Procedures for reassigning WAN/LAN interfaces via the OPNsense console following a system upgrade, and troubleshooting connectivity loss after a physical NIC replacement.

Key Decisions#

• Console-Based Reassignment: Use the OPNsense console menu (1. Assign Interfaces) to map physical ports to WAN/LAN roles.
• Network-Only Reset: If configuration is lost, use 2. Reset to factory defaults and select “Reset only the network configuration” to preserve other settings.
• Manual Config Edit: Fallback to vi /conf/config.xml to manually adjust <interfaces> tags (<wan>, <lan>) if the menu fails.
• NIC Troubleshooting Workflow: Verify driver recognition (vmstat -i), link status (ifconfig), and system logs (dmesg). Check NAT/Outbound and LAN firewall rules. Isolate hardware issues by reverting to the original NIC.

Current Configuration#

• Gateway: UCG Express “Olorín” (OPNsense) at 192.168.1.1.
• VLANs: Gandalf (192.168.1.x), Mithrandir (192.168.2.x), Tharkûn (192.168.3.x), Rivendell (192.168.4.x).
• Switch: Netgear MS308E (trunk/access VLANs managed via OPNsense).

Historical Notes#

• Procedures documented for OPNsense upgrades where interface assignments reset.
• Troubleshooting steps refined for scenarios involving physical NIC swaps (e.g., 2.5GbE to 1GbE) causing interface loss.
• Note: Driver support (Intel igb/em, Realtek) and firmware updates may be required for newer NICs.

Open Questions#

• Specific driver requirements for the current UCG Express “Olorín” gateway NICs.
• Automation of interface reassignment to prevent manual console steps during future upgrades.

Related Pages#

• OPNsense DHCP Configuration
• VLAN Configuration: OPNsense & Netgear MS308E
• Troubleshooting Network Interface Changes
• Network Infrastructure & VLANs

Sources#

• ingested/chats/034-Reassign WAN and LAN on OPNsense Post-Upgrade.md
• Historical DeepSeek conversation on OPNsense console interface reassignment and NIC troubleshooting.

OPNsense DHCP Configuration#

What Was Established#

Procedures for modifying DHCPv4 ranges and identifying other network segments where IP assignment ranges must be managed to prevent conflicts.

Key Decisions#

• DHCP Scope Management: Always ensure static leases or reserved IPs (like Proxmox) are excluded from the dynamic DHCP range to prevent IP conflicts.
• Subnet Alignment: DHCP ranges must reside within the defined subnet (e.g., /24 for 192.168.0.0/24).

Current Configuration#

DHCPv4 Modification#

1. Navigate to Services → DHCPv4 → [Interface].
2. Under General DHCP Options, set the Range (Start and End IP).
3. Save and Apply.

Other Assignment Areas to Monitor#

• DHCPv6: Found under Services → DHCPv6 → [Interface].
• VPNs:
  • OpenVPN: VPN → Open/IPsec → [Server] (Tunnel Network).
  • WireGuard: Manual assignment per peer.
• VLANs: Each VLAN interface requires its own DHCP scope.

Historical Notes#

As of March 2025, this covers the standard DHCPv4/v6 setup for the LAN and VLAN interfaces.

VLAN Configuration: OPNsense & Netgear MS308E#

What Was Established#

Configuration pattern for implementing tagged (trunk) and untagged (access) VLANs using OPNsense as the router and a Netgear MS308E managed switch.

Key Decisions#

• VLAN Naming/ID: Example VLAN “Incánus” assigned ID 20.
• Trunking Strategy: The port connecting OPNsense to the Netgear switch must be configured as a Tagged port for all active VLANs.
• Access Port Strategy: Ports for end-devices must be Untagged for the specific VLAN, with the PVID (Port VLAN ID) set to match that VLAN.

Current Configuration#

OPNsense Setup#

1. Create VLAN: Interfaces → Other Types → VLAN (Assign Parent Interface and Tag ID).
2. Assign Interface: Interfaces → Assignments (Add the new VLAN interface).
3. Configure IP: Set a static IPv4 address (e.g., 192.168.20.1/24 for VLAN 20).
4. DHCP: Enable DHCPv4 under Services → DHCPv4 → [VLAN Interface].

Netgear MS308E Setup#

1. VLAN Membership:
   • Trunk Port (to OPNsense): Set as Tagged for all VLANs (e.g., VLAN 20, 30).
   • Access Port (to Device): Set as Untagged for the target VLAN.
2. PVID Configuration:
   • For Access Ports, the PVID must be updated to match the VLAN ID (e.g., Port 1: PVID 20).

Historical Notes#

Configuration established during the rollout of the “Incánus” network segment.