GoogleCloudPlatform / GoogleCloudPlatform/pubsec-declarative-toolkit
Add optional peering between client-landing-zone:host-project and projects/hub-env:hub-project for client workload traversals through the fortigate FW
- Dominant language
- Shell
- Stars
- 36
- Forks
- 26
- PR merge metrics
- No merged PRs in 30d
Description
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](https://cloud.google.com/vpc/docs/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
Contributor guide
Assessment
This issue has not been assessed yet.