Transport VPN
A transport vpn encrypts the payload between two hosts while keeping original IP headers intact. You set it up by matching security rules and shared keys on both endpoints. Teams often use this setup to protect traffic between internal servers on a private network. When network rules are too broad, any user on the host can send raw commands. The encrypted link hides packets on the wire, not what the user runs inside. How a transport vpn works in practice Standard tunnel mode wraps the entire
VPN Access Control: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A transport vpn encrypts the payload between two hosts while keeping original IP headers intact. You set it up by matching security rules and shared keys on both endpoints. Teams often use this setup to protect traffic between internal servers on a private network. When network rules are too broad, any user on the host can send raw commands. The encrypted link hides packets on the wire, not what the user runs inside.
How a transport vpn works in practice
Standard tunnel mode wraps the entire original packet inside a new outer IP header. A transport vpn takes a simpler path for direct host-to-host links. It encrypts only the data payload and leaves the original source and destination headers untouched. Routers along the path read those original headers to forward each packet to its target.
To set this up, admins define matching security policies on both servers. Both machines must agree on the cipher suite, key exchange method, and host IP addresses. When one server sends data, the kernel checks the local policy table first. If the destination matches a rule, the system encrypts the payload before sending it out. The receiving host checks the cryptographic tag and decrypts the data for the local app.
This design saves bandwidth because it skips the extra IP header on every packet. It avoids hitting packet size limits that cause slow fragmentation on busy internal links. Teams often pair it with routing protocols to link cloud hosts without extra packet overhead.
What host-to-host encryption solves and where it stops
Setting up a transport vpn solves a clear problem on untrusted networks. Nobody on the wire can read or alter packets moving between the two machines. It stops packet sniffing and blocks rogue machines from spoofing traffic from unknown IP addresses.
Still, network encryption only checks which machine is talking, not which person is typing. Once the host link is live, the network trusts every packet from that IP address. A developer who logs into the source host can still connect to the target database. Network logs only show encrypted packets moving between two IP addresses on a given port.
VPN Access Control: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Those packet counters never show which SQL query ran or which production table changed. They also cannot stop a bad script from reading customer emails or phone numbers. Teams still have to manage database passwords and SSH keys on the target servers. If a user holds a broad role, the encrypted transport link carries destructive commands intact. Securing the wire is only the first step in protecting production data and systems.
Managing routing and network address translation limits
Because the original IP headers stay visible, network address translation can break the cryptographic check. When a middle router rewrites the source IP or port, the destination host drops packets. To fix this, both endpoints encapsulate the encrypted payload inside a standard UDP packet. That wrapper lets packets cross address translators while keeping host-to-host encryption active.
Teams also must rotate pre-shared keys or host certificates across every paired server. As the server fleet grows, tracking pairwise rules across dozens of hosts takes heavy work. Admins must check firewall rules and kernel policies whenever a host changes its IP address.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How does transport mode differ from tunnel mode?
Transport mode encrypts only the packet payload and keeps the original IP headers intact. Tunnel mode encrypts the entire original packet and adds a new outer IP header. Teams use transport mode for direct host links and tunnel mode for site-to-site networks.
Does a transport vpn hide which servers are talking?
No, the original source and destination IP addresses remain visible in the packet header. Anyone watching the network path can see which two hosts are exchanging traffic and when. The encryption only hides the actual data payload and ports inside each packet.
Can a transport vpn control which database queries a user runs?
No, it operates at the network layer and only secures packets between two IP addresses. It cannot inspect app protocols, check user identities, or block dangerous database statements in flight. You need app-level controls to audit queries or mask sensitive fields like card numbers.