L2TP, GRE or IPsec: which layer should carry the session?

Two questions get tangled whenever L2TP, GRE and IPsec land in the same design note: which session am I carrying, and which layer protects it? Get the first one wrong and everything downstream stays internally consistent while solving the wrong problem — a routed overlay built where users needed to dial in, or a dial-in concentrator standing in for a site-to-site gateway. The worksheet below forces that distinction before anyone logs into a device. Fill it in order and every line becomes something you can test by itself.

Start from the session, not from the protocol list

A remote user holding a PPP session and a routed overlay between two gateways are different network relationships, even when both end up wrapped in IPsec. The first terminates a per-user link and needs address assignment, authentication of a person or device, and a policy naming which internal networks that user may reach. The second forwards packets between sites nobody dials into.

Write one sentence that names which of the two you are building, then read it back as if you were the person who has to operate it. If the sentence needs the word "and", you are building both, and the worksheet needs two columns instead of one compromise column that half-serves each. If it names a user but no address pool, or a prefix but no forwarding policy, the sentence is still incomplete. The wording sounds bureaucratic, but it is the cheapest place to catch a design that will otherwise be discovered by a help desk ticket.

Give every layer exactly one job

L2TPv2 carries PPP sessions between its two endpoints. PPP runs the link negotiation and, when it is negotiated, the user authentication; L2TP adds no cryptography, so a bare L2TP daemon implements none of the IPsec security relationship and belongs only inside a link you already trust.

GRE is an encapsulation between two addresses. It carries network-layer packets across a logical overlay and, on its own, offers neither confidentiality nor an authenticated peer identity. That is not a defect: the header was designed to be simple so that it stays cheap to process on forwarding hardware. The consequence is that GRE answers "how do I move this packet between two addresses" and nothing else, which is exactly the question you should ask it.

That leaves IPsec as the layer that selects traffic, authenticates the peers and encrypts what it was told to protect. Which traffic it protects is a configuration decision that has to match the encapsulation the endpoints actually generate, because a policy written for the GRE outer address behaves differently from one written for the inner prefixes. The GRE specification keeps payload, GRE header and outer delivery protocol visibly separate, and your policy needs the same separation.

Write the packet path before the configuration

Take one packet and list every header that gets added, in the order it gets added, naming the device that adds it. For a dial-in user that is usually PPP inside L2TP inside IPsec; for a site overlay it is the inner IP packet inside GRE inside IPsec. If two devices add the same header, you have a loop or a duplicated tunnel, and no amount of policy editing will fix it.

The same list settles MTU, because the usable inner size is the measured path MTU minus the headers you just enumerated and nothing else. Do not copy a number from a forum post: add up the outer IP, UDP and ESP overhead, then GRE or L2TP, then PPP where it applies, and subtract from the path MTU you actually measured. Symptoms that appear only on large transfers, or sessions that establish and then die on the first big response, usually trace back to that addition being done by guesswork.

Check each layer separately, from the outside in

Run the checks in order and stop at the first one that fails. Each line answers a different question, so a failure points at one column of the worksheet instead of telling you the tunnel is broken.

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

On a Cisco box the equivalent is role-specific, and the exact syntax depends on platform and release: show crypto session for the IPsec peers, interface counters for the GRE or tunnel interface, and the VPDN or PPP verification for the dial-in role. A command set that terminates PPP proves nothing about GRE support, and a working GRE interface proves nothing about the PPP service, so verify the role you actually configured rather than the one in the diagram.

Record each output beside the worksheet line it belongs to. Notes taken while the fault is live are worth more than a topology redrawn afterwards from memory.

Order the teardown, then re-verify

Teardown runs in reverse for a reason: take the protected traffic out of the IPsec policy before you remove the encapsulation it was written against, or the policy keeps pointing at an interface that no longer exists and the next configuration load fails somewhere that looks unrelated. On Linux that means deleting the state and policy entries before the tunnel interface; on a router, removing the crypto map or profile entry before the tunnel.

After the rebuild, repeat the four acceptance observations one at a time: outer reachability, an established IPsec association, an established PPP session where the design includes one, and inner forwarding to a real destination address. One green light is not evidence for the other three, and that gap is the failure that survives longest in production — a tunnel that is up, encrypted, and forwarding nothing because the inner route was never added.

Keep the filled worksheet next to the device configuration. Any column you cannot fill is a layer with no assigned job, and a layer with no assigned job is usually a layer that should not be in the stack.