pfSense OpenVPN: Reaching a Network Behind Another Router

Your laptop reaches the pfSense LAN over the VPN and still fails to reach a service two hops further in, and the difference is one routing decision per owner. Three devices have to agree before a packet completes its round trip: the client, the firewall, and the router that actually owns the destination network. Miss any one of them and the symptom looks identical.

Follow one packet through those three decisions before changing a rule, because each owner has a different control and a different failure mode.

One packet, three routing decisions

The client decides whether the destination belongs in the tunnel, and it can only decide from what it knows: a pushed route, a local route, or a default that already covers everything. pfSense decides where to send the packet next, which for a network behind another router means a static route through a reachable gateway on the correct interface. The downstream router decides whether it knows a path back to the VPN pool, and if it does not, the reply is dropped or sent somewhere useless. Each decision is independent of the other two.

Failure of any single one produces the same user report. That is why the debugging order matters more than the tooling.

Give the client a prefix, not a guess

On a pfSense SSL/TLS server with an IPv4 tunnel network larger than a /30, the IPv4 Local network(s) field distributes routes to clients when they connect. Add the downstream prefix there rather than relying on the client to invent one. Then read the client's actual table after connecting, because a profile with route-nopull or a route filter can ignore what the server sent. The server can be perfectly correct while the client installs nothing.

Other server modes and topologies have different limits, and per-client or connection policy can change what a specific client receives. Verify on the client that matters rather than on whichever one you happened to test first.

Point pfSense at the internal router

A static route in pfSense needs a gateway that is defined and reachable, and the interface chosen for that gateway has to be the one that actually reaches it, as the Netgate static-route guide describes. In an illustrative layout the transit link is 192.168.77.1 on the firewall and 192.168.77.2 on the internal router, with the service network at 172.16.30.0/25 behind it. The route then names the prefix and the next hop, not the service address. Using an address from the remote network as the gateway is a common way to build a route that looks correct and forwards nowhere.

Assigning an interface a name does not describe the networks beyond it. The static route is that description.

The far side has to know the pool

The downstream router needs a return route for the pool, in this example 10.55.0.0/24 via 192.168.77.1, unless a default or a dynamic protocol already provides one. The service host's own gateway must lead toward that router, which is normally true when the router is its default gateway and false when the host was hand-configured. Policy routing on the firewall can also override the table for specific traffic, so check whether a rule selects a different gateway before concluding the route is wrong.

No translation is required for this design, and keeping the client's source address visible lets the downstream network apply its own policy.

For acceptance, follow one fresh request through tunnel ingress, the firewall's internal egress and the reply from the destination. If translation is deliberately used instead, record the source the downstream network sees and how the reply is expected to come back.

Save the three-owner plan alongside the permitted application, so the next administrator can reconstruct the path instead of rediscovering it.