The GCP PubSec Declarative Toolkit is a collection of declarative solutions to help you on your Journey to Google Cloud. Solutions are designed using Config Connector and deployed using Config Controller.
Apache License 2.0
30
stars
26
forks
source link
Add optional peering between client-landing-zone:host-project and projects/hub-env:hub-project for client workload traversals through the fortigate FW #847
Workloads traversing the hub-env fortigate cluster require peering with the client-landing-zone host project.
Alternatively as in #843 - create a services project directly against a shared VPC mode hub-env project.
"Hub and spoke with VPC peering
While the VPC Peering itself is non-transitive (two VPC networks can communicate only if directly peered), it's different if peering is combined with custom route and a routing NVA (network virtual appliance). A custom route created in the hub VPC with next hop set to FortiGate (or ILB fronting a FortiGate cluster) can be exported to all peered VPCs using export custom route property. The route imported to peered spoke VPCs will apply to all traffic leaving the spoke VPC sending it to the FortiGate appliance. Note that the route table is evaluated only once when the packet is leaving its source, it is not re-evaluated once the packet crosses the peering (so it's not affected by a peered subnet route in the hub VPC when on the way to FortiGate). It is important to note that the default route in spoke VPCs would take precedence over the route imported via the peering and thus has to be deleted."
Workloads traversing the hub-env fortigate cluster require peering with the client-landing-zone host project. Alternatively as in #843 - create a services project directly against a shared VPC mode hub-env project.
see lab https://www.cloudskillsboost.google/focuses/77469?catalog_rank=%7B%22rank%22%3A1%2C%22num_filters%22%3A0%2C%22has_search%22%3Atrue%7D&parent=catalog&search_id=29858686
"Hub and spoke with VPC peering While the VPC Peering itself is non-transitive (two VPC networks can communicate only if directly peered), it's different if peering is combined with custom route and a routing NVA (network virtual appliance). A custom route created in the hub VPC with next hop set to FortiGate (or ILB fronting a FortiGate cluster) can be exported to all peered VPCs using export custom route property. The route imported to peered spoke VPCs will apply to all traffic leaving the spoke VPC sending it to the FortiGate appliance. Note that the route table is evaluated only once when the packet is leaving its source, it is not re-evaluated once the packet crosses the peering (so it's not affected by a peered subnet route in the hub VPC when on the way to FortiGate). It is important to note that the default route in spoke VPCs would take precedence over the route imported via the peering and thus has to be deleted."
existing state