Answer: Configure the tunnel with LOCAL_TS set to 192.168.100.0/22 and REMOTE_TS set to 172.16.100.0/22.

### Why B is correct (based on official Google Cloud documentation: https://cloud.google.com/network-connectivity/docs/vpn/concepts/choosing-networks-routing#ts-ip-ranges) The scenario specifies: - On-premises legacy VPN device that **only supports IKEv1** and cannot use BGP. - A **Classic VPN** gateway is already configured. - Need for a **policy-based VPN tunnel**. According to the Google Cloud documentation on traffic selectors: > “When you use IKEv1, you can only supply a single CIDR for the local traffic selector and a single CIDR for the remote traffic selector. … Cloud VPN does not support creating a VPN tunnel by using IKEv1 with multiple Child SAs, each with a single CIDR.” Because of this strict IKEv1 limitation (single Child SA per tunnel), you **cannot** specify multiple individual /24 subnets in the traffic selectors (as option C attempts). Option C would only work with **IKEv2**. **Recommended approach for multiple subnets with IKEv1**: - Use a single, broader **supernet** (/22 in this case) that **summarizes** (covers) all the required subnets on each side. - On-premises subnets: 172.16.100.0/24 + 172.16.101.0/24 + 172.16.102.0/24 → summarized as **172.16.100.0/22** - Google Cloud subnets: 192.168.100.0/24 + 192.168.101.0/24 + 192.168.102.0/24 → summarized as **192.168.100.0/22** **Traffic selector configuration (from Cloud VPN perspective)**: - **LOCAL_TS** (GCP side) = **192.168.100.0/22** - **REMOTE_TS** (on-premises side) = **172.16.100.0/22** This matches **option B** exactly. On the on-premises legacy device, you must configure the **reversed** selectors (local = on-prem 172.16.100.0/22, remote = GCP 192.168.100.0/22) to match. ### Additional important points for the exam - After creating the tunnel with these broad selectors, Google Cloud automatically creates **static routes** in the VPC for the remote range (172.16.100.0/22) pointing to the tunnel (when using the console). - You may need to create **more specific static routes** if you want finer control, but the traffic selector itself must be the single summarized CIDR for IKEv1 compatibility. - The /22 summarization works cleanly here because the three /24s are contiguous and align properly under 172.16.100.0/22 and 192.168.100.0/22. - **Option A** has the LOCAL_TS and REMOTE_TS swapped — that is incorrect. - **Option C** tries to list multiple /24s — not supported with IKEv1 on Cloud VPN. - **Option D** uses 0.0.0.0/0 for remote — this turns it into route-based behavior and is not a proper policy-based setup for specific subnets. ### Best practices / alternatives (for real-world or exam context) - If possible, upgrade the on-premises device to support **IKEv2** → then option C (multiple CIDRs) becomes valid. - Prefer **HA VPN** with BGP (dynamic routing) whenever the on-premises side can support it — it uses 0.0.0.0/0 selectors and avoids these limitations entirely. - For legacy IKEv1-only devices: summarization (supernetting) + policy-based static routing is the standard workaround. This question tests your understanding of **IKEv1 traffic selector limitations** in Classic VPN policy-based tunnels. It's a common exam topic.