Enterprise VPN
An enterprise vpn links remote staff to private networks through an encrypted tunnel. You set it up by placing a server at the network edge and installing client software. Teams often use this setup to keep internal apps and databases off the public web. Still, broad network roles often let users reach every machine on an internal subnet. Once inside the tunnel, a user can probe servers they do not need for work. How an enterprise vpn works in your network The workflow starts when a worker op
VPN Access Control + Passwordless Enterprise: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An enterprise vpn links remote staff to private networks through an encrypted tunnel. You set it up by placing a server at the network edge and installing client software. Teams often use this setup to keep internal apps and databases off the public web. Still, broad network roles often let users reach every machine on an internal subnet. Once inside the tunnel, a user can probe servers they do not need for work.
How an enterprise vpn works in your network
The workflow starts when a worker opens the client app on a laptop. The client sends a login request to the central server at the network edge. That server checks the user identity against a directory service and asks for a second factor. Once the check passes, the server assigns a private IP address to the laptop.
Next, the client and server build an encrypted tunnel over the public internet. Routing rules push traffic for private subnets into this tunnel instead of the public web. Split tunnel setups send only work traffic through the server to save bandwidth. Full tunnel setups route all web traffic through the company network for inspection.
Network admins then write firewall rules based on user groups and IP ranges. Developers might get a rule that opens ports to staging databases and Kubernetes clusters. Support staff might get a rule that only opens internal web tools. Every packet from the laptop flows through these network filters before hitting the target host.
What network tunnels solve and where they fall short
A network tunnel solves the problem of exposed ports on the public internet. It hides internal servers from outside scanners and encrypts traffic on public Wi-Fi. It also gives teams one place to check user identity before granting network entry. For years, this was the main way to let remote workers reach private systems.
Still, a network tunnel only checks who can join the network. It does not check what happens inside a database session or server shell. Once a packet passes the firewall port check, the network tool is blind to the payload. A user with port entry to a database still needs a local password to log in. Teams often share these database passwords across the whole group to save time.
VPN Access Control + Passwordless Enterprise: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Network logs also lack detail for security audits. A firewall log shows that an IP address sent bytes to a database port at noon. It does not show which SQL query ran or which rows came back. If an engineer runs a drop table command, the network tunnel does not stop it. If a query returns customer emails, phone numbers, or card numbers, the tunnel sends them in full.
Why managing subnet rules gets hard at scale
As a company grows, managing IP rules becomes a daily chore for the ops team. Every new cloud account or cluster needs new routes and firewall entries. Engineers wait on tickets just to reach a database for a quick fix. To clear the queue, admins often open whole subnets to large user groups.
Static network rules also keeps the session active long after a task ends. An engineer who needed five minutes of database time keeps that network route for months. If malware infects that laptop, the attacker rides the open tunnel straight into production servers. Securing modern systems requires controls that act on individual commands and data rather than raw network packets.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Does an enterprise vpn encrypt database queries inside the private network?
It encrypts traffic between the user laptop and the network edge server. After traffic leaves the server, it travels across the local network using the app protocol. You still need TLS on the database to keep data encrypted all the way.
Can network firewall rules stop a bad SQL query or shell command?
No, network firewalls only look at IP addresses, ports, and basic protocols. They decide if a laptop can reach the database port. They cannot read or block specific SQL statements or shell commands inside the session.
Why do teams still share database passwords when using a network tunnel?
The network tool only checks identity when the user starts the network tunnel. The target database or server still asks for its own login credentials. Without a tool to manage app sessions, teams end up sharing static database logins.