Netmap VPN
You set up a netmap VPN by translating local subnet addresses to virtual ranges. This network address translation lets two overlapping private networks talk without IP conflicts. Teams use this setup when merging cloud networks or linking partner sites. It solves routing clashes without forcing anyone to renumber existing servers. Yet once the tunnel is up, broad network rules often expose every port. One logged-in user can reach entire subnets instead of one specific service. How a netmap VPN
VPN Access Control: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a netmap VPN by translating local subnet addresses to virtual ranges. This network address translation lets two overlapping private networks talk without IP conflicts. Teams use this setup when merging cloud networks or linking partner sites. It solves routing clashes without forcing anyone to renumber existing servers. Yet once the tunnel is up, broad network rules often expose every port. One logged-in user can reach entire subnets instead of one specific service.
How a netmap VPN translates overlapping network ranges
A standard site-to-site tunnel fails when both sides use the same private subnet. Routers cannot tell if a packet belongs to the local network or the remote one. The netmap feature solves this problem by rewriting the network prefix of an IP address. At the same time, it keeps the host portion of the address intact.
When a developer sends a packet across the tunnel, the firewall steps in. It swaps the source or destination prefix before routing the traffic. The remote network sees a clean virtual subnet that does not clash with local hosts. Return traffic goes through the exact reverse translation at the tunnel boundary. Each host keeps its original IP address while talking across the link.
Network teams set up these rules in their firewall translation tables. They pair a source range with a matching virtual range of the exact same size. Both sides of the tunnel must agree on the virtual subnet addresses. Once the rules match, packets flow between the two private networks without routing errors.
Planning virtual subnets and routing rules
Good address planning prevents new routing conflicts down the road. Network admins pick a dedicated block of private IP space just for virtual mappings. This block must not exist anywhere else in the company network. Each remote site gets its own slice of this virtual address block.
Teams also need to update DNS records or host files for internal tools. Engineers must aim their apps at the virtual IP address, not the real one. The router only translates packets that target the mapped virtual range. If an engineer types the real remote IP, the packet stays on the local network. Clear internal docs help developers pick the right address for each remote database or server.
VPN Access Control: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What network translation solves and what it leaves open
Subnet mapping fixes layer three routing conflicts during mergers or cloud migrations. Teams save weeks of work because they do not change server IP addresses. Traffic moves between sites with very little delay once the firewall rules run.
Still, a network tunnel only controls which IP addresses can talk to each other. It does not inspect or govern what a user does inside an active session. Once a developer connects to a mapped database IP, the firewall steps back. The network layer cannot tell a safe read query from a table drop.
Shared database logins and static keys make this visibility gap much worse. Network logs only show packet counts between a client IP and a virtual IP. They do not record which engineer ran a specific SQL statement or shell command. Also, network translation cannot mask sensitive data like emails or card numbers in query results. Teams still need controls that check user identity and inspect commands in flight.
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
When should a team use a netmap rule on a VPN?
Use it when two networks share the exact same local IP subnet range. It translates the network prefix so both sides can talk without renumbering hosts.
Does one-to-one subnet mapping change the host part of an IP address?
No, it only rewrites the network prefix of the IP address. The host number at the end stays the same, which makes tracking servers easy.
Does a mapped VPN tunnel log database queries or shell commands?
No, a network tunnel only sees IP packets and port numbers. You need command-level logging and data masking to govern what users run inside sessions.