Cassandra Over VPN: Give Clients and Nodes Separate Access

A Cassandra deployment does not have one universal database network. Applications talk to the client service, cluster members talk to each other, and operators use administrative interfaces, and those three audiences should not inherit one another's reachability. A private path such as a VPN is a good starting point, but it is not the database's user identity and it is not its encryption policy. Treat the connectivity decision and the authorization decision as two separate reviews.

Each of the three audiences gets its own answer, and the sections below take them in order of exposure.

Three audiences, three decisions

Identify what each group actually needs before you touch a rule. Clients need the client listener and enough information to reach every node they may be handed, peer nodes need each other on the internode port, and operators need the management interface for whatever the runbook actually calls for. Three lists, three audiences, three levels of trust.

The common mistake is to build one flat private segment and assume the VPN boundary does the rest. Inside it, an application that can reach the client port can usually reach the internode port too, and an operator's administrative tools often sit on the same jump host as the application. Flattening those together means a compromised application identity already has more reach than its own queries. Draw the three audiences as three rows in the design document, each with the rule that permits it, and the gaps become visible before anyone builds them.

What clients need, and nothing more

Permit the intended application sources to the client endpoints for the deployed version, and keep unrelated cluster and management services out of that reach. Then check how the driver discovers nodes. A reachable initial contact point does not establish that every node address the driver selects afterwards is reachable from that client context, because the driver asks the cluster for peers and then connects to whatever addresses the cluster advertises.

That is why one private-address mismatch produces the familiar pattern of a successful first connection followed by timeouts. Configure advertised addresses and client routing deliberately; publishing the whole cluster to the internet to repair one mismatch trades a routing bug for an exposure you cannot take back.

Keep the application's database authentication and role permissions in place as well. A shared translated VPN address can stand for many users or services, so it is never a substitute for distinct database identities.

Encrypt client-to-node and internode separately

Apache's security documentation treats client-to-node and internode encryption as separate configurations, and enabling one does not enable the other. That distinction still applies inside a VPN, because the tunnel protects its own segment and does not automatically extend from the application process to the database process or between every pair of cluster members.

A configuration that turns both on explicitly, rather than inheriting a template default, looks roughly like this:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

On server configurations that allow optional client encryption, accepting TLS can coexist with accepting unencrypted connections, so read the effective policy rather than the intent. Plan certificate names, trust distribution and renewal for the endpoints each client actually contacts; replacing a hostname with an IP address changes the client's identity check, not just its route.

Keep administration on its own path

Internode traffic needs the permitted peer set and its own protection policy. Administrative access, including JMX where it is used, needs a separate audience and its own authentication. An application permitted to issue ordinary queries does not thereby need every management capability, and the reverse is worse: an administrative path exposed to the application segment is the shortest route from a bug to a rebuild. Write those two audiences down separately, and name their owners, because they are usually different teams whose rules got merged by accident.

Keep effective cloud rules, host rules and listener configuration aligned. A private listener can still be exposed through an unintended translation or proxy, and a broad public rule can sit quietly beside a narrow VPN rule until someone audits both at once.

Where operators genuinely need a management path, give it a named owner and a shorter credential lifetime than the application's. That keeps the delegation visible when the next person inherits the cluster.

What the design promises

Validate all three promises with real roles rather than with connectivity tests alone. An approved application should complete its allowed work and nothing more, an excluded source should fail against the client entry, and an application identity should be refused on the reserved administration paths. Add client reconnection and node selection to the same rollout test, because that is where discovery mistakes surface.

Finish with three sentences in the design document: which clients can query, which nodes can communicate, and which operators can administer. Being behind a VPN is useful topology information, but it is not an answer to any of those three questions.