Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Terraform import aws_vpn_connection does not get tunnel1/2_inside_cidr #4728

Closed
ghost opened this issue Jun 1, 2018 · 7 comments · Fixed by #19311
Closed

Terraform import aws_vpn_connection does not get tunnel1/2_inside_cidr #4728

ghost opened this issue Jun 1, 2018 · 7 comments · Fixed by #19311
Labels
bug Addresses a defect in current functionality. service/ec2 Issues and PRs that pertain to the ec2 service.
Milestone

Comments

@ghost
Copy link

ghost commented Jun 1, 2018

This issue was originally opened by @repl-nealalberda as hashicorp/terraform#18170. It was migrated here as a result of the provider split. The original body of the issue is below.


Long time user, first time contribute, thanks for all you do!. Reworking my VPN connections and forced to import aws_vpn_connection..

terraform import module.vpn_eu-west-1.aws_vpn_connection.xxxxx_wan1_vpn vpn-xxxxxxxx

module.vpn_eu-west-1.aws_vpn_connection.xxxxx_wan1_vpn: Importing from ID "vpn-xxxxxxxx"...
module.vpn_eu-west-1.aws_vpn_connection.xxxxx_wan1_vpn: Import complete!
Imported aws_vpn_connection (ID: vpn-xxxxxxxx)
module.vpn_eu-west-1.aws_vpn_connection.xxxxx_wan1_vpn: Refreshing state... (ID: vpn-xxxxxxxx)

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

Releasing state lock. This may take a few moments...

Upon a plan I get (redacted some info):
-/+ module.vpn_eu-west-1.aws_vpn_connection.xxxxxxx_wan1_vpn (new resource required)
id: "vpn-xxxxxxxx" => (forces new resource)
customer_gateway_id: "cgw-xxxxxxxx" => "${aws_customer_gateway.xxxxx_wan1.id}" (forces new resource)
routes.#: "0" =>
static_routes_only: "false" => "false"
tags.%: "1" => "1"
tags.Name: "xxxxx_wan1_vpn" => "xxxxx_wan1_vpn"
tunnel1_address: "x.x.x.x" =>
tunnel1_bgp_asn: "12345" =>
tunnel1_bgp_holdtime: "30" =>
tunnel1_cgw_inside_address: "169.254.6.6" =>
tunnel1_inside_cidr: "" => "169.254.6.6/30" (forces new resource)
tunnel1_vgw_inside_address: "169.254.6.5" =>
tunnel2_address: "y.y.y.y" =>
tunnel2_bgp_asn: "12345" =>
tunnel2_bgp_holdtime: "30" =>
tunnel2_cgw_inside_address: "169.254.6.10" =>
tunnel2_inside_cidr: "" => "169.254.6.10/30" (forces new resource)
tunnel2_vgw_inside_address: "169.254.6.9" =>
type: "ipsec.1" => "ipsec.1"
vgw_telemetry.#: "2" =>
vpn_gateway_id: "vgw-zzzzzz" => "${aws_vpn_gateway.vpn_gateway_zzzz.id}" (forces new resource)

If I terraform state pull, amend the state file in the appropriate spots with:
"tunnel1_inside_cidr": "169.254.6.6/30",
"tunnel2_inside_cidr": "169.254.6.10/30",
and terraform state push then no new resource is attempted.

Terraform Version

terraform -v

Terraform v0.11.7

  • provider.aws v1.21.0
...

Terraform Configuration Files

resource "aws_vpn_connection" "xxxxxx_wan1_vpn" {
  vpn_gateway_id      = "${aws_vpn_gateway.vpn_gateway_zzzzz.id}"
  customer_gateway_id = "${aws_customer_gateway.xxxxxx_wan1.id}"
  type                = "ipsec.1"
  tunnel1_inside_cidr = "${var.mytun1}"
  tunnel2_inside_cidr = "${var.mytun2}"
  static_routes_only  = false

  tags {
    Name = "xxxxxx_wan1_vpn"
  }
}

Debug Output

Crash Output

Expected Behavior

Actual Behavior

Steps to Reproduce

Additional Context

References

@radeksimko radeksimko added service/ec2 Issues and PRs that pertain to the ec2 service. bug Addresses a defect in current functionality. labels Jun 13, 2018
@sh4d0wz
Copy link

sh4d0wz commented Jul 10, 2019

@radeksimko we are running into this right now, is there a workaround or a patch for this that we can try?

@sgzijl
Copy link

sgzijl commented Nov 22, 2019

@sh4d0wz - the workaround is mentioned in the in de bug report (pull state, amend statefile and plan/apply). Hopefully someone is able to fix this in the import of aws_vpn_connection?

@mpitt
Copy link

mpitt commented Jul 6, 2020

This looks fixed now with

Terraform v0.12.28
+ provider.aws v2.66.0

@berniland
Copy link

berniland commented Jul 9, 2020

Hi, unfortunalty, I just done a new import with 0.12.28 ( start rm before)
field is no empty : but instead of tunnel1_inside_cidr -> we can see the the mask lengh ( probably, the end of 169.254.49.52/30 cidr)
<tunnel_inside_address>
<ip_address>169.254.49.53</ip_address>
<network_mask>255.255.255.252</network_mask>
<network_cidr>30</network_cidr>
</tunnel_inside_address>

Terraform v0.12.28

  • provider.aws v2.69.0

bflad added a commit that referenced this issue Apr 23, 2021
…_*` ordering when `tunnel1_inside_cidr`, `tunnel1_inside_ipv6_cidr`, or `tunnel1_preshared_key` is configured

Reference: #396
Reference: #3359
Reference: #4728
Reference: #5809
Reference: #11293

Previously (race condition of automatically assigned outside IP addresses):

```
=== CONT  TestAccAWSVpnConnection_tunnelOptions
resource_aws_vpn_connection_test.go:210: Step 15/15 error: Check failed: Check 4/6 error: aws_vpn_connection.test: Attribute 'tunnel1_preshared_key' expected "12345678", got "abcdefgh"
--- FAIL: TestAccAWSVpnConnection_tunnelOptions (738.28s)
```

Output from acceptance testing:

```
--- PASS: TestAccAWSVpnConnection_Tunnel1PresharedKey (251.02s)
--- PASS: TestAccAWSVpnConnection_withoutStaticRoutes (263.77s)
--- PASS: TestAccAWSVpnConnection_Tunnel1InsideCidr (335.14s)
--- PASS: TestAccAWSVpnConnection_tunnelOptions (342.30s)
--- PASS: TestAccAWSVpnConnection_disappears (388.07s)
--- PASS: TestAccAWSVpnConnection_tags (445.29s)
--- PASS: TestAccAWSVpnConnection_basic (797.33s)
--- PASS: TestAccAWSVpnConnection_withIpv6 (1235.35s)
--- PASS: TestAccAWSVpnConnection_TransitGatewayID (1235.72s)
--- PASS: TestAccAWSVpnConnection_withEnableAcceleration (1352.28s)
--- PASS: TestAccAWSVpnConnection_Tunnel1InsideIpv6Cidr (1595.79s)
```
bflad added a commit that referenced this issue Apr 23, 2021
…_*` ordering when `tunnel1_inside_cidr`, `tunnel1_inside_ipv6_cidr`, or `tunnel1_preshared_key` is configured (#19077)

* resource/aws_vpn_connection: Prevent flipped `tunnel1_*` and `tunnel2_*` ordering when `tunnel1_inside_cidr`, `tunnel1_inside_ipv6_cidr`, or `tunnel1_preshared_key` is configured

Reference: #396
Reference: #3359
Reference: #4728
Reference: #5809
Reference: #11293

Previously (race condition of automatically assigned outside IP addresses):

```
=== CONT  TestAccAWSVpnConnection_tunnelOptions
resource_aws_vpn_connection_test.go:210: Step 15/15 error: Check failed: Check 4/6 error: aws_vpn_connection.test: Attribute 'tunnel1_preshared_key' expected "12345678", got "abcdefgh"
--- FAIL: TestAccAWSVpnConnection_tunnelOptions (738.28s)
```

Output from acceptance testing:

```
--- PASS: TestAccAWSVpnConnection_Tunnel1PresharedKey (251.02s)
--- PASS: TestAccAWSVpnConnection_withoutStaticRoutes (263.77s)
--- PASS: TestAccAWSVpnConnection_Tunnel1InsideCidr (335.14s)
--- PASS: TestAccAWSVpnConnection_tunnelOptions (342.30s)
--- PASS: TestAccAWSVpnConnection_disappears (388.07s)
--- PASS: TestAccAWSVpnConnection_tags (445.29s)
--- PASS: TestAccAWSVpnConnection_basic (797.33s)
--- PASS: TestAccAWSVpnConnection_withIpv6 (1235.35s)
--- PASS: TestAccAWSVpnConnection_TransitGatewayID (1235.72s)
--- PASS: TestAccAWSVpnConnection_withEnableAcceleration (1352.28s)
--- PASS: TestAccAWSVpnConnection_Tunnel1InsideIpv6Cidr (1595.79s)
```

* tests/resource/aws_vpn_connection: Add nosemgrep comment for errant situation

* resource/aws_vpn_connection: Fix comment typo
bflad added a commit that referenced this issue Apr 23, 2021
…_*` ordering when `tunnel1_inside_cidr`, `tunnel1_inside_ipv6_cidr`, or `tunnel1_preshared_key` is configured (#19077)

* resource/aws_vpn_connection: Prevent flipped `tunnel1_*` and `tunnel2_*` ordering when `tunnel1_inside_cidr`, `tunnel1_inside_ipv6_cidr`, or `tunnel1_preshared_key` is configured

Reference: #396
Reference: #3359
Reference: #4728
Reference: #5809
Reference: #11293

Previously (race condition of automatically assigned outside IP addresses):

```
=== CONT  TestAccAWSVpnConnection_tunnelOptions
resource_aws_vpn_connection_test.go:210: Step 15/15 error: Check failed: Check 4/6 error: aws_vpn_connection.test: Attribute 'tunnel1_preshared_key' expected "12345678", got "abcdefgh"
--- FAIL: TestAccAWSVpnConnection_tunnelOptions (738.28s)
```

Output from acceptance testing:

```
--- PASS: TestAccAWSVpnConnection_Tunnel1PresharedKey (251.02s)
--- PASS: TestAccAWSVpnConnection_withoutStaticRoutes (263.77s)
--- PASS: TestAccAWSVpnConnection_Tunnel1InsideCidr (335.14s)
--- PASS: TestAccAWSVpnConnection_tunnelOptions (342.30s)
--- PASS: TestAccAWSVpnConnection_disappears (388.07s)
--- PASS: TestAccAWSVpnConnection_tags (445.29s)
--- PASS: TestAccAWSVpnConnection_basic (797.33s)
--- PASS: TestAccAWSVpnConnection_withIpv6 (1235.35s)
--- PASS: TestAccAWSVpnConnection_TransitGatewayID (1235.72s)
--- PASS: TestAccAWSVpnConnection_withEnableAcceleration (1352.28s)
--- PASS: TestAccAWSVpnConnection_Tunnel1InsideIpv6Cidr (1595.79s)
```

* tests/resource/aws_vpn_connection: Add nosemgrep comment for errant situation

* resource/aws_vpn_connection: Fix comment typo
@envintus
Copy link

I'm also running into this issue when attempting to import resources. I'm using the latest version of the AWS provider along with the latest version of the AWS VPN Terraform module. After debugging the AWS module I found myself here since this is apparently a provider bug.

Terraform Version

v1.0.3

AWS Provider Version

v3.53

AWS VPN Module Version

v2.10.0

Expected Behavior

Import the existing aws_vpn_connection resource type using the AWS VPN module, which will add the resource to the state. Then run a terraform plan and there should be no changes to the resource that force a replacement and/or the plan should finish stating that there are no changes.

Actual Behavior

I'm able to successfully import the aws_vpn_connection using the AWS VPN module and the defined configuration data. When I run a subsequent teraform plan the plan marks the resource for replacement, because Terraform thinks it needs to update the following attributes, which were provided as part of the import:

  • tunnel1_inside_cidr
  • tunnel2_inside_cidr
  • tunnel1_preshared_key
  • tunnel2_preshared_key

Steps to Reproduce

Import an existing aws_vpn_connection type with provided configuration data for its various attributes then run a terraform plan.

Additional Context

In an effort to troubleshoot what was going on I figured that I could pull the state created from the import and reconcile whatever the issue is. When I pulled the state and inspected it the fields listed in "Actual Behavior" are blank even though the configuration for these attributes are defined in the Terraform configuration and are being set for the resource. All of this is in order upon importing the resource.

I then tried to backfill this attribute configuration data into the state, updated its version, and pushed the state to its remote storage. Upon re-running another terraform plan the plan still marks the aforementioned attributes as changing even though local Terraform configuration code and remote state are now reconciled. A result of which is that Terraform continues to mark the resource for replacement.

This bug is preventing me from successfully managing existing AWS aws_vpn_connection resource types whether it's using the vanilla type in the AWS provider or using the AWS VPN module, which does in fact create the same aws_vpn_connection type.

@github-actions
Copy link

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
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Addresses a defect in current functionality. service/ec2 Issues and PRs that pertain to the ec2 service.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants