Site-to-Site vs Remote Access VPN: What the Two Join

Both designs are called a VPN and they solve different problems. A site-to-site tunnel joins two gateways, so every host behind them can reach permitted addresses on the other side without installing anything. A remote-access tunnel joins individual devices to a network, one client at a time. The comparison matters because most deployment mistakes come from configuring one while expecting the behaviour of the other, and the symptom is usually a timeout on a service that the tunnel genuinely reached.

Two designs, two boundaries

Neither design extends a LAN broadcast domain. Devices on the far side do not appear in a local discovery list, and expecting them to is the first assumption to drop. Private DNS names that you publish deliberately are more predictable than any discovery protocol, and they survive a change of vendor.

Take 10.10.0.0/24 at one site and 10.20.0.0/24 at the other. Gateway A needs a route or a traffic selector that sends the 10.20.0.0/24 prefix into the tunnel, and gateway B needs the mirror image. Hosts on either side then use ordinary IP connectivity and never learn that a tunnel exists. That invisibility is the feature, and it is also why failures look like ordinary network errors rather than tunnel errors.

Policy-based and route-based are not the same tunnel

In a policy-based IPsec deployment, the negotiated traffic selectors define exactly which source and destination pairs are protected. If a new subnet appears behind one gateway and no selector covers it, the tunnel stays up and the new subnet is simply not carried. In a route-based design, an interface receives the traffic and the routing table decides, which makes adding a prefix a routing change rather than a tunnel renegotiation.

StrongSwan exposes both views directly, and reading them together is how you tell which model you actually deployed.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

A selector list that omits the prefix you care about explains the failure without any packet capture, and a route pointing at the wrong interface explains the mirror-image failure on the way back. Read both before you renegotiate anything, because a rekey will not add a selector you never configured.

Plan the addressing before the tunnel

Overlapping ranges are the design mistake that cannot be fixed with configuration. If both sites use 192.168.1.0/24, a host that needs 192.168.1.50 has two candidates and no way to choose. The tunnel will authenticate, the security associations will establish, and the routing decision will be wrong or ambiguous regardless.

Choose one of three honest options: renumber one site, translate the overlapping range at the gateway so each side sees a distinct prefix, or give up on direct routing for those hosts and publish the service another way. Each has a cost, and the first is usually the cheapest over a two-year horizon. Decide before the tunnel exists, because after the fact the change touches every device that has the old address.

Also fix the MTU question early. A tunnel reduces the usable payload, and a design that relies on fragmentation behaves differently from one that clamps the MSS at the gateways.

Forwarding and policy sit outside the tunnel

The gateway has to be willing to forward packets between the tunnel interface and the LAN interface, and both directions need policy that permits the service. On Linux that is two separate settings, plus the firewall rules that decide whether the forwarded flow is allowed at all.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

The receiving host adds a third layer: its own firewall still has to accept a client from the remote subnet. A file server that allows only its local /24 will reject forwarded traffic from 10.20.0.7 no matter how healthy the tunnel looks, and that rejection is easy to misread as a routing failure.

Test from a host, not from the gateway

A ping sourced by the gateway itself can follow a different source address and a different policy than forwarded user traffic. That makes it a weak test and, occasionally, a misleading one: it succeeds while the application fails, or fails while the application works.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Use a real host, a real source address, and the real protocol the application uses. Then read the reply path separately, because a working forward direction with no return route produces a timeout that looks identical to a blocked service.

Choose the design by the question you are answering: are you joining networks, or admitting devices? Everything else, including which vendor you configure, follows from that answer.