vpn route propagation should be on aws_vpn_gateway resource type

[ringods]

Hello,

In the AWS provider, I have the impression that the vpn route propagation functionality is implemented on the wrong resource type. Currently it is on aws_route_table.

I am building an infrastructure with multiple VPCs. As an example, take a software lifecycle example where you have a staging and a production VPC. They are stored as environments on Atlas.
These VPC's have the following resources each, constructed from the same module but with different arguments:

• 1 aws_vpc
• 1 aws_internet_gateway
• 2 public aws_subnets, each in a different AZ
• 2 private aws_subnets, each in a different AZ
• 1 public aws_route_table
• 1 private aws_route_table
• the required aws_route_table_associations

but not an aws_vpn_gateway. I definitely don't want one attached to my production VPC.

Now I want to connect my network to the development VPC, so I create a separate Terraform setup, import the remote state for development and hook up a aws_vpn_gateway to it. So far so good, but I can't modify the private aws_route_table anymore for route propagation.

The documentation for EnableVgwRoutePropagation reads:

Enables a virtual private gateway (VGW) to propagate routes to the specified route table of a VPC.

The actor seems to be the VGW, rather than the route table. Can this option be added to the aws_vpn_gateway resource type?

Ringo

[toddmichael]

I agree with @ringods on this one. I'm building my VPCs out, including routing tables, via module where there is not yet any knowledge of VPN gateways. I then selectively create my VPNs and it seems logical that it would be here that I would create the association with my routing tables. Interested in getting some feedback on this one. Thanks.

[phinze]

Thanks for the report - this logic makes sense to me.

[feanil]

Being able to pass in a set of RouteTableIds at VGW creation time would be great. Another option would be to create a new resource that is the route propagation. So you can create the VGW and Route Tables whenever and then determine propagation independently later if you want.

[eliranbz]

+1
It makes it really difficult working with modules as you are not managing the route_table (on your sub-module) but rather the routes.

[leighmhart]

+1 - similar to several folks above, we create VPCs in modules and come back later and add VPNs in modules - making it difficult to retrospectively update the route table association to propagate the VPN routes.

[aiwilliams]

I am working to configure an AWS Direct Connect link with a Virtual Private Gateway that I would like to have propagate its routes to the VPC routing table (AWS API). It sounds like this is the right place to request that feature in Terraform!

[aiwilliams]

After configuring propagation on the route table in the AWS UI, I ran terraform plan and discovered it cares about the setting, leading to this: https://www.terraform.io/docs/providers/aws/r/default_route_table.html#propagating_vgws

Sorry for the noise. Hope it helps another n00b 😊

[aaroncaito]

+1 same workflow configuring direct connect with vpn redundancy

[sirmarkwei]

+1 whilst having the "propagating_vgws" argument when creating a route_table helps. It only makes sense if you have your VGW's created at the time you are creating a route table.

We're running into the same problem as DjxDeaf whilst working with modules.

We have a core module that is systematically creating subnets and other components of our VPC. Certain VPC environments have VGW/VPN tunnel setups. Currently there is no way to 'add-on' this "VPNGatewayRoutePropagation" at the time of creation of your VGW.

[mkamlesh]

+1 Any plans of addressing this issue in near future?

[charles-d-burton]

I'm currently also running into this issue.

[apparentlymart]

Hi everyone! Sorry for the long silence here.

I reviewed the API and Terraform code around the VPN gateway associations, and learned that although enabling and disabling the propagation are separate actions in the API, reading the setting is done by reading the route table, since the data comes from the propagatingVgwSet attribute of RouteTable.

It would seem therefore that AWS considers this to be a property of the route table, which I suppose makes sense if you consider that the propagation behavior adds new routes to the route table, and so both of the sources of route data (the static routeSet and the automatic propagatingVgwSet) are kept together on the route table.

However, I can definitely see the argument that this approach is non-ideal for Terraform, since it forces the config creating the resource to "know about" the VPN connection, rather than the other way around.

Were we starting from scratch here, I'd consider making aws_vpn_gateway_route_propagation a separate resource, which uses the EnableVgwRoutePropagation, DisableVgwRoutePropagation and DescribeRouteTables actions to create one association at a time.

Doing that requires breaking a little the behavior of the existing propagating_vgws attribute, since we'll need to make it possible to omit it in config without Terraform deleting all of the existing gateway relationships. That seems like a minor inconvenience compared to the current situation, though.

[ghost]

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.