Conversation
…3 have registered.
![peqy[bot]](https://avatars.githubusercontent.com/in/1930020?s=60&v=4){kind=small}
There was a problem hiding this comment.
Found a couple of blockers around firewall rule validity and the WireGuard tunnel CIDR conflicting with the VPC subnet. Also flagged a couple of items that will cause churn/confusion (external key generation + unused state bucket var).
Found 5 issues (3 critical, 2 improvements).
| @@ -0,0 +1,33 @@ | |||
| [Interface] | |||
| Address = ${server_ip}/24 | |||
There was a problem hiding this comment.
Critical WireGuard tunnel CIDR overlaps the VM’s VPC subnet
Address = ${server_ip}/24 will try to add a 10.0.0.0/24 route via wg0, which conflicts with the instance’s existing 10.0.0.0/24 route on its primary NIC (since the WireGuard VPC subnet is also 10.0.0.0/24). wg-quick up will typically fail with “RTNETLINK answers: File exists”, or routing becomes ambiguous.
Fix: use a dedicated tunnel CIDR that does not overlap the VPC subnet (preferred), or set the WireGuard interface address to
/32and route peers viaAllowedIPs(and keep the VPC subnet on a different range).
| } | ||
|
|
||
| source_ranges = [var.node_cidr, var.pod_cidr] | ||
| destination_ranges = [var.master_cidr] |
There was a problem hiding this comment.
Critical destination_ranges requires direction = "EGRESS"
This rule is currently defaulting to INGRESS, but sets destination_ranges. GCP/Terraform rejects this combination.
Fix: set
direction = "EGRESS"and addtarget_tags = ["gke-${var.environment}"](or drop the rule entirely since egress is currently allowed by default).
| } | ||
|
|
||
| source_ranges = [var.wireguard_cidr] | ||
| destination_ranges = [var.master_cidr] |
There was a problem hiding this comment.
Critical destination_ranges on an ingress firewall rule
gke_wireguard_to_master defaults to INGRESS but sets destination_ranges, which isn’t valid for ingress firewall rules.
Fix: remove
destination_ranges(and accept that this becomes a network-wide allow fromwireguard_cidrto tcp/443), or replace this approach with something that can actually scope to the control-plane endpoint (often master authorized networks is sufficient).
|
|
||
| # Generate server key pair via wg genkey | ||
| data "external" "server_key" { | ||
| program = ["bash", "-c", "priv=$(wg genkey); pub=$(echo \"$priv\" | wg pubkey); jq -n --arg p \"$priv\" --arg b \"$pub\" '{private_key: $p, public_key: $b}'"] |
There was a problem hiding this comment.
Improvement Key generation via data.external will churn and requires local deps
This runs wg + jq on the machine running Terraform and (because it’s a data source) will typically produce new keys on refresh/plan, forcing perpetual diffs and potentially recreating the VM / peer configs.
Fix: generate keys once and pass them in (tfvars/Secret Manager), or persist them (e.g.,
local_file+ read-back), or use a provider/resource designed for stable key material rather than an always-changing external data source.
| type = string | ||
| } | ||
|
|
||
| variable "terraform_state_bucket" { |
There was a problem hiding this comment.
Improvement terraform_state_bucket is currently unused
Terraform backend config can’t reference var.terraform_state_bucket, so this variable will never affect where state is stored.
Fix: either remove it, or document clearly that the bucket must be provided via
terraform init -backend-config=bucket=...(and don’t suggest it’s controlled by tfvars).
1 participant
This PR introduces changes from the
feat/wiregurad-vpn-tmpbranch.📝 Summary
📁 Files Changed ( 41 files)
📋 Commit Details
✅ Checklist
🧪 Testing
📸 Screenshots (if applicable)
🔗 Related Issues