I’ve set up more VPN servers in my career than I can count, I even hold a few patents related to them. Believe me when I say it wasn’t always “click and go.” In the early 2000s, my introduction to Virtual Private Networks was through IPSec with tools like FreeS/WAN. Those were the days of kernel compiles and cryptic config files. I still recall having to patch the Linux kernel just to get IPsec to work. Yes, if you wanted your IPSec tunnel to work through a NAT router, you literally had to recompile your OS!
So yah, it often took weeks of tweaking and troubleshooting to get a stable tunnel. By the time it finally worked, I’d have a few more gray hairs and a deep-seated aversion to ever touching that setup again.
Moving a bit forward, strongSwan improved the IPSec experience. For those familiar with its architecture, the original IKEv1 daemon, pluto, was eventually replaced by the more modern charon daemon, which could speak the IKEv2 protocols. But even then, you were on your own when it came to client software or OS Interoperability. There just weren’t any great cross-platform clients, and every new user meant wrestling with configuration on their machine. We became experts in deciphering error logs and obscure IKE negotiation failures. Those early IPSec adventures left some scars; if you mentioned “set up a new IPSec VPN” to me back then, I’d probably cringe and start considering a career change.
Then came the rise of SSL VPNs, and with it, OpenVPN. “It’ll be easier,” they said. And in some ways, it was: no kernel patching needed, more flexibility since we’re using just UDP or TCP. But easier is relative. OpenVPN introduced its own headaches. While it supported username/password authentication, many setups relied on certificates. Managing this meant generating and distributing keys securely. In theory, it's straightforward, but in practice, it was a hassle keeping track of who had which .ovpn file, dealing with revocations, and handling the inevitable “I lost my config” support calls. The administrative overhead was non-trivial, with plenty of room for misconfiguration. And user-friendly? Well, let's just say forcing your non-tech coworkers to edit text files or mess with command-line clients was not winning any popularity contests.
Around the same time, companies started investing in enterprise VPN appliances. I remember evaluating and using hardware from Cisco (the classic ASA boxes running AnyConnect), Juniper, and later on specialized appliances like Pulse Secure. These promised to take the headache away: a dedicated box (or cluster of boxes) that handled VPN for you. And they did work, but at a cost. Literally a cost: many thousands of dollars, plus licensing fees per user.
Setting them up was still a project of its own. You’d rack the appliance, spend days (or weeks) learning its admin interface (which often felt like it was designed in the ’90, because it was), and then struggle with client software versions, driver issues, and network policies. We traded open-source quirks for enterprise complexity. At least we had nicer GUI clients for the end-users, but behind the scenes it often felt like just as much toil to maintain. And one more thing: these VPN concentrators were exposed to the internet by design (they have to be, so your roaming users can reach them). That fact kept me up at night, because if there’s one box in your infrastructure that cannot go down or be compromised, it’s the VPN gateway. Unfortunately, we’ve seen countless instances where VPN appliances became huge targets, with attackers exploiting vulnerabilities in VPN servers to breach networks. (If you need a nightmare example: over 16,000 internet-exposed Fortinet VPN devices were recently found to be compromised via an undisclosed backdoor. Yikes.) The more I worked with these, the more I thought, “There has got to be a better way.”
Why Did It Have to Be So Painful? (Spoiler: It Doesn’t Anymore)
Looking back, each generation of VPN tech was trying to solve the core problem of secure remote access, but they were limited by the era’s constraints:
IPSec Era (OpenS/WAN, StrongSwan, etc.) Powerful but very low-level. Required deep networking knowledge and even kernel modifications for features like NAT traversal. Interoperability issues were common, client software was sparse, and setup could take weeks for a single site-to-site link.
SSL VPN Era (OpenVPN and friends) More firewall-friendly and slightly easier to deploy, but you became a part-time PKI administrator. Setting up a VPN meant also setting up a CA, managing certificates, and wrestling with config files on each client machine. User authentication was usually separate from your main identity systems (no SSO), leading to credential sprawl or cumbersome certificate distribution.
Appliance Era (Cisco, Juniper, Pulse, etc.) Turnkey hardware/software solutions that cost a fortune. These introduced nicer clients and more polished management, but complexity was still high. You had to maintain the appliances, keep them updated (pray that your users did the same with their clients), and deal with scaling issues as your user base grew. Plus, every VPN box sitting on the internet 24/7 became an attractive target for attackers, many orgs learned this the hard way via critical VPN security bugs and breaches.
In short, setting up a VPN used to be a big deal. It was never just “spin up and go.” Even in the best case, it was hours of work; in the worst case, it dragged on for weeks with plenty of frustration along the way. So if you feel a slight sense of dread when someone says “we need a new VPN”, believe me, I relate. I lived that pain for years.
But here’s the good news: it doesn’t have to be that way anymore. We’re now in an era where we can rethink VPNs from the ground up, with modern tech and a fresh approach. This is exactly what we set out to do with Border0.
Border0 VPN: Two Clicks to Secure Network Bliss
When we built the VPN feature into Border0, my guiding thought was: What is the VPN I wish I’d had all those years? I knew the answer right away: something incredibly simple to set up, that “just works” without the laundry list of prerequisites and gotchas. I didn’t want to spend hours configuring networking, generating keys by hand, allocating IP manually, or punching holes in firewalls. We have better technology now, and we can finally hide all that complexity under the hood.
Let me paint a picture of how setting up a VPN looks with Border0 today:
1) Deploy a Connector: You install a lightweight Border0 Connector in your environment (wherever you need the VPN to terminate). This is often a single Docker command or a one-line script, no crazy setup. The connector only needs outbound network connectivity, no inbound ports to open, which is already a sigh of relief!
2) Create an Exit Node, or a Subnet Route Socket: In the Border0 web portal, you literally click “Add New Socket” and choose Exit Node (a fancy term for a VPN entry/exit point). A couple of clicks to name it and point it to your connector, and boom: your VPN is ready to go!
That’s it. No, really, that’s it. In under a minute, you have a fully functional VPN spun up! I’ve recorded a short demo video (above ) where I go through this process, it actually took me about 30 seconds, but I promise I wasn’t rushing 😄. Going from “zero” to a secure, private network connection now feels almost anti-climactic. Two clicks and you’re done, something I only dreamed about back in the OpenS/WAN days.
The best part is that users connect using their Border0 client, which ties into their SSO login. So onboarding a new user doesn’t mean generating keys or certificates; it’s literally as easy as “Bob joins the team, Bob logs in with Google/Microsoft auth, Bob now has access.” When Bob leaves the team, you disable his SSO account or remove his Border0 access, and poof, his VPN access is gone. No lingering keys to worry about. This kind of integration eliminates so much headache. It’s the magic of Zero Trust principles applied in a very practical way: trust is tied to identity and policy, not to a device with an IP on your network.
Modern Tech Under the Hood (So You Don’t Feel the Pain)
How did we make Border0’s VPN so effortless? By leveraging the right modern technologies and building in the hard parts from the start:
Built on WireGuard®: We chose WireGuard® as the foundation for our VPN. WireGuard is a modern, lightweight VPN protocol known for its speed and strong encryption. It’s like IPSec’s cooler younger sibling, much easier to configure (no more X.509 certificate nightmares). By using WireGuard, we get state-of-the-art security and performance without dragging along the complexity of legacy protocols.
Automatic NAT Traversal: Remember all that pain with NAT and firewalls? Gone. Border0’s connector and clients intelligently handle NAT traversal (using techniques like NAT hole punching) behind the scenes. Whether your resources are in a cloud VPC, behind a corporate firewall, or on a Raspberry Pi under your desk behind NAT, you don’t have to worry about opening ports or configuring DNS. If both the server side and the client side are behind NAT, no problem: Border0 orchestrates a secure tunnel across the internet without manual network plumbing. It just works™. And because the connection is initiated outbound by the connector, your VPN “server” isn’t sitting exposed on the open internet waiting for knocks on the door.
Identity-Integrated Access: This is huge. Traditional VPNs didn’t really know who you were, once you were on, you were just an IP address on the network. With Border0, VPN access is tied into our Privileged Access Management (PAM) system. You log in with your SSO (Google, Okta, Azure AD, etc.), so the VPN knows “Oh, that’s Alice from Engineering” rather than just some random IP. This means we can enforce per-user and per-group policies easily. For example, maybe only the Engineering team’s SSO group can access the “engineering lab network”. In the past, implementing something like that would require complex firewall rules or separate VPN profiles, now it’s a few clicks because identity is part of the equation from the get-go. As a bonus, SSO integration means no more managing separate VPN credentials or client certificates: one less thing for both admins and users to worry about.
Zero Trust and Application-Awareness: Old VPNs were all or nothing, connect and you’re on the network, with access to whatever the network routes allow. Border0 takes a zero-trust, application-aware approach (hence why we call it an “application-aware VPN”). This means access can be narrowly scoped. You might fire up the VPN to reach a specific database or service, and only that resource is accessible to you. We’ve essentially merged the VPN with the idea of PAM and least privilege. No more “I logged in to VPN to reach one server, but now I can see 50 others by accident” situations. This not only improves security but also the user experience; it’s clean and focused access, rather than network chaos.
All these modern twists happen behind the scenes. As a user or an admin, you don’t necessarily see WireGuard or think about NAT traversal or SSO flows, you just click “connect” and it connects. But as a geek, I think it’s important to highlight why it feels so easy: because a lot of hard engineering is under the hood making it easy. We can appreciate that without having to suffer for it.
No Open Doors: Security By Design
One aspect I’m particularly proud of is how Border0’s architecture inherently reduces the attack surface that plagued older VPN setups. Since our connectors initiate outbound connections, you no longer have a VPN appliance sitting on an internet-facing IP, begging to be probed. This dramatically lowers the risk of external attack. Consider the example I mentioned earlier: thousands of organizations were hacked via bugs in their VPN gateways simply because those gateways were exposed online. With Border0, there is no gateway appliance open to the world, you can have it run behind firewalls without opening inbound ports or even behind NAT gateways. It’s a fundamentally different (and safer) model. Essentially, if you don’t expose it, they can’t attack it.
That isn’t to say you should stop patching or worrying about security (you should always care!), but it’s a relief to remove one big, juicy target from your list of concerns. And because each user’s access is narrowly scoped and tied to who they are, even if an account were compromised, the blast radius is far smaller than that of a traditional VPN where one valid login could potentially snoop around the entire network.
In summary, Border0’s approach gives you both ease of use and robust security. Those two don’t usually go hand-in-hand in the VPN world.
Final Thoughts: The Joy of the One-Click VPN
If you had told younger me, hunched over a console, compiling kernel modules for OpenS/WAN that one day I’d set up a company to make VPNs basically a non-issue, I might’ve laughed it off. Yet here we are. Border0’s VPN is something I’m immensely proud of, not just as a product, but because of what it represents: a shift in how we think about secure access. It embodies the idea that powerful infrastructure can also be simple and user-friendly.
No more weeks-long projects to connect offices or onboard a new partner network. No more dread when someone says “can we give so-and-so access to this internal tool?” Instead, it’s become: deploy a connector, click a button, share a link and done. The first time I set up a Border0 VPN for a friend (who expected the usual ordeal), he literally didn’t believe it was working at first. “That’s it? It’s already connected?” That reaction is gold. It means we’ve done something right by removing the pain that used to be synonymous with VPN setup.
So, to all the network geeks, IT admins, and developers out there who have their own war stories of VPN setups gone awry: I see you, I feel your pain. And I’m happy to report that those days are over. We have a better way now. Whether you use Border0 or another modern solution, the point is that VPNs have finally evolved. They can fit into the way we want to work today, on-demand, secure, identity-centric, and yes, even pleasant to use.
Thanks for reading my little trip down memory lane and forward into the future. If you’re interested in trying this out yourself, go ahead and spin up a Border0 connector + exit node, I think you’ll find it refreshingly simple. And as always, I’d love to hear your feedback, war stories, or questions. After all, we’re all in this quest for a better, safer internet together.
Happy (easy) tunneling! 🚀
Ready to level up
your security?
