IPsec Between Two Hosts: Where Protection Starts and Stops
A host pair can protect selected flows without a gateway. Define the endpoints, the policy that selects traffic, and the permissions that stay separate.
Protection on a host pair starts where the security association terminates, and that is the fact most gateway-shaped intuition misses. An application server and its database server can protect their own conversation directly, with no remote-access concentrator in the path, and the protection boundary then sits inside each host rather than in a firewall. What that buys you is end-to-end coverage for selected flows. What it does not buy you is a decision about who may read which row.
The boundary is where the SA terminates
RFC 4301 describes transport-mode security associations as the arrangement typically used between a pair of hosts for end-to-end protection. Those two hosts hold the keys, and each one decides which of its own packets enter the association. A gateway tunnel terminates somewhere else entirely and reaches the host through an additional internal segment, which is a different trust boundary even when the packet is encrypted for most of its journey.
Host-to-host and transport mode are not synonyms, though. Two hosts may just as correctly build a tunnel-mode association between themselves, so choose the mode first and then describe the endpoints. Write both into the design note next to the peer addresses, because a reviewer who knows only the mode will assume the other one.
The SPD decides protection, the route decides direction
A routing table answers where a packet goes. The security policy database answers how the selected traffic crosses the protection boundary, and it does so per direction with its own selectors. That split is why a working route to the database proves nothing about whether the request was protected, and why an established negotiation proves nothing about whether this particular application matched it. Compare the selectors before you compare the counters, since the counters only describe the flows that got that far.
On Linux, ip xfrm policy prints those entries with their direction, priority, selector and action of allow, block or trap, while ip xfrm state shows the resulting associations and their counters. Reading the two together is how you find the flow that quietly bypassed the tunnel because a broader allow entry matched first.
Priority ordering is part of the policy, not an implementation detail. A narrow entry that should protect the database port loses to a broader entry at higher priority, and the failure looks like the policy was never consulted.
Transport mode covers the next layer, not the IP header
| Transport mode | Tunnel mode | |
|---|---|---|
| Original IP header | kept for routing the flow | replaced by an outer header |
| What ESP protects | the carried next-layer payload | the whole inner IP packet |
| Where it terminates | commonly the two hosts | gateway pair, or a host pair |
In transport mode the ESP header sits between the IP header and the payload, and the address fields of that header remain visible to every device on the path. That is fine when the addresses are not the secret and the payload is. It is the wrong choice if you also need to hide the internal topology, because only tunnel mode wraps the original header inside a new one.
Both modes can carry several next-layer protocols, and ESP will protect what the selector matches rather than everything the host sends.
Selection is narrower than the connection
A single association can carry multiple flows, but only those the policy selects. Record the peer identities, the source and destination addresses, the protocol and the service scope for the relationship you intend, then decide separately whether non-matching traffic may go in clear, must be protected, or must be dropped when the association is unavailable. That last decision is the one that produces surprises, because a rule requiring protection for the wrong source can block your own management access as effectively as it blocks an intruder.
Keep an approved out-of-band path while you change enforcement, and test it before you need it rather than after both hosts become unreachable.
Machine identity is not application permission
IPsec authenticates a configured peer and protects selected packets. It does not decide which database record a person may edit, and it does not turn a trusted server identity into a grant of every application privilege. Application accounts, roles and authorisation stay exactly where they were, and an application-level TLS requirement keeps its own purpose even when the network path is already protected.
Accept the design with one operation from the intended source and one that must be refused, and include what happens when the required association cannot be established. An ordinary reachability test tells you that packets move; it does not tell you that they moved under the policy you wrote.