Route OpenVPN Clients Through Cloudflare? Check the Role First
A device client is not a router. Confirm the Cloudflare role forwards other hosts' packets, then keep the server's own tunnel on its old path.
You have a working OpenVPN server and a host that also runs Cloudflare's device software, and the obvious next step looks like pointing client traffic at it. Two working connections on one machine do not add up to a transit gateway. What is missing is a role documented to forward packets belonging to somebody else, and a policy that classifies those packets when they arrive.
Four questions come before any rule: what traffic enters, where it goes next, how the answers find their way back, and what the design does when that second path fails. The first two are capability questions.
Two services on one host are not a transit path
A device client is built to handle traffic that originates on the machine where it runs. It intercepts name resolution, or selected application traffic, and sends it through its own tunnel, and its policy is written for that device's user and that device's processes. A packet forwarded from an OpenVPN client is not local output, so the same rules do not classify it. That is not a configuration detail you can paper over with a broader rule, because it decides whether the software sees the packet at all.
Which is why the design question is a capability question. Either the installed product has a documented role that forwards traffic for other networks, or the transit function belongs somewhere else entirely.
Which Cloudflare role is allowed to forward
Cloudflare's device client offers modes that differ in scope: name resolution only, traffic from the device, and sometimes both. None of those modes turns the host into a router for a private range that arrives over a different tunnel. The dedicated routing role is a separate product with its own connector, enrolment and network model.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
Check the installed role before designing routes around it. Read which interface the connector creates, whether it advertises specific prefixes or a default, and whether local policy applies to forwarded packets as well as local ones. If only local traffic is handled, the OpenVPN server cannot be the transit point no matter how the translation rule is written.
This is also where a public egress requirement has to be stated precisely. A Cloudflare-provided exit for forwarded client traffic is a specific use case, and it needs confirming against the service you actually have.
Keep the outer tunnel independent of the new route
The moment you add a default route toward the new interface, the server's own outbound traffic starts competing for it, and that includes replies to the OpenVPN clients and your SSH session to the box. The usual symptom is a tunnel that establishes and then dies, or an administrator locked out while the change appears to have worked. Compare ip route get for the endpoint before and after, and use policy routing or a host route to keep the server's own transport where it was. Run that comparison from the box itself, because the server's view of its own route is the one that matters.
An exception for the server's public address is not enough by itself, because each remote administrator's return path is a different flow. Decide which of those flows must survive the change, then verify each one instead of assuming the first covers the rest.
Scope the forwarding and translation to one flow
Received packets follow the forwarding path, not the local output path, so the rule that matters lives in the forward hook. Where the onward interface needs translation, scope the source to the client pool, the destination to what is permitted and the egress to that single interface. A masquerade rule keyed only to an interface picks no route by itself and does not permit forwarding past any other filter.
Decide the fail-closed behaviour in advance, then test it. Stop the onward path and confirm that clients lose the intended egress instead of quietly falling back to the ordinary uplink, which is the outcome nobody notices until traffic is leaving by the wrong door. Repeat the check for name resolution and for IPv6, because a v4-only rule set leaves a v6 path open.
Write down the four answers you settled on and the observation that demonstrates each one. A transit path you can describe is one you can defend at the next incident review.