Changing the customer gateway of an aws_vpn_connection forces replacement

[wwboynton]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

tl;dr

Changing the CGW associated with a VPN Connection is wrongly forcing destruction and recreation of the VPN connection, which is not consistent with the behaviour of the AWS CLI/Console.

Terraform Version

Terraform v0.12.17
+ provider.aws v2.41.0
+ provider.http v1.1.1
+ provider.null v2.1.2

Affected Resource(s)

• aws_vpn_connection

Terraform Configuration Files

resource "aws_vpn_connection" "yeet" {
  customer_gateway_id = aws_customer_gateway.yeet.id
  transit_gateway_id  = aws_ec2_transit_gateway.yeet.id
  type                = "ipsec.1"
  static_routes_only  = true
}

Output

  # aws_vpn_connection.yeet must be replaced
      ~ customer_gateway_id            = "cgw-xxxxxxxxxxxxxxx" -> "cgw-yyyyyyyyyyyyyyyy" # forces replacement

Expected Behavior

Changing the CGW associated with a VPN should modify the resource in-place which is consistent with the behaviour of the AWS CLI and console.

Actual Behavior

Terraform attempted to destroy and recreate the resource -- this is particularly troublesome with an aws_vpn_connection resource, as one cannot control the public IPs associated with the tunnels provided with it. Upon recreation, one will lose the public IPs that have been used with their VPN, forcing manual reconfiguration of the appliance backing the associated customer gateway.

Steps to Reproduce

1. Create an aws_vpn_connection and associate it with some customer gateway.
2. terraform apply
3. Change the customer_gateway_id parameter of the aws_vpn_connection created in step 1
4. terraform plan
5. Cry

[krwrang]

This is causing trouble for a client when there's a need to update the gateway IP.
How could we get this sorted out?

Currently to work around this issue, we are:

• Creating a new customer gateway from console with correct details
• Associating the new CGW with the VPN connection
• Removing the old CGW from terraform state (terraform state rm)
• Updating the CGW in our .tf files to match the new CGW created through console
• Importing the new CGW to terraform state

This is somewhat cumbersome and prone to errors, we'd really like to see this fixed.

[wwboynton]

@krwrang obviously this doesn't solve the problem at-hand, but it's worth thinking about why your use-case necessitates frequently changing your CGW.

If you are changing back-and-forth between a few known IPs, you could theoretically use a Transit Gateway and multiple VPNs as a workaround, though this might have routing implications.

Maaaaaaybe if this PR idles for a long time, eventually I'll find the time to try to fix this myself, but for the time being I think the chances that this issue will sit idle for the foreseeable future are fairly high, so thinking through options for a better workaround without that level of manual intervention might be beneficial to you.

[krwrang]

@wwboynton I appreciate your concern. Our issue is not about changing one VPN over and over again.

Customers have been instructed that they will be provided with tunnel IPs from our end before they have provided their gateway IP, meaning that sometimes for new customers the VPN connection needs to be created with a false on-prem GW IP. That is then changed when the customer gives their correct details. Changing this flow has proven difficult as it is what they are used to outside of AWS.

This and the occasional human error means that while no CGW is updated/replaced more than once, there will be quite a few of them and therefore this is something we need to tackle.

[kahawai-sre]

We have the same situation as per @krwrang above. Yes changing the customer gateway is an infrequent requirement, but the provider should support it nonetheless given the AWS API allows that, for valid reasons.
Can this please be addressed?

[davidmnoriega]

I'm running into this issue as well. We were hoping to transition the vpn connection from a deprecated vpc to its replacement while keeping the external IPs of the vpn in place by just updating the vpn_gateway_id. The console would let us do this as mentioned above. A pertinent usecase is when working with external partners who have slow change management that would make updating a vpn connection a very long process, thus being able to preserve the vpn connection as AWS documented is valuable.

AWS Site-to-Site VPN User Guide: Modifying a Site-to-Site VPN connection's target gateway

Terraform v0.14.10
+ provider registry.terraform.io/hashicorp/aws v3.36.0

[davidmnoriega]

I found out that if I manually make the change to the vpn connection and update the terraform code to reflect that, terraform plan does not show a planned change to the aws_vpn_connection resource.

[emachnic]

Just ran into this issue today which was super frustrating. It's definitely possible to change the target gateway that the VPN points to in the AWS console without rebuilding the VPN but using Terraform, the entire thing is rebuilt. Unfortunately, this new VPN will have a different public IP address and causes the connection between our on-prem appliance to sever.

[github-actions]

This functionality has been released in v3.72.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.