Does the router between two IPsec peers need IPsec?

A lab exercise that says "configure IPsec between two sites" hides two different jobs. The two endpoints terminate the tunnel: they negotiate, authenticate, encrypt, and decrypt. Any router in between forwards packets whose outer header belongs to the endpoints, and it does so without knowing the tunnel exists.

Deciding which job a device is being asked to do is the first step in the exercise. Most confusion in lab write-ups, and a good share of confusion in production diagrams, comes from treating "supports IPsec" as one property rather than two.

Forwarding is not terminating

In tunnel mode, the outer IP header is addressed to the terminating devices. A router in the middle looks up the destination and forwards, exactly as it would for any other packet, and the payload it carries is opaque to it.

That opacity is deliberate. The router does not hold the peer's secret, does not run a negotiation, and does not need a policy database. It needs a route toward the far endpoint and permission to forward the packet.

Confusing the two leads to real mistakes: asking a transit firewall to "allow IPsec" when the actual requirement is to allow protocol 50 between specific addresses, or expecting a middle device to decrypt for inspection when it has no key.

What the middle device must still get right

Forwarding has its own requirements. Routes must reach both external endpoints, and any policy along the path must permit the actual outer traffic rather than a guessed port number. A rule written against TCP 443 because someone assumed TLS will not match protocol 50.

Native ESP is IP protocol 50. It is not TCP 50 and not UDP 50, and a rule that blocks non-TCP traffic will drop it. If the design uses UDP encapsulation, the visible transport changes to the encapsulation port, and the policy has to match whichever design was chosen.

Packet size matters too. A route that carries a small probe does not prove that the full encapsulated exchange fits. A path that drops large packets can let the negotiation succeed and the workload fail, which looks like an application problem. Test with traffic the size of the real workload before blaming the tunnel.

Why the simulator changes the question

A simulator is not a router with a smaller feature list; it is a model with a documented subset, and its own rules about what a given device can be configured to do. Cisco's Packet Tracer FAQ is explicit that devices and protocols are simplified models.

So the question becomes three questions. Does the simulated device forward the packets the scenario needs? Does the same device offer the configuration surface the lesson assumes? And does the accepted command mean the behaviour is genuinely simulated, or only parsed?

An absent command may be a model limit rather than a mistake in your configuration. A present command may accept syntax without reproducing every production behaviour. Check the installed version's device help before concluding either way.

Writing a pass condition for the lab

For an underlay lesson, the pass condition is endpoint reachability plus the outer packets crossing the intermediate device. Prove it with the simulator's own counters or a packet view, and name the protocol you expect to see.

For an IPsec lesson, add the negotiation state and one protected LAN-to-LAN flow. If the simulator exposes security associations, record them. If it does not, say so in the write-up instead of implying the tunnel was verified.

Keep the simulator release, the chosen devices, and the learning objective with the topology file. That record is what lets someone else reproduce the exercise and understand which parts were modelled.

Production configuration needs its own platform evidence. A green simulated packet is a teaching result, not a compatibility statement about the hardware you will deploy.