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?

Related Pages#

• UniFi Express VPN & Network Management
• Proxy Management & Cloudflare Tunnels
• Network Infrastructure & VLANs

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#

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

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?

Related Pages#

• Proxy Management & Cloudflare Tunnels
• Troubleshooting Network Interface Changes

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#

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.

Related Pages#

• Network Infrastructure & VLANs
• VLAN Configuration: OPNsense & Netgear MS308E
• Cloudflare Integration: SSL & DNS

Uptime Kuma - Configuration & Integrations

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.

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#

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#

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.

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#

1. Verify Connectivity: ping 192.168.0.69.
2. 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

3. Check for IP Conflicts: Ensure no other device (via DHCP) has been assigned 192.168.0.69.
4. 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#

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: