Firewalls and Vpns
You set up firewalls and vpns by pairing encrypted tunnels with strict port rules. The tunnel assigns a private address while the firewall filters packets by port. Many teams build this boundary first to hide internal servers from public view. They create one large private network and place databases and servers inside it. Developers then log in to the tunnel to do their daily work. Still, broad subnet rules often grant access to every host on that network. One open route lets a user reach dozen
DigitalOcean Cloud Firewalls: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up firewalls and vpns by pairing encrypted tunnels with strict port rules. The tunnel assigns a private address while the firewall filters packets by port. Many teams build this boundary first to hide internal servers from public view. They create one large private network and place databases and servers inside it. Developers then log in to the tunnel to do their daily work. Still, broad subnet rules often grant access to every host on that network. One open route lets a user reach dozens of sensitive systems at once.
How firewalls and vpns control network traffic
A virtual private network builds an encrypted link between a laptop and a server. The user logs in with a password or key to start the session. Once the check passes, the server hands the laptop a virtual network address. That address makes the laptop look like it sits inside the private office. Packets travel through this secure pipe over the public internet without exposing data. Every message stays wrapped in encryption until it reaches the internal network router.
Next, the firewall checks every packet that exits the tunnel into the subnet. It reads the source address, the destination address, and the target port number. Admins write a list of rules to allow or drop these network packets. If a rule matches the address and port, the traffic flows through. If no rule matches, the firewall drops the packet right at the border. Teams often group users into network pools and write rules for each pool.
What network rules solve and what they miss
This classic network setup solves a major problem for modern engineering teams. It keeps database ports and internal servers off the open public internet. Attackers on the outside cannot scan ports or try passwords against hidden hosts. The firewall drops uninvited traffic before it ever touches a database or server. The encrypted tunnel also protects traffic when staff work from public coffee shops. For years, this perimeter model served as the main defense for private systems.
Yet network tools only look at addresses and ports during the initial handshake. Once the firewall opens the configured port or the configured port, its job ends. It cannot read the SQL queries or shell commands moving inside the pipe. A developer with valid network access still logs in with shared database keys. If they run a bad command that deletes a table, the firewall allows it. If a script pulls ten thousand phone numbers or emails, the network stays blind. Network logs only show that a laptop talked to a server on a port. They do not record which user ran a specific query at a given second.
DigitalOcean Cloud Firewalls: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to tighten network rules in practice
Teams can reduce risk by shrinking the size of each network zone. Instead of one flat subnet, split development, staging, and production into separate zones. Give each zone its own tunnel pool and its own strict firewall rules. Drop all traffic between zones by default and open only required ports. Remove old user keys and unused port rules during a monthly security review. Even with tight zones, remember that network rules only guard the front door. You still need controls that watch commands and mask sensitive fields like 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
Do firewalls inspect SQL queries or shell commands?
No, standard firewalls only check IP addresses and port numbers on network packets. They do not read or block specific database statements or terminal commands in flight.
Why is a flat VPN subnet dangerous for databases?
A flat subnet lets any person on the tunnel reach every internal port. If an attacker steals one laptop, they can reach all databases on that network.
Can network logs pass a strict data audit?
Network logs only record packet sizes, IP addresses, and connection times. Auditors usually ask for a full log of every query and command run by users.