Skip to main content

Technical Lab: Configure encryption over ExpressRoute

Questions​

Question 1 — Multiple Choice​

An organization needs to ensure end-to-end confidentiality of data traveling over an ExpressRoute Private Peering circuit. The security team requires that traffic be encrypted even if the connectivity provider is compromised.

Which approach meets this requirement?

A) Enable MACsec between the on-premises router and the provider's edge router, as this encrypts the physical link between the two devices.

B) Configure a Site-to-Site VPN tunnel using Azure VPN Gateway over the ExpressRoute Private Peering circuit, creating an IPsec layer over the private connection.

C) Enable ExpressRoute Global Reach to interconnect on-premises sites, as this feature adds native encryption between circuits.

D) Use Microsoft Peering instead of Private Peering, as Microsoft Peering automatically applies TLS to traffic between the on-premises network and Azure services.

Question 2 — Technical Scenario​

A network engineer is configuring MACsec on an ExpressRoute circuit and needs to define key parameters. They receive the following configuration fragment already applied on the Microsoft side:

MACsec CKN : 0x3031...
MACsec CAK : ********
Cipher Suite: GCM-AES-128

When attempting to establish the MACsec session, the link remains inactive. The engineer verifies that the on-premises equipment is configured with:

cipher-suite: GCM-AES-256
ckn: 0x3031...

What is the most likely cause of the failure?

A) The CKN is incorrect, as values starting with 0x are not accepted on the on-premises side.

B) The cipher suite is incompatible between both sides of the link, as MACsec requires symmetric negotiation of the encryption algorithm.

C) MACsec is not supported on ExpressRoute circuits when configured through the Azure portal; it's necessary to use the REST API directly.

D) The CAK was not provided in the on-premises configuration, and this prevents any cipher suite verification.

Question 3 — True or False​

When implementing IPsec over ExpressRoute using Azure VPN Gateway in active-active mode, each gateway instance establishes independent IPsec tunnels over the same ExpressRoute circuit, and traffic can be distributed across these tunnels to increase the effective encrypted bandwidth available.

Is the statement true or false?

Question 4 — Technical Scenario​

A company wants to implement IPsec over ExpressRoute Private Peering. The architect proposes the topology below:

On-premises VPN Device
        |
        | (ExpressRoute Private Peering)
        |
  Virtual Network Gateway
  (type: VPN, SKU: VpnGw1)
        |
   Azure Virtual Network

During review, the security team questions whether the chosen SKU supports the scenario. Which statement correctly describes the relevant limitation in this topology?

A) The VpnGw1 SKU does not support ExpressRoute-type connections; an ExpressRoute gateway is required for the IPsec tunnel to be established over the circuit.

B) The VpnGw1 SKU supports IPsec over ExpressRoute, but does not support active-active mode, which limits the solution's resilience compared to higher SKUs.

C) The VPN Gateway cannot coexist in the same Virtual Network as an ExpressRoute Gateway; the two connections require separate VNets connected by peering.

D) IPsec over ExpressRoute Private Peering mandatorily requires using a VPN Gateway SKU that supports BGP, and VpnGw1 does not support BGP.

Question 5 — Multiple Choice​

When comparing MACsec and IPsec in the context of encryption over ExpressRoute, which statement correctly represents the functional difference between the two approaches?

A) MACsec operates at the network layer (Layer 3) and protects traffic between IP addresses, while IPsec operates at the data link layer (Layer 2) and protects Ethernet frames.

B) MACsec protects the link between directly connected devices at layer 2, while IPsec creates an end-to-end encrypted tunnel at layer 3, capable of traversing multiple network hops.

C) MACsec and IPsec are mutually exclusive on ExpressRoute; enabling one automatically disables the other on the circuit.

D) IPsec over ExpressRoute is configured exclusively on the Microsoft side and automatically propagated to the on-premises device via BGP, while MACsec requires manual configuration on both sides.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

The central requirement is end-to-end encryption, including protection against provider compromise. MACsec (alternative A) only encrypts the physical link between the on-premises router and the provider's edge router; traffic between the provider and Microsoft travels without additional protection, therefore not meeting the requirement. The correct solution is to configure an IPsec/IKE tunnel over Private Peering, using Azure VPN Gateway as the tunnel terminator on the Azure side. This way, the IP payload is encrypted before entering the ExpressRoute circuit, and encryption persists regardless of any intermediate infrastructure compromise. ExpressRoute Global Reach (C) connects circuits to each other but does not add encryption. Microsoft Peering (D) is used to access public Microsoft services and does not automatically apply transport layer encryption to customer traffic.

Answer Key — Question 2​

Answer: B

MACsec requires both sides of the link to use the same cipher suite. The Microsoft side is configured with GCM-AES-128, while the on-premises device has GCM-AES-256. This incompatibility prevents MACsec session establishment, as there is no automatic algorithm negotiation — the match must be explicit. The CKN in 0x format (A) is valid hexadecimal representation and accepted on both sides. The Azure portal supports MACsec configuration normally (C). The absence of visible CAK in the on-premises configuration (D) is not the described problem; the CAK may be configured correctly without appearing in the displayed fragment, and the divergent cipher suite is a deterministic and verifiable cause of failure.

Answer Key — Question 3​

Answer: False

The statement is false in its conclusive part. In active-active mode, Azure VPN Gateway does create two instances, and each establishes its own IPsec tunnels. However, individual IPsec tunnels do not perform bandwidth aggregation: each TCP flow is forwarded through a single tunnel. Traffic distribution occurs per flow (ECMP), not per packet, and effective bandwidth per flow does not exceed the capacity of a single tunnel. The real benefit of active-active mode over ExpressRoute is resilience and availability, not increased aggregate throughput per session. Confusing flow distribution with increased available bandwidth is a common technical misconception in this scenario.

Answer Key — Question 4​

Answer: B

The VpnGw1 SKU supports IPsec over ExpressRoute Private Peering, so the configuration is technically valid. The real limitation is that VpnGw1 does not support active-active mode, which reduces solution resilience: if the gateway instance fails, there is interruption until the standby instance takes over. Higher SKUs (VpnGw2 and above) support active-active, allowing failover without interruption. Alternative A is wrong because VPN Gateway is exactly the component used for IPsec over ExpressRoute; an ExpressRoute Gateway is not needed for this purpose. Alternative C is wrong because VPN Gateway and ExpressRoute Gateway can coexist in the same VNet — this is a common topology called coexisting connections. Alternative D is wrong because VpnGw1 has supported BGP since its initial version.

Answer Key — Question 5​

Answer: B

The fundamental distinction is the layer of operation. MACsec (IEEE 802.1AE) operates at layer 2 and protects Ethernet frames between two directly connected devices; it does not traverse routers or multiple hops. IPsec operates at layer 3 and creates an encrypted tunnel between IP endpoints, capable of traversing any number of intermediate hops. In the ExpressRoute context, this defines where each technology is applicable: MACsec is suitable for the link between the customer equipment and the provider's edge, while IPsec is suitable for end-to-end protection between the on-premises environment and Azure VNet. Alternative A reverses the operating layers of both technologies. Alternative C is incorrect; both approaches can be combined, operating at different layers. Alternative D describes behavior that does not exist: IPsec over ExpressRoute requires explicit configuration at both endpoints.