Terraform complains about invalid CIDR when both variables and resource references are used to define cidr_blocks of the aws_security_group rule

[drscre]

terraform v0.9.1

I am using a variable and a reference to ip of the aws instance to define CIDR for ingress rule of the aws_security_group.

variable "test_ip" {
  default = "192.168.102.10"
}

resource "aws_instance" "test" {
  instance_type = "t2.micro"
  ami = "test"
}

resource "aws_security_group" "test" {
  name = "test"
  vpc_id = "123"

  ingress {
    from_port = "80"
    to_port = "80"
    protocol = "tcp"
    cidr_blocks = ["${aws_instance.test.private_ip}/32", "${var.test_ip}/32"]
  }
}

Terraform thinks the code above is invalid because
* aws_security_group.test: "ingress.0.cidr_blocks.1" must contain a valid CIDR, got error parsing: invalid CIDR address: ${var.test_ip}/32

But he is completely happy if I remove either of the CIDRs.
The following works:

  ingress {
    cidr_blocks = [
      "${var.test_ip}/32"
    ]
  }

And the following works as well:

  ingress {
    cidr_blocks = [
      "${aws_instance.test.private_ip}/32"
    ]
  }

I guess this happens because I mix different interpolations: a variable and a resource reference

[bittopaz]

Got the same problem here.

[grubernaut]

Hi @drscre and @bittopaz, thanks for the issue!

This was actually just fixed in #13046, and will be released in the next minor version of Terraform (v0.9.2). Happy to answer any further questions as well. Thanks again!

[joestump]

Is it possible there's been a regression on this? Just ran into this exact problem in 0.10.2. TF is throwing an invalid CIDR error on a valid CIDR block.

[grubernaut]

@joestump absolutely possible. What are you using for a CIDR block that's throwing the issue? And is the issue occurring during a plan or an apply?

[duncanhall]

@grubernaut I'm also seeing this (or a related issue). I'm supplying a tfvars file in the command invocation.

Planning executes without error:

terraform plan -var-file="tfvarsfilename"

...
aws_subnet.public_c: Creating...
  assign_ipv6_address_on_creation: "" => "false"
  availability_zone:               "" => "eu-west-1c"
  cidr_block:                      "" => "10.3.0.0/22"
  ipv6_cidr_block:                 "" => "<computed>"
  ipv6_cidr_block_association_id:  "" => "<computed>"
  map_public_ip_on_launch:         "" => "false"
  tags.%:                          "" => "1"
  tags.Name:                       "" => "Public C"
  vpc_id:                          "" => "vpc-xxxxxxxx"
...

Running apply with the exact same tfvars throws the invalid CIDR error:

terraform apply -var-file="tfvarsfilename"

...
* aws_subnet.public_c: 1 error(s) occurred:

* aws_subnet.public_c: Error creating subnet: InvalidSubnet.Range: The CIDR '10.3.0.0/22' is invalid.
        status code: 400, request id: 91e7f6fd-40f9-4d92-a3ef-24aa8d606a7d
...

The CIDR 10.3.0.0/22 seems valid to me. Is this a bug or am I doing something silly?

[grubernaut]

Hey @duncanhall,

If the error is thrown at apply time (as shown above), that is an error coming directly from the AWS API, you can see the request code as a 400 in the error output: status code: 400, request id: 91e7f6fd-40f9-4d92-a3ef-24aa8d606a7d

I would either check with amazon's documentation for a subnet in the EU-West-1C region, or contact AWS support with that request ID as to why that error is being thrown from the AWS API.

[duncanhall]

Thanks @grubernaut, you're right. I'm still figuring out why that CIDR block is invalid but it's definitely AWS and not TF. Changing the subnet to a 10.0.3.0/24 range solved my issue.

[grubernaut]

@duncanhall ah nice, glad that worked. Yeah TF only validates that the provided CIDR is in the correct notation, not whether it's possible or not 😄

[aking1012]

This is the page you're looking for: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#VPC_Sizing
Find on the page:"The following table provides an overview of permitted and restricted CIDR block associations, which depend on the IPv4 address range in which your VPC's primary CIDR block resides."

There are some wacky rules that specifically forbid things that technically on real networking gear WOULD work.

[neeleshkorade]

Thanks @aking1012 for the aws doc link. However, based on that, if 10.0.0.0/8 CIDR range is valid, why would I get the same error for a subnet CIDR of 10.1.0.0/19 for a VPC CIDR of 10.1.0.0/16?

[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.