GCP VPC, Firewall Rules and Cloud NAT on STACKIT

One firewall rule, rewritten as a security group

A small network written for this page and assessed by StackToIT on 4 November 2026: two subnetworks, four firewall rules, a Cloud Router with Cloud NAT and a reserved address. Left: the HTTPS rule of the input. Right: the resource blocks of the STACKIT Terraform the run wrote; the review comments above each block in the file are left out here.

resource "google_compute_firewall" "web_https" {
  name      = "allow-https-web"
  network   = google_compute_network.core.name
  direction = "INGRESS"
  priority  = 1000

  allow {
    protocol = "tcp"
    ports    = ["443"]
  }

  source_ranges = ["0.0.0.0/0"]
  target_tags   = ["web"]
}

resource "stackit_security_group" "web_https" {
  project_id = var.project_id
  name       = "allow-https-web"
}

resource "stackit_security_group_rule" "web_https_allow_https_web" {
  project_id        = var.project_id
  security_group_id = stackit_security_group.web_https.security_group_id
  direction         = "ingress"
  ether_type        = "IPv4"
  ip_range          = "0.0.0.0/0"
  port_range = {
    max = 443
    min = 443
  }
  protocol = {
    name = "tcp"
  }
}

• Direction, range and port carry over

  The ingress rule for TCP 443 from 0.0.0.0/0 becomes one rule of a security group with the same range and port.

• The target tag does not

  The source applies the rule to instances tagged web. STACKIT has no tag selector, so the run leaves a decision: which network interfaces list this group.

• Priority is dropped

  STACKIT security group rules have no priority, and the run records that the order the source relied on is not carried.

Cloud NAT and the egress deny rule

The part of the network where the models differ most. Left: the end of the input file, from the rule that denies outgoing SMTP through the Cloud Router and the reserved address to the NAT gateway. Right: the one block the run wrote for them.

resource "google_compute_firewall" "deny_egress_smtp" {
  name      = "deny-egress-smtp"
  network   = google_compute_network.core.name
  direction = "EGRESS"
  priority  = 900

  deny {
    protocol = "tcp"
    ports    = ["25"]
  }

  destination_ranges = ["0.0.0.0/0"]
}

resource "google_compute_router" "core" {
  name    = "core-router"
  region  = "europe-west3"
  network = google_compute_network.core.id
}

resource "google_compute_address" "nat" {
  name   = "core-nat-ip"
  region = "europe-west3"
}

resource "google_compute_router_nat" "core" {
  name                               = "core-nat"
  router                             = google_compute_router.core.name
  region                             = "europe-west3"
  nat_ip_allocate_option             = "MANUAL_ONLY"
  nat_ips                            = [google_compute_address.nat.self_link]
  source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"
}

resource "stackit_public_ip" "nat" {
  project_id = var.project_id
}

• The reserved address becomes a public IP

  The run classes it DIRECT, and notes that the address itself changes, so DNS entries and partner allowlists need updating.

• The NAT gateway has no block

  Outbound access for servers without a public IP is part of the STACKIT network. The run says that a fixed egress address which partners allowlist is not kept that way.

• The deny rule is a redesign

  A security group only allows. The run classes the rule REDESIGN and explains how to rebuild the intent as explicit egress rules.

How the network estate maps

Every row is a unit of the run on the example estate: ten resources scanned, nine migration units. The Cloud Router has no unit of its own; it is the place where the NAT configuration lives.

Classes as the run decided them. The example sets no lock file for the Google provider, so every unit stays at medium confidence at best; the egress deny rule is rated low.

Where the two models differ in practice

The Google Cloud column follows the VPC firewall and Cloud NAT documentation; the STACKIT column follows the security group, public IP and network documentation, and the run output where it says so.

The order that works

Practice, tied to the files the run writes.

1. 01

   List the rules by what they select

   Read each firewall rule for its target (all instances, tags or service accounts), its direction and its priority. The run keeps one security group per rule and the findings say which ones select by tag.

2. 02

   Decide the network shape

   Subnetworks become networks. If they must reach each other privately across projects, they join a Network Area; ranges are then taken from the area.

3. 03

   Attach groups to interfaces

   The manual steps of the run, in execution/manual/actions.md, list which network interfaces name each group. Resolve every tag into a group or into ranges.

4. 04

   Rebuild the deny rules

   For an egress deny, delete the default egress rules after apply and create an egress rule for every destination the source still allows.

5. 05

   Fix the outbound address

   If a partner allowlists your NAT addresses, give the servers that call it a public IP and send the new address before cutover.

6. 06

   Verify after a minute

   Test reachability with the rules in place and wait for propagation before you judge a rule.

Questions network teams ask

Sources

• Google Cloud: VPC firewall rules
• Google Cloud: Cloud NAT overview
• STACKIT docs: Security group concepts
• STACKIT docs: Public IP address concepts
• STACKIT docs: Network Area concepts
• Google Cloud: Using IAP for TCP forwarding
• STACKIT Terraform provider v0.121.0: stackit_security_group_rule