VPN and Proxy Tools
Teams use vpn and proxy tools to route user traffic into private networks. You set up a network tunnel or forwarder and then grant user roles. Many teams start by placing all databases and servers inside one private subnet. Then they give engineers a client profile to join that private network. If those roles are too broad, one user can reach every internal machine. How vpn and proxy tools work in practice A virtual private network creates an encrypted tunnel between a laptop and a router. On
Database Proxy (ProxySQL, PgBouncer) + VPN Access Control: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Teams use vpn and proxy tools to route user traffic into private networks. You set up a network tunnel or forwarder and then grant user roles. Many teams start by placing all databases and servers inside one private subnet. Then they give engineers a client profile to join that private network. If those roles are too broad, one user can reach every internal machine.
How vpn and proxy tools work in practice
A virtual private network creates an encrypted tunnel between a laptop and a router. Once the user logs in, the laptop gets a private IP address. The operating system then sends internal traffic through that virtual network interface. Network admins write firewall rules to control which subnets that IP can reach. They assign users to groups in an identity provider to manage these rules.
A forward or reverse intermediate server works at the transport or protocol level. Instead of joining a full subnet, the client sends requests to one specific endpoint. That endpoint checks the source IP or user token before forwarding the packet. Teams often pair both methods to layer their network defenses. First, the user starts the tunnel on their work machine. Next, the client tool talks to an internal endpoint inside the private network.
Network setup steps for engineering teams
To set this up, you first deploy a network server in your cloud account. You place this server in a public subnet with a static IP address. Next, you link the server to your team directory for user sign-in. You define group rules that map engineering teams to specific private subnets. For example, the data team gets a route to the analytics subnet. The backend team gets a route to the app server subnet.
After the server is live, you send client profiles to your engineers. Each engineer installs a local client app and loads the profile file. Before they log in, they must pass a multi-factor check. You also set up routing tables inside your cloud network. These tables direct return traffic back through the tunnel interface to the user. Finally, you turn on network flow logs to record which IPs talk together.
Database Proxy (ProxySQL, PgBouncer) + VPN Access Control: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What network tunnels solve and what they miss
This native setup solves the problem of exposing private ports to the public internet. Attackers on the outside cannot scan or reach your internal databases and servers. Your firewall drops any packet that does not come through the encrypted tunnel. It also gives your team a single place to cut off network routes. When an engineer leaves the company, you revoke their directory account right away.
Still, network tunnels only decide who can reach a host port. Once the tunnel is open, the network tool does not inspect the session payload. It cannot tell a safe read query from a command that drops a table. Engineers also still need raw database passwords or SSH keys on their laptops. Flow logs show bytes sent, but they do not show the exact queries run. Plus, if data comes back, network routes do not rewrite emails or card numbers.
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
What is the main difference between a tunnel and an endpoint forwarder?
A tunnel puts a user device onto a private network at the IP layer. An endpoint forwarder takes traffic for one specific port and sends it to one server.
Why do engineers still need database passwords when using a network tunnel?
The tunnel only handles the network route between the laptop and the database port. The database still asks the client app for a username and password to log in.
Can firewall rules block a dangerous query inside an open session?
No, standard firewall rules only check IP addresses, ports, and basic packet headers. They do not read or block specific database statements or shell commands in flight.