Transitive VPC Challenges in GCP: A Phantom VM Approach

Overcome transitive VPC limitations in Google Cloud.

Net Ninja

Network and Automation Architect

Google Cloud

Transitive VPC Challenges in GCP: A Phantom VM Approach

Introduction

Google Cloud Platform (GCP) offers robust networking features, including Virtual Private Clouds (VPCs) and VPC peering, to facilitate secure communication within and between networks. However, a persistent challenge arises in scenarios where VPCs cannot directly exchange prefixes due to the transitive VPC issue. In this article, we delve into a comprehensive solution involving the deployment of a Phantom VM within an intermediate VPC, enabling seamless communication between distinct VPCs with distinct subnets.

The Transitive VPC Challenge

Transitive VPC Diagram

Consider a scenario with three VPCs: VPC1 (172.16.1.0/24), VPC2 (172.16.2.0/24), and an intermediate VPC3 (172.16.100.0/24). Due to the transitive VPC issue, VPC1 and VPC2 cannot establish direct peering, hindering the flow of traffic between their subnets.

The Phantom VM Solution

To address this challenge, we implement a Phantom VM within VPC3, acting as an intermediary for traffic between VPC1 and VPC2. The following detailed steps outline the implementation:

  1. Creation of Phantom VM:

    • Instantiate a Linux VM within VPC3, connecting it to the VPC3 network through a single interface.
  2. Subnet Configuration:

    • VPC1: 172.16.1.0/24
    • VPC2: 172.16.2.0/24
    • VPC3: 172.16.100.0/24 (Intermediate)
  3. Routing Configuration on Phantom VM:

    • Configure a summary route on the Phantom VM for the collective address space of VPC1 and VPC2 (172.16.0.0/16), with the next hop pointing to the Phantom VM itself.
  4. Advertisement to VPCs:

    • Advertise the summary route (172.16.0.0/16) from the Phantom VM to both VPC1 and VPC2 using Cloud Router configurations.
  5. IP Forwarding Enablement and Static Route Addition on Phantom VM:

    # Enable IP forwarding temporarily (valid until the next reboot)
    sudo sysctl -w net.ipv4.ip_forward=1
    
    # Enable IP forwarding persistently (across reboots)
    echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
    sudo sysctl -p
    
    # Add a static route for the combined address space (172.16.0.0/16)
    sudo ip route add 172.16.0.0/16 via 172.16.100.1
    

Traffic Flow Descriptions

With the Phantom VM configured, traffic flows seamlessly between hosts in VPC1 and VPC2:

VPC1 to VPC3:

  • A host in VPC1 initiates traffic destined for VPC2.
  • VPC1, with a route for 172.16.0.0/16 received through VPC3, forwards the traffic to VPC3.

Processing at Phantom VM:

  • VPC3 routes incoming traffic to the Phantom VM.
  • The Phantom VM forwards the traffic to its gateway within VPC3.

VPC3 to VPC2:

  • The gateway in VPC3, using a specific route for 172.16.0.0/16, directs the traffic towards VPC2.

Arrival at VPC2:

  • VPC2 receives the traffic from VPC3 and seamlessly delivers it to the intended host.

Conclusion

Deploying a Phantom VM within an intermediate VPC emerges as a powerful solution to overcome the transitive VPC issue in GCP. This meticulous approach ensures a detailed configuration of routes, IP forwarding, and routing on the Phantom VM, facilitating efficient and secure communication between VPCs with distinct subnets.

Something not clear?

Our expertise in infrastructure architecture, combined with a commitment to innovation, makes us the perfect partner for your journey