As of now, there is a lack of a route creation resource to accompany the ones currently available that do the initial tasks of endpoint creation:
There is currently an open pull request (https://github.com/terraform-providers/terraform-provider-aws/pull/7564) to rework the initial resource to include the authorization ingress, but not the route creation. Relevant developer: @slapula
+1
As a workaround, it is possible to automate this via the CLI until this is implemented
resource "null_resource" "client_vpn_route_internet" {
provisioner "local-exec" {
when = "create"
command = "aws ec2 create-client-vpn-route --client-vpn-endpoint-id ${aws_ec2_client_vpn_endpoint.client_vpn.id} --destination-cidr-block 0.0.0.0/0 --target-vpc-subnet-id ${aws_subnet.subnet_az1.id} --profile ${var.profile}"
}
provisioner "local-exec" {
when = "destroy"
command = "aws ec2 delete-client-vpn-route --client-vpn-endpoint-id ${aws_ec2_client_vpn_endpoint.client_vpn.id} --destination-cidr-block 0.0.0.0/0 --target-vpc-subnet-id ${aws_subnet.subnet_az1.id} --profile ${var.profile}"
}
}
You can also use a cloudformation stack resource :
resource "aws_cloudformation_stack" "public_route" {
name = "PublicRoute"
parameters = {
TargetCidr = "0.0.0.0/0"
SubnetId = "${var.subnet_id}"
Description = "Route for vpn to go to outside world"
ClientVpnEndpointId = "${aws_ec2_client_vpn_endpoint.client_vpn.id}"
}
template_body = <<STACK
Parameters:
TargetCidr:
Type: String
SubnetId:
Type: String
Description:
Type: String
ClientVpnEndpointId:
Type: String
Resources:
Route:
Type: AWS::EC2::ClientVpnRoute
Properties:
ClientVpnEndpointId: !Ref ClientVpnEndpointId
Description: !Ref Description
DestinationCidrBlock: !Ref TargetCidr
TargetVpcSubnetId: !Ref SubnetId
STACK
}
As a workaround, it is possible to automate this via the CLI until this is implemented
resource "null_resource" "client_vpn_route_internet" { provisioner "local-exec" { when = "create" command = "aws ec2 create-client-vpn-route --client-vpn-endpoint-id ${aws_ec2_client_vpn_endpoint.client_vpn.id} --destination-cidr-block 0.0.0.0/0 --target-vpc-subnet-id ${aws_subnet.subnet_az1.id} --profile ${var.profile}" } provisioner "local-exec" { when = "destroy" command = "aws ec2 delete-client-vpn-route --client-vpn-endpoint-id ${aws_ec2_client_vpn_endpoint.client_vpn.id} --destination-cidr-block 0.0.0.0/0 --target-vpc-subnet-id ${aws_subnet.subnet_az1.id} --profile ${var.profile}" } }
This solution will become sooner or later strictly invalid. As latest versions of Terraform show, they are gliding more into invalidate references to other resources during the destroy phase, as they can "cause dependency cycles and interact poorly with create_before_destroy".
My latest runs are showing:
Warning: External references from destroy provisioners are deprecated
Destroy-time provisioners and their connection configurations may only
reference attributes of the related resource, via 'self', 'count.index', or
'each.key'.References to other resources during the destroy phase can cause dependency
cycles and interact poorly with create_before_destroy.
Does anyone know the best way to get the submitted PR reviewed?
The null_resource workaround will cease to work in terraform 0.13 when specifying non-self var references in destroy provisioners will be treated as an error.
Hi, I dont know why my PR isnt reviewed :-(
@bflad @gdavison
can you provide some guidance to help get this reviewed and merged? this is a pretty painful shortcoming and as mentioned above, the current workarounds will break with the next release of terraform. Thanks.
This has been released in version 2.70.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 for triage. Thanks!
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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!
Most helpful comment
@bflad @gdavison
can you provide some guidance to help get this reviewed and merged? this is a pretty painful shortcoming and as mentioned above, the current workarounds will break with the next release of terraform. Thanks.