Homelab • Networking

Remote Access in Restrictive Networks

Building resilient access through WireGuard and SSH fallback.

Having a homelab has been one of the most effective ways for me to learn cybersecurity and networking outside of the classroom. Working in real environments, dealing with real constraints, and solving problems that don’t have clean lab solutions forces a different kind of understanding.

One of those problems was remote access. I wanted to be able to connect to my home network from campus to continue working on projects or access services I was running. What seemed simple at first quickly turned into a layered set of constraints that required rethinking how remote access actually works.

The Initial Roadblocks

The first issue was my ISP. It uses CGNAT, which prevents inbound connections entirely. That immediately rules out traditional approaches like port forwarding or DDNS, because there’s no way to directly reach my home network from the outside.

I tried using Tailscale, and while it works well in many cases, the campus network blocks it along with most VPN providers. Even when it works, I’m not a fan of relying entirely on a third-party service for access to my own infrastructure. If that service goes down or changes, access goes with it.

At that point, I had two constraints that shaped everything that followed: I couldn’t accept inbound connections, and I couldn’t rely on typical VPN traffic being allowed.

The Plan

Given those constraints, the solution had to start from inside my network. If inbound connections aren’t possible, the only option is to establish a persistent outbound connection to something that is reachable.

I set up a VPS and used it as a relay. My home router establishes an outbound WireGuard tunnel to the VPS, effectively creating a bridge between my LAN and a publicly reachable system. From there, I configured my laptop to connect to the same WireGuard instance, allowing it to behave as if it were on my home network.

The architecture looked like this:

Home Network → WireGuard → VPS ← WireGuard ← Laptop

This worked exactly as expected—until I tried it on the campus network.

The Fix

On campus, WireGuard failed in a way that made the problem clear. The initial handshake would go through, but subsequent handshakes never completed, preventing the tunnel from staying active. In practice, this meant UDP-based VPN traffic was being interfered with or blocked.

So I shifted to something more resilient: SSH.

Unlike WireGuard, SSH runs over TCP and is commonly allowed through restrictive networks because blocking it would disrupt legitimate use. Instead of trying to force a full tunnel, I used SSH in two ways depending on the need.

For browser-based services, I set up a SOCKS proxy. This allowed me to route traffic for things like Wazuh, OPNsense, and Plex through the VPS and into my home network.

For services that required direct port access, like my AI inference server, I used SSH ProxyJump with local port forwarding. This let me map local ports on my laptop to internal services on my home network, effectively extending access without needing a full VPN tunnel.

At that point, the architecture became:

Laptop → SSH → VPS → WireGuard → Home Network

This setup is less seamless than a full VPN. It requires managing tunnels and doesn’t provide transparent network access in the same way WireGuard does. But it works reliably in environments where VPN traffic is restricted, which makes it a practical fallback.

The Final Architecture

The result is a hybrid approach that adapts to the network I’m on.

On open networks, I connect directly to my WireGuard relay and get full access to my home LAN with minimal overhead.

On restrictive networks, I fall back to SSH. The VPS acts as a pivot point, and I selectively expose services through SOCKS or port forwarding depending on what I need.

This approach trades convenience for resilience. WireGuard provides a clean, full-network solution when it’s allowed. SSH provides a reliable fallback when it isn’t.

More importantly, building this forced me to think in terms of constraints rather than tools. Instead of asking “what should I use,” the question became “what is this network allowing, and how can I work within that?”

That shift in perspective ended up being more valuable than the solution itself.