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

SSH Host Key Management & Troubleshooting

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

SSH Host Key Management & Troubleshooting#

What Was Established#

Standard procedures for resolving SSH REMOTE HOST IDENTIFICATION HAS CHANGED warnings, which occur when a host’s SSH fingerprint differs from the locally stored known_hosts entry. This typically happens after a server reinstall, OS upgrade, or SSH key regeneration.

Key Decisions & Commands#

Verify Legitimacy: Always confirm with a system administrator or check server logs if a key change is unexpected, as it could indicate a man-in-the-middle attack.
Remove Stale Keys: Use ssh-keygen -R <hostname> to safely remove the outdated entry from ~/.ssh/known_hosts.
Targeted Removal: If the error specifies a line number (e.g., line 9), you can remove it via sed -i '' '9d' ~/.ssh/known_hosts or manually edit the file.
Pre-populate Keys: In managed environments, use ssh-keyscan <host> >> ~/.ssh/known_hosts to automate key acceptance.
Security Best Practice: Prefer certificate-based authentication in sensitive environments to bypass host key checking entirely.

Current Configuration#

Host Encountered: proxy (192.168.1.222, Nginx Proxy Manager)
User Context: Commands executed from macOS (NK---Galadriel) as user natekelley.
Fingerprint Example: SHA256:k5j8V356rpQXapznIs12MeBEWHfZYwfeicXdNNWFyOI (ED25519)

Historical Notes#

Initial troubleshooting documented on 2025-11-17. The proxy host likely had its underlying VM/container rebuilt or its SSH configuration reset, triggering the warning.

Open Questions#

Should SSH host keys be version-controlled or managed via a configuration management tool (e.g., Ansible) to prevent future mismatches?

Sources#

ingested/chats/111-Check and Install Git, Go, Dart Sass on Ubuntu.md
ingested/chats/104-SSH Host Key Change Warning and Fix.md
Historical DeepSeek conversation: SSH Host Key Change Warning and Fix (2025-11-17)

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

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.

Pavilion (AI PC) Configuration

Sun, 26 Apr 2026 00:00:00 +0000

Pavilion (AI PC) Configuration#

What Was Established#

The Pavilion machine uses a USB-based or specific Ethernet interface (enx6c1f7197a66) that occasionally fails to bring the link up automatically on boot.

Current Configuration#

Netplan Configuration#

Ensure /etc/netplan/01-netcfg.yaml is correctly configured with the active interface name and permissions are set to 600.

network:
  version: 2
  ethernets:
    enx6c1f7197a66:
      dhcp4: true

Apply with:

sudo chmod 600 /etc/netplan/01-netcfg.yaml
sudo netplan apply

Boot-time Interface Fix#

If the interface remains DOWN after reboot, use a systemd service to force the link up.

Network Infrastructure & VLANs

Tue, 14 Apr 2026 00:00:00 +0000

Network Infrastructure & VLANs#

What Was Established#

The network uses a UniFi UCG Express with a multi-VLAN setup. A recent incident involving a VPN expiry caused a routing failure on specific VLANs due to policy-based routing (PBR) without a fallback mechanism.

Key Decisions#

VLAN Segmentation:
- Gandalf: Server network (Always-on, stable, no VPN).
- Mithrandir (VLAN 2): Client/AI network. Traffic is routed through ProtonVPN via WireGuard.
- Harken (VLAN 3): General usage.
- Tharkûn (DMZ): Restricted zone (DMZ $\rightarrow$ Internal is Blocked).
- Rivendell (VLAN 4): Unused.
VPN Configuration: ProtonVPN WireGuard Client 1 is used for Mithrand/VLAN 2. Critical: Ensure “Block traffic if WireGuard is down” is enabled to prevent IP leaks.
IP Management: Use DHCP Reservations (Fixed IPs) in the UniFi Controller rather than configuring static IPs on individual hosts to prevent port-forward breakage during DHCP lease renewals.

Current Configuration#

Known Fixed IPs (DHCP Reservations):

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.

Proxmox Network Troubleshooting

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

Proxmox Network Troubleshooting#

What Was Established#

Troubleshooting steps for resolving connectivity loss to Proxmox nodes, specifically addressing IP conflicts and subnet mismatches.

Key Decisions#

Static IP Reservation: Proxmox nodes should always have a static IP (e.g., 192.168.0.69) that is excluded from the OPNsense DHCP pool.

Current Configuration#

Troubleshooting Workflow#

Verify Connectivity: ping 192.168.0.69.

Check Local Config: Log in via console and verify /etc/network/interfaces:

auto vmbr0
iface vmbr0 inet static
    address 192.168.0.69/24
    gateway 192.168.0.1
    bridge-ports enp3s0

Check for IP Conflicts: Ensure no other device (via DHCP) has been assigned 192.168.0.69.
ARP Cache: Clear local ARP cache if IP conflicts are suspected: arp -d 192.168.0.69.

Historical Notes#

Identified an issue where a DHCP client was assigned 192.168.0.69, conflicting with the Proxmox static IP.

Proxmox Network Configuration

Sun, 23 Mar 2025 00:00:00 +0000

Proxmox Network Configuration#

What Was Established#

Procedures for manually updating the IP address and network interface settings on a Proxmox VE host via the command line.

Key Decisions#

Network configuration is managed via the /etc/network/interfaces file. When changing network parameters, the Linux bridge (vmbr0) must be updated to point to the correct physical interface.

Current Configuration#

To modify the IP, gateway, or interface, edit the configuration file:

nano /etc/network/interfaces

Example of a static configuration for a bridge interface:

Troubleshooting Network Interface Changes

Sun, 23 Mar 2025 00:00:00 +0000

Troubleshooting Network Interface Changes#

What Was Established#

When replacing a physical Network Interface Card (NIC)—for example, swapping a 2.5GbE card for a 1GbE card—the system will lose connectivity if the software configuration still references the old interface name.

Key Decisions#

Connectivity loss after a hardware swap is usually due to a mismatch in the bridge-ports setting within the network configuration. The new NIC will likely have a different kernel interface name (e.g., changing from enp0s1 to enp0s2).

Wi-Fi Performance Optimization (U7 Lite)

Mon, 01 Jan 0001 00:00:00 +0000

Wi-Fi Performance Optimization (U7 Lite)#

What Was Established#

Diagnostic steps for addressing throughput discrepancies between wired (1 Gbps) and wireless (300 Mbps) connections on Wi-Fi 6/6E hardware.

Key Decisions#

Channel Width: For high-speed Wi-Fi 6/6E, utilize 80 MHz or 160 MHz channel widths on the 5 GHz/6 GHz bands.
Band Steering: Disable Band Steering if it causes frequent client roaming/drops.

Current Configuration#

Optimization Steps#

Verify Link Speed: Check client-side PHY rates (e.g., netsh wlan show interfaces on Windows) to ensure the client is connecting via 5 GHz/6 GHz.
AP Settings (Unifi/Ubiquiti):
- Mode: Set to HE (Wi-Fi 6) or EHT (Wi-Fi 7).
- Channel Width: Set to 80 MHz or 160 MHz.
- Minimum Data Rate: Set to 24 Mbps to disable legacy (802.11b/g) rates.
Client-Side: Disable Wi-Fi Power Saving mode on Linux clients:
```
iw dev wlan0 set power_save off
```

Historical Notes#

Addressed a specific case where a U7 Lite was capped at 300 Mbps due to potential client-side or channel width limitations.

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#

SSH Host Key Management & Troubleshooting

SSH Host Key Management & Troubleshooting#

What Was Established#

Key Decisions & Commands#

Current Configuration#

Historical Notes#

Open Questions#

Related Pages#

Sources#

UniFi Express VPN & Network Management

UniFi Express VPN & Network Management#

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#

Pavilion (AI PC) Configuration

Pavilion (AI PC) Configuration#

What Was Established#

Current Configuration#

Netplan Configuration#

Boot-time Interface Fix#

Network Infrastructure & VLANs

Network Infrastructure & VLANs#

What Was Established#

Key Decisions#

Current Configuration#

OPNsense DHCP Configuration

OPNsense DHCP Configuration#

What Was Established#

Key Decisions#

Current Configuration#

DHCPv4 Modification#

Other Assignment Areas to Monitor#

Historical Notes#

Proxmox Network Troubleshooting

Proxmox Network Troubleshooting#

What Was Established#

Key Decisions#

Current Configuration#

Troubleshooting Workflow#

Historical Notes#

Proxmox Network Configuration

Proxmox Network Configuration#

What Was Established#

Key Decisions#

Current Configuration#

Troubleshooting Network Interface Changes

Troubleshooting Network Interface Changes#

What Was Established#

Key Decisions#