Array Networks VPN Reverse-proxy Architecture
You set up an array networks vpn reverse proxy architecture by routing external traffic through a single edge appliance. The appliance checks user logins first and then sends safe requests to internal servers. Engineering teams use this design to hide private networks from the public web. Still, teams often give users broad network roles just to make daily work easy. When one account has wide network rights, a single bad command can break production data. How an array networks vpn reverse prox
Reverse Proxy Security + Zero Trust Architecture: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up an array networks vpn reverse proxy architecture by routing external traffic through a single edge appliance. The appliance checks user logins first and then sends safe requests to internal servers. Engineering teams use this design to hide private networks from the public web. Still, teams often give users broad network roles just to make daily work easy. When one account has wide network rights, a single bad command can break production data.
How an array networks vpn reverse proxy architecture works
An array networks vpn reverse proxy architecture sits at the edge of your private network. Remote users log in to a public portal or start a client tunnel. The edge appliance terminates the external TLS link and checks the user login against a central directory. Once the user passes this check, the appliance maps their group role to internal network routes.
In web mode, the appliance rewrites internal web links and forwards HTTP requests to backend servers. In full tunnel mode, it assigns a virtual IP address to the user device. The appliance then routes TCP packets across the private subnet based on firewall rules. Internal servers see traffic coming from the edge appliance rather than the remote device. This setup keeps backend IP addresses hidden from external attackers.
Admins manage these rules by grouping users into broad job roles like developer or support. Each role gets a list of allowed IP addresses and port numbers. When an engineer needs to fix a database or run a script, they start their VPN session. The appliance checks the IP and port, then opens the network path for the user.
What the native setup solves and where gaps remain
This edge design solves the basic problem of remote network entry. It stops random web scanners from reaching your private databases and internal apps. Central login checks also let security teams require multi-factor codes before a tunnel starts. If someone leaves the team, admins can block their directory account to stop future logins.
Still, network tunnels only check who logs in and which port they reach. Once the TCP path is open, the appliance does not check individual commands or SQL queries in flight. An engineer who connects to a database port still needs a local database password to log in. Teams often share these database keys in chat rooms or store them on laptops.
Reverse Proxy Security + Zero Trust Architecture: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Worse, the network appliance cannot tell a safe read query from a table drop command. It logs the start of a network session and the bytes sent, not the actual queries run. If an engineer queries a table with customer emails or card numbers, raw data flows straight to their laptop. Network rules alone cannot mask sensitive fields or require a peer to approve a risky command.
Best practices for tightening edge routing rules
Teams that rely on edge appliances should shrink their network rules as much as possible. Avoid giving any user group full subnet routes across the whole production network. Instead, restrict each role to the exact host IP and port required for their daily work. Separate staging routes from production routes so test scripts cannot hit live servers by mistake.
You should also set short timeouts on idle VPN sessions. When an engineer steps away from their desk, an open tunnel is an easy target. Force a fresh login and multi-factor check at the start of each workday. Finally, ship all connection logs from the appliance to a central log server for daily review.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between web portal mode and full tunnel mode?
Web portal mode routes only browser traffic to specific internal web apps. Full tunnel mode gives the user device a virtual IP and routes all TCP traffic to private subnets.
Does a VPN reverse proxy hide database passwords from engineers?
No, the network appliance only opens the path to the database port. Engineers still must enter database passwords in their local client tools to start a session.
Can an edge VPN appliance log the exact SQL queries an engineer runs?
No, the appliance operates at the network and transport layers for non-web traffic. It records IP addresses, ports, and byte counts, not the database queries inside the stream.