pfSense as VPN Server and Client: Two Paths, One Router

One appliance can face two directions at once: roaming users connect in, and the same box connects out to an exit provider so that selected traffic leaves through another network. Enabling both services takes minutes; making them coexist takes a design, because the second role rewrites the routing table the first one depends on. Three conditions decide whether the arrangement works, namely whether the inbound service keeps its own return path, whether the outbound tunnel can still reach its peer, and whether the traffic you meant to forward is selected for the exit. Get one wrong and you get two tunnels that both report connected while nothing useful crosses between them. The checks below establish each condition in the order the failures usually appear.

Name the two roles before touching a setting

Write down four facts for each instance: its remote peer, its authentication material, the address pool it hands out, and the networks behind it. The two instances are separate objects on the appliance and should stay separate in your notes too. Almost every confusing symptom later comes from mixing their values, and two instances sharing one set of notes is how the wrong pool ends up in the wrong field.

The inbound service needs a tunnel network that does not overlap the outbound tunnel's addresses or any private network the appliance routes. Overlap is the one mistake that produces symptoms in both roles at once, and it is far cheaper to catch on paper. Compare both pools and every routed private network in one place before configuring either service.

Shared hardware does not imply shared credentials, and a client certificate from the remote-access pool should not be usable against the exit provider. Separate material also turns revocation into a local decision instead of a fleet-wide event.

Keep the server's replies on the WAN path

Replies the appliance generates itself are the first casualty of a careless default route. When a roaming user's encapsulated packet arrives, the reply is locally originated traffic and it has to leave by the interface that user reached. If the outbound client installed a default that captures it, the reply enters the wrong tunnel and the session stalls while the service still looks healthy.

There is no single checkbox that settles this, because the decision is about which traffic the outbound client may capture. Either pull no routes and steer only what you select, or pull routes and add the exceptions that keep the appliance's own services working. Write the choice down next to the instance, or the next person will assume the other one.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Read the routing table by longest match rather than by the order you configured anything. The question is which entry wins for the exit peer's address and which entry wins for the inbound service's reply, and those two answers can differ.

Don't let the exit tunnel eat its own endpoint

The outbound client has to reach its peer's public address in order to establish the tunnel at all. If that address is itself routed into the tunnel, the client chases its own tail: the transport never comes up, or it comes up and then drops the moment the route installs. The log looks like an authentication timeout rather than a routing fault, which is why the route deserves checking first.

Check the route before the credentials and again after the tunnel is up, because an entry can be correct at boot and wrong a minute later. The address of the peer must point at the ordinary WAN path, never at the tunnel device. Once the transport is stable the interesting question moves to forwarded traffic, which is the next decision.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Pick which users get the exit

Source policy belongs at the ingress where traffic enters the appliance, so select the remote-access pool, or narrower identities inside it. Preserve the private destinations and management exceptions that must never be sent to the exit, and place those rules before the broad one. The exit path then needs its own translation or routed return arrangement, which for most designs means outbound NAT on the exit interface covering the pool. Translation does not choose an egress; it only rewrites what has already left, so a NAT rule on an unrelated WAN changes nothing about selection.

Confirm that the far end permits forwarded traffic from this design, because some providers do and some do not. The difference shows up as a tunnel that connects and carries nothing, which is easy to misread as a local fault. Test the three flows separately, since they fail independently and two out of three is a half-built design.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

The first command is the roaming user's outer connection, and it is working when the client reports the initialisation sequence complete. The second, run from that connected laptop, should report the exit provider's address rather than your WAN address. The third runs on the appliance bound to a pool address, and it tests the source policy for forwarded traffic without involving a remote user at all. If it answers from the WAN instead, the policy did not match, and no amount of NAT editing fixes a selection problem.

Decide what happens when the exit fails

Write the failure behaviour down before it happens: when the outbound tunnel drops, do users fall back to the ordinary WAN or are they blocked until the exit returns? Both answers are defensible, and the appliance will not choose for you. A removed route or a policy pointing at a dead gateway does not automatically produce a fail-closed result. If you want blocking, the policy has to say so explicitly, and it has to be tested by taking the exit away rather than by reasoning about it. If you want fallback, publish that to users, because traffic that silently takes the ordinary path is exactly the traffic somebody believed was covered.

Disable the client instance, watch what a connected user can still reach, then start it again. A request that times out is the fail-closed result you asked for; one that answers with the WAN address is the fallback you did not document. Repeat the check for IPv6 and for DNS, because a policy written for IPv4 says nothing about AAAA traffic and a resolver pushed by either tunnel answers from wherever the query actually leaves.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

The Netgate routed OpenVPN recipe shows how source policy, interface assignment and outbound translation fit together, and its site-to-site scope is the part not to copy wholesale. What it will not tell you is which of the three conditions above your own design has already broken.