Where Your Site VPN Terminates Decides What Gets Inspected

The device that decrypts site-to-site traffic decides what the firewall can still inspect. Draw the boundary first, then pick a router or a firewall.

A site-to-site tunnel hides one detail that decides the whole inspection design: the exact device where the inner packet appears in clear. Everything before that point sees ESP, and everything after it sees ordinary IP that a rule can match. Put the boundary in the wrong place and the firewall you paid for becomes a router with a licence. The walkthrough below draws the line first and only then asks which box should own it.

Draw the line where the packet stops being encrypted

In tunnel mode the original packet is encrypted and wrapped in a new outer IP header addressed to the peer gateway. That outer packet carries protocol 50 for ESP, so any device between the two gateways can route it without reading the inner addresses. The first device that decrypts is the security boundary, and it is also the first device that can apply policy to the inner flow. Everything downstream of that point is ordinary routing.

Mark three things on the drawing: the external endpoint that admits ESP, the protected networks named in the policy, and the next hop the decrypted packet takes. If those three are not on the same device, you have a handoff to design rather than a single control point.

RFC 4301 calls the decrypting device a security gateway and treats its policy as part of the boundary. That is a more useful frame than the product category, because a device is a boundary when it holds the policy, not when its datasheet says firewall.

Firewall-terminated: one device, one policy point

When the firewall terminates the tunnel, the upstream router only has to deliver ESP to it. The firewall authenticates the peer, decrypts, and then applies its normal rules to the inner packet on the way to the server VLAN. That gives one place to read policy and one place to read logs, which is usually what an audit asks for.

Check the two permissions separately. Allowing IKE and ESP to the appliance is not the same rule as allowing a remote site to reach a server, and a firewall that accepts the tunnel while blocking the inner flow looks exactly like a broken tunnel from the far end.

The cost is that the firewall now sits on the path for all site traffic, so its throughput, session limits and failover behaviour become the behaviour of the tunnel itself. Size it for the combined site flows rather than for the remote-access profile it may have been bought for.

Router-terminated: the inspection hop becomes optional

When the router decrypts, the packet is already in clear when it reaches the routing table. If a separate firewall is meant to inspect that traffic, the router has to send it through the firewall and the return path has to come back the same way. A direct route from the router to the server VLAN quietly removes the firewall from the path while leaving it in the diagram.

That is the failure to look for in an existing network: two routes to the same prefix, one through the firewall and one direct, with the direct one winning on prefix length or metric. The tunnel still passes traffic and the inspection you believe in does not happen.

Route-based tunnels make this visible, because the tunnel is an interface you can route through another device. Policy-based tunnels select traffic by selector, which can leave the decrypted packet on the router with nowhere else to go.

Ask both candidates the same five questions

A short worksheet beats a feature matrix, because every question maps to a line on the drawing. Ask each candidate:

  • Which IKE versions, peer authentication methods and routing models does this release actually support?
  • Where is ESP admitted, and where is the decrypted flow permitted or denied?
  • How do local hosts learn the remote prefixes, and how does the far side learn yours?
  • What throughput, session count and failover behaviour must the endpoint sustain for the real workload?
  • Who owns the peer credentials, the policy and the recovery path when the tunnel is the broken thing?

pfSense documents policy-based and route-based IPsec as separate models with separate constraints, and that difference matters more than the label on the box. Check the exact mode and the supported filtering of decrypted traffic on the release you would actually deploy.

If a candidate cannot answer the second question with a rule you can read, it is not the boundary you want, whatever else it does well. Ask for the rule text rather than a yes, and treat a vague answer as a no.

Verify the path with a capture, not with the diagram

A diagram describes intent and a capture describes behaviour, so confirm which interface carries ESP and which carries the inner flow before trusting either.

tcpdump -ni wan0 esp
tcpdump -ni lan0 host 10.60.4.20
ip xfrm policy list

If the first capture shows ESP arriving and the second shows the inner packet on the LAN side, the decrypt point is where you think it is. If the inner packet appears on a segment that bypasses the firewall, the routing is wrong no matter what the policy text says. The xfrm listing then shows which selectors are installed and in which direction.

Repeat the capture on the return path, because asymmetric routing is common when one site has two possible exits. A tunnel that works in one direction and times out in the other is almost always this, and no amount of policy editing on the far side will fix it.

Inyandiko zihuye