miguelaferreira
commented
5 years ago Hi @adamthomason. Thanks for reporting this and apologies for the late reply. I don't think this is expected behaviour. Example complete-vpn-gateway-with-static-routes that uses pre-shared keys and tunnels details should cover this case.
I just ran a plan-apply-plan cycle on that example and in the first plan-apply terraform offers to create 28 resources:
(...)
Plan: 28 to add, 0 to change, 0 to destroy.
(...)
Apply complete! Resources: 28 added, 0 changed, 0 destroyed.
Outputs:
vpn_connection_id = vpn-0c9d44d432710088c
vpn_connection_tunnel1_address = 34.251.115.132
vpn_connection_tunnel1_cgw_inside_address = 169.254.33.102
vpn_connection_tunnel1_vgw_inside_address = 169.254.33.101
vpn_connection_tunnel2_address = 63.34.56.91
vpn_connection_tunnel2_cgw_inside_address = 169.254.33.90
vpn_connection_tunnel2_vgw_inside_address = 169.254.33.89On the second plan terraform offers to replace 3 resources
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement
Terraform will perform the following actions:
# module.vpn_gateway.aws_vpn_connection.tunnel_preshared[0] must be replaced
-/+ resource "aws_vpn_connection" "tunnel_preshared" {
~ customer_gateway_configuration = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<vpn_connection id=\"vpn-0c9d44d432710088c\">\n <customer_gateway_id>cgw-05a8696354f104dde</customer_gateway_id>\n <vpn_gateway_id>vgw-0cd65a4a426062da6</vpn_gateway_id>\n <vpn_connection_type>ipsec.1</vpn_connection_type>\n <vpn_connection_attributes>NoBGPVPNConnection</vpn_connection_attributes>\n <ipsec_tunnel>\n <customer_gateway>\n <tunnel_outside_address>\n <ip_address>172.83.124.11</ip_address>\n </tunnel_outside_address>\n <tunnel_inside_address>\n <ip_address>169.254.33.102</ip_address>\n <network_mask>255.255.255.252</network_mask>\n <network_cidr>30</network_cidr>\n </tunnel_inside_address>\n </customer_gateway>\n <vpn_gateway>\n <tunnel_outside_address>\n <ip_address>34.251.115.132</ip_address>\n </tunnel_outside_address>\n <tunnel_inside_address>\n <ip_address>169.254.33.101</ip_address>\n <network_mask>255.255.255.252</network_mask>\n <network_cidr>30</network_cidr>\n </tunnel_inside_address>\n </vpn_gateway>\n <ike>\n <authentication_protocol>sha1</authentication_protocol>\n <encryption_protocol>aes-128-cbc</encryption_protocol>\n <lifetime>28800</lifetime>\n <perfect_forward_secrecy>group2</perfect_forward_secrecy>\n <mode>main</mode>\n <pre_shared_key>abcdefghijklmn1234567890</pre_shared_key>\n </ike>\n <ipsec>\n <protocol>esp</protocol>\n <authentication_protocol>hmac-sha1-96</authentication_protocol>\n <encryption_protocol>aes-128-cbc</encryption_protocol>\n <lifetime>3600</lifetime>\n <perfect_forward_secrecy>group2</perfect_forward_secrecy>\n <mode>tunnel</mode>\n <clear_df_bit>true</clear_df_bit>\n <fragmentation_before_encryption>true</fragmentation_before_encryption>\n <tcp_mss_adjustment>1379</tcp_mss_adjustment>\n <dead_peer_detection>\n <interval>10</interval>\n <retries>3</retries>\n </dead_peer_detection>\n </ipsec>\n </ipsec_tunnel>\n <ipsec_tunnel>\n <customer_gateway>\n <tunnel_outside_address>\n <ip_address>172.83.124.11</ip_address>\n </tunnel_outside_address>\n <tunnel_inside_address>\n <ip_address>169.254.33.90</ip_address>\n <network_mask>255.255.255.252</network_mask>\n <network_cidr>30</network_cidr>\n </tunnel_inside_address>\n </customer_gateway>\n <vpn_gateway>\n <tunnel_outside_address>\n <ip_address>63.34.56.91</ip_address>\n </tunnel_outside_address>\n <tunnel_inside_address>\n <ip_address>169.254.33.89</ip_address>\n <network_mask>255.255.255.252</network_mask>\n <network_cidr>30</network_cidr>\n </tunnel_inside_address>\n </vpn_gateway>\n <ike>\n <authentication_protocol>sha1</authentication_protocol>\n <encryption_protocol>aes-128-cbc</encryption_protocol>\n <lifetime>28800</lifetime>\n <perfect_forward_secrecy>group2</perfect_forward_secrecy>\n <mode>main</mode>\n <pre_shared_key>1234567890abcdefghijklmn</pre_shared_key>\n </ike>\n <ipsec>\n <protocol>esp</protocol>\n <authentication_protocol>hmac-sha1-96</authentication_protocol>\n <encryption_protocol>aes-128-cbc</encryption_protocol>\n <lifetime>3600</lifetime>\n <perfect_forward_secrecy>group2</perfect_forward_secrecy>\n <mode>tunnel</mode>\n <clear_df_bit>true</clear_df_bit>\n <fragmentation_before_encryption>true</fragmentation_before_encryption>\n <tcp_mss_adjustment>1379</tcp_mss_adjustment>\n <dead_peer_detection>\n <interval>10</interval>\n <retries>3</retries>\n </dead_peer_detection>\n </ipsec>\n </ipsec_tunnel>\n</vpn_connection>" -> (known after apply)
customer_gateway_id = "cgw-05a8696354f104dde"
~ id = "vpn-0c9d44d432710088c" -> (known after apply)
~ routes = [
- {
- destination_cidr_block = "10.100.0.1/32"
- source = ""
- state = "available"
},
- {
- destination_cidr_block = "10.200.0.1/32"
- source = ""
- state = "available"
},
] -> (known after apply)
static_routes_only = true
tags = {
"Name" = "VPN Connection between VPC vpc-0cc1c0738d8faab4c and Customer Gateway cgw-05a8696354f104dde"
}
+ transit_gateway_attachment_id = (known after apply)
~ tunnel1_address = "34.251.115.132" -> (known after apply)
+ tunnel1_bgp_asn = (known after apply)
~ tunnel1_bgp_holdtime = 0 -> (known after apply)
~ tunnel1_cgw_inside_address = "169.254.33.102" -> (known after apply)
tunnel1_inside_cidr = "169.254.33.88/30"
~ tunnel1_preshared_key = (sensitive value)
~ tunnel1_vgw_inside_address = "169.254.33.101" -> (known after apply)
~ tunnel2_address = "63.34.56.91" -> (known after apply)
+ tunnel2_bgp_asn = (known after apply)
~ tunnel2_bgp_holdtime = 0 -> (known after apply)
~ tunnel2_cgw_inside_address = "169.254.33.90" -> (known after apply)
tunnel2_inside_cidr = "169.254.33.100/30"
~ tunnel2_preshared_key = (sensitive value)
~ tunnel2_vgw_inside_address = "169.254.33.89" -> (known after apply)
type = "ipsec.1"
~ vgw_telemetry = [
- {
- accepted_route_count = 2
- last_status_change = "2019-07-01 07:54:38 +0000 UTC"
- outside_ip_address = "63.34.56.91"
- status = "DOWN"
- status_message = ""
},
- {
- accepted_route_count = 2
- last_status_change = "2019-07-01 07:57:26 +0000 UTC"
- outside_ip_address = "34.251.115.132"
- status = "DOWN"
- status_message = ""
},
] -> (known after apply)
vpn_gateway_id = "vgw-0cd65a4a426062da6"
}
# module.vpn_gateway.aws_vpn_connection_route.default[0] must be replaced
-/+ resource "aws_vpn_connection_route" "default" {
destination_cidr_block = "10.100.0.1/32"
~ id = "10.100.0.1/32:vpn-0c9d44d432710088c" -> (known after apply)
~ vpn_connection_id = "vpn-0c9d44d432710088c" -> (known after apply) # forces replacement
}
# module.vpn_gateway.aws_vpn_connection_route.default[1] must be replaced
-/+ resource "aws_vpn_connection_route" "default" {
destination_cidr_block = "10.200.0.1/32"
~ id = "10.200.0.1/32:vpn-0c9d44d432710088c" -> (known after apply)
~ vpn_connection_id = "vpn-0c9d44d432710088c" -> (known after apply) # forces replacement
}
Plan: 3 to add, 0 to change, 3 to destroy.This seems to reproduce what you are experiencing. I will look into it.
Alien2150
maartenvanderhoef
antonbabenko
bugok
cdaniluk
maartenschalekamp
omahonyb
github-actions[bot]
fabioformosa
module.vpn_gateway.aws_vpn_connection.preshared Attempts to compute a new ID each run, and also also forces new resource based on preshared keys. Is this expected behaviour? The state objects looks perfectly fine to me.