GoogleCloudPlatform / GoogleCloudPlatform/pubsec-declarative-toolkit
IaaS workload: verify ingress/egress for IDS or Fortigate firewalls
- Dominant language
- Shell
- Stars
- 36
- Forks
- 26
- PR merge metrics
- No merged PRs in 30d
Description
A canary app for ingress/egress testing of NGFW (PA/IDS or Fortigates)
Redirect inbound traffic to a frontend VM running in Google Cloud behind FortiGate
Secure outbound traffic from Google Cloud to Internet
Secure east-west traffic between VMs running in Google Cloud
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."
Contributor guide
Assessment
This issue has not been assessed yet.