Networking on homelab

Mobile Hotspot & Proton VPN Troubleshooting

Fri, 01 May 2026 00:00:00 +0000

Mobile Hotspot & Proton VPN Troubleshooting#

What Was Established#

A PC connected to a mobile hotspot will always display a local/private IP address (e.g., 192.168.43.x) to communicate with the phone acting as the gateway/router.
Enabling Proton VPN on the mobile device does not automatically extend the encrypted tunnel to connected hotspot devices by default. This is due to app-level vs. system-level routing, separate network interfaces, and carrier/OS restrictions.
Public IP verification and DNS leak tests are required to confirm whether hotspot traffic is actually being routed through the VPN tunnel.

Key Decisions#

Local IP vs Public IP: Local IPs are expected and required for LAN communication; privacy and security are determined by the public IP and DNS resolution, not the local address.
VPN Extension Methods:
- Enable “Always-on VPN” and “VPN passthrough” in the phone’s hotspot/tethering settings.
- Install Proton VPN directly on the PC for guaranteed tunneling, kill switch functionality, and split tunneling control.
- Use USB tethering instead of Wi-Fi hotspot if Wi-Fi passthrough fails or is blocked by the carrier.
Order of Operations: Disabling and re-enabling the hotspot after establishing the VPN connection can force the routing table to update and apply the tunnel correctly.

Current Configuration#

N/A (General networking troubleshooting pattern applicable to remote management of homelab infrastructure like Isengard (192.168.1.69) or Legolas (192.168.1.45) via mobile data).

Historical Notes#

Conversation dated 2025-12-13.
Proton VPN mobile app behavior varies significantly by OS (iOS/Android) and mobile carrier; some devices natively block VPN over hotspot.
This pattern is relevant for remote homelab administration or travel scenarios where mobile data serves as the primary internet source.

Open Questions#

Does the specific mobile carrier or OS version in use support native VPN passthrough for hotspots without third-party apps?
Are there specific Proton VPN mobile app settings that consistently bypass carrier restrictions for tethering?

Sources#

ingested/chats/130-PC Local IP While Hotspot with VPN.md
DeepSeek conversation: PC Local IP While Hotspot with VPN (2025-12-13)

Proxy Management & Cloudflare Tunnels

Fri, 01 May 2026 00:00:00 +0000

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.

Uptime Kuma - Configuration & Integrations

OPNsense DMZ Firewall Rules for IoT

Thu, 30 Apr 2026 00:00:00 +0000

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).

UniFi Express VPN & Network Management

Thu, 30 Apr 2026 00:00:00 +0000

UniFi Express VPN & Network Management#

What Was Established#

Methodology for configuring ProtonVPN WireGuard on UniFi Express.
Kill switch implementation to prevent IP/DNS leaks when the VPN drops.
Best practices for managing Netgear managed switches via dedicated subnets and secure ports.

Key Decisions#

WireGuard Protocol: Selected over OpenVPN for superior speed and efficiency on UniFi Express.
Kill Switch Pattern: Default-deny WAN traffic; only allow forwarding through the wg0 interface.
Netgear Management: Restrict switch web GUI access to a dedicated management VLAN/subnet using HTTPS.

Current Configuration#

VPN Client: ProtonVPN (WireGuard)
Endpoint: us-123.protonvpn.net:51820 (example high-speed server)
ProtonVPN DNS: 10.2.0.1
Allowed IPs: 0.0.0.0/0 (full tunnel)
Netgear Switch Management Ports:
- HTTP: 80 (insecure, avoid)
- HTTPS: 443 (secure web GUI)
- SSH: 22 (CLI access)
- SNMP: 161 (monitoring)

Historical Notes#

Conversation dated 2025-04-14.
Gateway device referred to as UniFi Express (infrastructure list notes “UCG Express ‘Olorín’ at 192.168.1.1”).
Netgear MS308E is the managed switch in the homelab.
Kill switch and DNS leak prevention rely on iptables/nftables or UniFi OS firewall rules.

Open Questions#

Does UniFi Express support native WireGuard kill switch in the GUI, or is manual CLI firewall configuration required?
Specific UniFi OS version and exact GUI paths for VPN/kill switch implementation.
Whether split tunneling is needed for specific homelab services.

Uptime Kuma - Configuration & Integrations

UniFi UX7 & Netgear MS308E VLAN Setup

Thu, 30 Apr 2026 00:00:00 +0000

UniFi UX7 & Netgear MS308E VLAN Setup#

What Was Established#

Multi-switch VLAN topology using UniFi UCG Express (UX7) and Netgear MS308E switches.
Netgear MS308E 802.1Q Advanced configuration pattern for trunks and access ports.
Troubleshooting methodology for multi-switch chains (isolate to inter-switch trunks vs. device-specific vs. firewall).
UX7 firewall rule correction for IoT isolation (Tharkûn VLAN 3).

Key Decisions#

VLAN 1 (Gandalf): Untagged on trunks, PVID 1. Used for servers and switch management.
VLAN 2 (Mithrandir): Tagged on trunks, Untagged on access. PVID 2. Routes through UX7 VPN.
VLAN 3 (Tharkûn): Tagged on trunks, Untagged on access. PVID 3. Isolated IoT network.
Native VLAN set to 1 on trunks to ensure management traffic passes untagged and remains accessible.
UX7 Firewall: Tharkûn (VLAN 3) placed in DMZ zone. Required explicit “Allow DMZ to Internet” rule to restore IoT connectivity.

Current Configuration#

UX7 (Olorín): 192.168.1.1
- Port 1 (to Netgear Switch 1): Trunk, Native VLAN 1, Allowed VLANs 1, 2, 3.
Netgear MS308E (Switch 1): 192.168.1.239
- Port 1 (to UX7): VLAN 1 Untagged (PVID 1), VLAN 2 Tagged, VLAN 3 Tagged.
- Ports 2, 3 (to downstream switches): Same as Port 1.
- Access Ports (e.g., Port 8 to U7 AP): VLAN 3 Untagged, PVID 3.
Netgear MS308E (Switch 2):
- Trunk ports: VLAN 1 Untagged (PVID 1), VLAN 2 Tagged, VLAN 3 Tagged.
- Access Ports: VLAN 2 Untagged (PVID 2) for PCs, VLAN 3 Untagged (PVID 3) for IoT (e.g., Hue Hub).
UX7 Firewall Rules (Tharkûn/DMZ):
- Allow DMZ to Internet
- Allow DMZ to Gateway
- Block DMZ to Internal
- Block DMZ to VPN

Historical Notes#

Initial attempts to set trunk ports to “No Native VLAN” (all tagged) caused lockout because management traffic (VLAN 1) became untagged and was dropped. Reverted to Native VLAN = 1.
VLAN 2 (Mithrandir) initially failed on downstream switches due to missing tagged configuration on inter-switch trunks.
VLAN 3 (Tharkûn) failed due to missing firewall rule in UX7 Site Manager for the DMZ zone.

Open Questions#

How to handle Rivendell (VLAN 4) when deployed?
Will U7 APs require specific VLAN tagging configurations for Tharkûn WiFi?

wiki/networking/vlan_setup.md (Legacy OPNsense context)
wiki/infrastructure/network.md
wiki/networking/opnsense_dmz_iot_firewall.md

Uptime Kuma - Configuration & Integrations

OPNsense Interface Reassignment & NIC Troubleshooting

Mon, 27 Apr 2026 00:00:00 +0000

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.

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

Tue, 25 Mar 2025 00:00:00 +0000

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#

Navigate to Services → DHCPv4 → [Interface].
Under General DHCP Options, set the Range (Start and End IP).
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

Tue, 25 Mar 2025 00:00:00 +0000

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#

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

Netgear MS308E Setup#

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.
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.

Networking on homelab

Mobile Hotspot & Proton VPN Troubleshooting

Mobile Hotspot & Proton VPN Troubleshooting#

What Was Established#

Key Decisions#

Current Configuration#

Historical Notes#

Open Questions#

Related Pages#

Sources#

Proxy Management & Cloudflare Tunnels

Proxy Management & Cloudflare Tunnels#

What Was Established#

Nginx Proxy Manager (NPM) Troubleshooting#

Key Decisions#

Current Configuration#

Historical Notes#

Open Questions#

Related Pages#

OPNsense DMZ Firewall Rules for IoT

OPNsense DMZ Firewall Rules for IoT#

What Was Established#

Key Decisions#

Current Configuration#

UniFi Express VPN & Network Management

UniFi Express VPN & Network Management#

What Was Established#

Key Decisions#

Current Configuration#

Historical Notes#

Open Questions#

Related Pages#

UniFi UX7 & Netgear MS308E VLAN Setup

UniFi UX7 & Netgear MS308E VLAN Setup#

What Was Established#

Key Decisions#

Current Configuration#

Historical Notes#

Open Questions#

Related Pages#

OPNsense Interface Reassignment & NIC Troubleshooting

OPNsense Interface Reassignment & NIC Troubleshooting#

What Was Established#

Key Decisions#

Current Configuration#

Historical Notes#

Open Questions#

Related Pages#

Sources#

OPNsense DHCP Configuration

OPNsense DHCP Configuration#

What Was Established#

Key Decisions#

Current Configuration#

DHCPv4 Modification#

Other Assignment Areas to Monitor#

Historical Notes#

VLAN Configuration: OPNsense & Netgear MS308E

VLAN Configuration: OPNsense & Netgear MS308E#

What Was Established#

Key Decisions#

Current Configuration#

OPNsense Setup#

Netgear MS308E Setup#

Historical Notes#