GRE over IPSec vs L2TP over IPSEC

I just stumbled across this old one showing up as related, and wanted to answer, for having been in that situation more than once.

No need for trust configuration on cisco routers like ISR G1 (18xx/28xx/38xx), G2 (19xx/29xx/39xx) or ISR 4000 series - and probably older ones, too.

As long as there is no inbound QoS policies that would classifiy and (re)mark the packets, they will leave the ToS byte alone.

Usually, the to-be-encapsulated packet's ToS Byte (including DSCP) is copied out to the encapsulating headers.

Also see https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book/IPSecQoS.pdf

Chapter "ToS Byte preservation" (Page 6-12):

To overcome this predicament, the IPSec protocol standards inherently have provisioned the capability to preserve the ToS byte information of the original IP header by copying it to the IP headers added by the tunneling and encryption process.

QoS Preclassification is also explained right there. In a nutshell: with QoS preclassify, every to-be-encrypted data packet gets a companion data structure in router memory that holds information from the original packet. Egress QoS policies then queue/schedule the encrypted packet properly, based on the data from the companion data instead of the encapsulated/encrypted (and therefore inaccessible) original packet.

If I understand your case correctly, default-active ToS byte preservation and an egress policy on the tunnel interface should work pretty nicely, making sure that the packets leave the router in the order you intend them to.

However, it may be that the metro ethernet or the WAN service provider might not trust the dscp markings in the outermost IP headers and might nullify them. That may be of minor concern for two reasons:

• the packets left the router after queuing/scheduling, in the order you wanted them to. If your egress policy includes proper shaping to just-under-the-SP's thresholds, the SP's devices won't need to queue/reschedule.
• the remote tunnel endpoint will start do decapsulate the incoming packet. First step will be to discard the outermost IP header with the possibly nullified ToS byte. No harm done, the next IP Header will still have the original ToS byte with the DSCP field.

Respectfully, No. Stand the IPSec connection up. Then, if you need to create a GRE tunnel between other endpoints behind the IPSec peers, say from a pair of computers or something, simply configure the GRE tunnels on those devices.

You do not want or need to create an additional GRE tunnel on the IPSec devices themselves (since you already have a tunnel stood up - the IPSec tunnel).