Put Internal Apps Behind Your VPN, Without Rebuilding Them
Check the tunnel and the person at the edge, and fail closed
Balinder Walia2026年10月26日7 min read
Staging sites, admin panels and internal tools are usually "private" because of an IP allowlist and a good intention. This post explains, in plain terms, how we put them behind the wslvpn Zero Trust VPN and enforce it at the WSLProxy edge: we check both the tunnel and the person using it, every failure denies, and a blocked response tells you why. Engineers who want the configuration, the rule logic and the debugging steps should read the in-depth technical article.
The internal tool everyone assumes is private
During a routine review we looked at a pre-production site that everyone described as "VPN-only". Its access rule allowed exactly one public address and named no groups of users.
In practice, "VPN-only" meant something narrower: your traffic must leave the internet from this one address. Anyone on that network got in, whether or not they were running the VPN client. No user was ever checked. The rule did what it said; it just didn't say what people thought it said.
Two further questions were worth asking. Could the site's origin server be reached directly from the internet, skipping the proxy altogether? And did every edge location actually have the access rule, or only some of them? We found no evidence that anyone had taken advantage of this, but the lesson was clear and it applies well beyond one site:
- Name the groups that may get in, not just the network they come from.
- Lock the origin so it only accepts traffic from your edge.
- Test from both sides, on and off the VPN.
- Check every edge location, not just the one you happen to hit.
The risk, in plain language
An IP allowlist answers one question: where did this request come from? That's useful, but it isn't the same as knowing who sent it. Shared office networks, a contractor's laptop that happens to be on the overlay, or anything else that can send traffic from an allowed address all look identical to an allowlist.
The second risk is quieter. If the application server behind the proxy also answers requests from the internet, the proxy's rules don't matter: someone who finds the origin's address simply goes around them. A front door is only useful if it is the only door.
Neither problem shows up in day-to-day use. People on the VPN get in, the site works, and nobody has a reason to look further. That's why it's worth designing the check properly once, instead of relying on everyone remembering the caveats.
What wslvpn and WSLProxy do together
wslvpn is a lightweight, self-hosted, WireGuard-based Zero Trust VPN. A user installs the client, signs in with single sign-on, their device is registered and its posture is evaluated, policy decides what they may reach, and the WireGuard tunnel connects. Each session gets its own overlay address.
WSLProxy is the open-source edge proxy that Workstation WSL Proxy is built on. It already routes, caches and filters traffic in front of our sites. Its access profiles add two checks at the edge, on every request to a protected path:
| Check | The question it answers | How |
|---|---|---|
| Network | "Did this request come over the tunnel?" | The client's address must sit inside the VPN's address range. |
| Identity | "Who sent it, and are they allowed?" | WSLProxy asks the wslvpn control plane which signed-in user holds that address, and checks their groups. |
The network check on its own is a boundary, not Zero Trust: any device on the VPN would get in. Naming groups is what turns it into a per-person decision. Access profiles always keep both checks, on purpose, so that one leaked credential on its own isn't enough to get in from outside the tunnel.
What it means for the business
One field per domain, no app changes
Protection is switched on by adding one line, "access_profile": "staff-internal", to the domain's configuration. The profile lists the paths to protect and who may reach them. The application itself doesn't change: no login library to add, no code to redeploy. The same profile can protect as many domains as you like.
No reload, no maintenance window
WSLProxy evaluates its rules on every request, so a new or changed profile takes effect on the next request. There's no proxy restart to schedule and no dropped connections.
It fails closed
If anything goes wrong, the answer is "no". If the VPN's control plane can't be reached, if there's no active session at that address, if the reply is malformed, if the configuration is incomplete, or if the user simply isn't in the right group, the request is denied. If a profile itself can't be loaded, perhaps because of a typo, the whole domain is denied rather than quietly left open. A brief outage of the identity service means a few people see a "VPN required" page; it never means the admin panel is exposed.
Faster support, fewer guessing games
Every decision made by a profile comes back with short response headers: X-WSL-VPN: allowed or blocked, the name of the profile, and when blocked a reason such as client-ip-not-allowed (not on the VPN) or vpn-group-not-held (on the VPN, but not in the right group). When someone says "I can't get into staging", support can see the cause in one command instead of starting a ticket thread. Blocked users see a branded "VPN required" page rather than a bare error, and teams can replace the wording per profile.
The six steps at a glance
The diagram shows the whole set-up and what happens on every request. The technical article walks through each step in detail.
- Connect users to wslvpn. Single sign-on, device registration, posture check and a WireGuard tunnel. Each session gets an overlay address.
- Make the edge see that address. Route the property through the tunnel. If another proxy sits in front of WSLProxy, tell WSLProxy to trust it so it sees the real client address.
- Write an access profile. The VPN's address range, the paths to protect, and the groups allowed on each.
- Attach it to the domain. One field. It's live on the next request; make sure every edge location has the profile.
- Lock the origin to the edge. Firewall the application server so it only accepts traffic from your WSLProxy edges.
- Verify both sides. Off the VPN you should get a 403 with a reason; on the VPN you should reach the site. Test both: a broken deny rule looks exactly like a working set-up from inside the VPN.
Honest limits
These are the current limitations, and it's worth planning around them:
- Device posture isn't re-checked on every request. wslvpn checks posture when a session is created. A device that falls out of compliance mid-session keeps access until its session ends.
- Only web traffic is covered. Databases, SSH and other non-HTTP services don't pass through WSLProxy rules. Restrict those on the wslvpn gateway itself, using its network routes and firewall allowlist.
- Revocation takes up to 15 seconds. WSLProxy briefly caches who holds each address, so a revoked session or a group change can keep web access for up to 15 seconds, unless a revocation webhook clears the cache entry straight away.
- IPv4 only. The address-range check is IPv4. A client arriving over IPv6 never matches, so it is denied rather than let through.
Where to go next
- Read the technical article: An IP Allowlist Is Not a VPN Check: Zero Trust Access Profiles with wslvpn and WSLProxy.
- Learn about Workstation WSL Proxy, or visit wslproxy.com.
- Explore the VPN on GitHub: github.com/bwalia/wslvpn.
Want help putting your staging sites and admin tools behind wslvpn? Talk to the Workstation team.