feat(vpn): add BGP filter resources and gateway/connection SDK updates

[steffenkoenig]

Description

Reflects vpn changes:

• New stackit_vpn_bgp_filter and stackit_vpn_bgp_filter_rule resources and data sources, supporting the new gateway-scoped BGP route filtering API.
• stackit_vpn_gateway gains an optional network_config block (predefined_network_prefix, routing_table_id).
• stackit_vpn_connection's tunnel bgp block gains inbound_filter_id, linking a tunnel's BGP session to a stackit_vpn_bgp_filter, with tri-state set/clear/leave-untouched handling on update.
• integrity_algorithms now additionally accepts sha2_512. sha1 remains supported but is deprecated (SDK enum change, no code change needed since values are derived dynamically); a plan-time warning is now emitted when sha1 is configured, pointing users toward sha2_256/sha2_384/sha2_512 instead.

Checklist

• Issue was linked above
• Code format was applied: make fmt
• Examples were added / adjusted (see examples/ directory)
• Docs are up-to-date: make generate-docs (will be checked by CI)
• Unit tests got implemented or updated
• Acceptance tests got implemented or updated (see e.g. here)
• Unit tests are passing: make test (will be checked by CI)
• No linter issues: make lint (will be checked by CI)

[cgoetz-inovex]

Hi @steffenkoenig,
thanks for your contribution, I've created an internal issue to review this PR

[github-actions]

This PR was marked as stale after 7 days of inactivity and will be closed after another 7 days of further inactivity. If this PR should be kept open, just add a comment, remove the stale label or push new commits to it.

[devpie]

It would be really great to have this functionality in one of the next releases <3

[itrich]

It seems that predefined_network_prefix must be a string, not an array. The VPN Gateway API blocks any payload with predefinedNetworkPrefix set as an array with error 500. See stackitcloud/stackit-api-specifications#69

We will have to wait for a new release of the Go SDK to fix this.

[devpie]

Thanks for catching this. One detail is worth pinning down before a new SDK release is planned around it.

This comment reports HTTP 500, while stackitcloud/stackit-api-specifications#69 reports HTTP 400 for the array payload and includes a response body with "status": "BAD_REQUEST".

The two point at different fixes:

• 400 means the server rejects the array at validation. The contract is then a single string, and only the spec needs correcting.
• 500 means the array is not handled at all. That is a server-side defect on top of the spec fix, and correcting the spec alone would not close it.

I asked the same question in the issue. For context I also added this there: predefinedNetworkPrefix carries no type at all in the spec, only items plus a scalar example. It is the only such property in the file, which is why both the Go and the Python generator produce a list.

[devpie]

One note on how far this blocker actually reaches, since it does not affect all of network_config.

It only hits predefined_network_prefix. A block that sets just routing_table_id never puts an array on the wire:

• toNetworkConfigPayload guards the prefix with tfutils.IsUndefined, which is IsUnknown() || IsNull(). An omitted predefined_network_prefix is null, so NetworkConfig.PredefinedNetworkPrefix stays nil.
• The SDK's NetworkConfig.ToMap writes predefinedNetworkPrefix only when IsNil returns false, and it returns true for a nil slice. The key is therefore absent from the request body.

So this configuration is untouched by the spec bug:

network_config = {
  routing_table_id = stackit_routing_table.example.routing_table_id
}

That covers serialization only. Whether the API accepts a custom routing table is untested in this PR: TestAccVpnGatewayResourceMax asserts TestCheckResourceAttrSet on network_config.routing_table_id, which the default table assigned by the API already satisfies, and gateway-max.tf sets only the prefix. A case that passes an existing routing table id would close that gap.

Worth mentioning because it means the routing table part of this PR could be usable ahead of the spec fix.

[itrich]

I just tested this branch in our local setup and it throws an error:

│ Error: Value Conversion Error
│ 
│   with module.stackit.module.mack_one.module.connect.module.hub.module.dev.module.hub_dev_vpn.stackit_vpn_gateway.this,
│   on modules/stackit-vpn-gateway/main.tf line 15, in resource "stackit_vpn_gateway" "this":
│   15:   network_config = var.network_config
│ 
│ An unexpected error was encountered trying to build a value. This is always an error in the provider. Please report the following to the provider developer:
│ 
│ Received unknown value, however the target type cannot handle unknown values. Use the corresponding `types` package type or a custom type that handles unknown values.
│ 
│ Path: network_config
│ Target Type: *gateway.NetworkConfigModel
│ Suggested Type: basetypes.ObjectValue

We're creating the VPN Gateway in a reusable module with network_config set as a variable.

The resource in our Terraform module:

resource "stackit_vpn_gateway" "this" {
  project_id   = var.project_id
  display_name = "${data.stackit_resourcemanager_project.this.name}-vpn-gw"
  plan_id      = var.plan_id
  routing_type = var.routing_type
  availability_zones = {
    tunnel1 = var.availability_zones.tunnel1
    tunnel2 = var.availability_zones.tunnel2
  }

  network_config = var.network_config
}

and the corresponding variable:

variable "network_config" {
  description = "Network configuration for the VPN gateway. Leave null to have the network prefix assigned automatically."
  type = object({
    predefined_network_prefix = optional(list(string))
    routing_table_id          = optional(string)
  })
  default = null
}

I think using basetypes is safer here for optional values, see also Europa-Park-DD@572dc0c#diff-238f9f2b61941094893b6851aab64dac70d5582b03fbd2c22ba6f0d34dc6fd0fR22-R64 on how we set this up.