creating a R81.20 gw in AWS with terraform

[Daniel_Kavan]

RE: main.tf

https://github.com/CheckPointSW/CloudGuardIaaS/blob/master/terraform/aws/gateway-master/main.tf

https://github.com/CheckPointSW/CloudGuardIaaS/blob/master/terraform/aws/gateway-master/variables.tf

We are getting an error where it doesn't like the syntax of commenting out the contents of this block

provider "aws" {
//    region = var.region
//    access_key = var.access_key
//    secret_key = var.secret_key
}

because it's a deprecated method, but it  is how they say to do it in the CP documentation

╷
│ Error: Cannot override provider configuration
│
│   on main.tf line 33, in module "launch_gateway_into_vpc":
│   33:     aws = aws
│
│ The configuration of module.launch_gateway_into_vpc has its own local configuration for aws, and so it cannot
│ accept an overridden configuration provided by the root module.

which refers to this

module "launch_gateway_into_vpc" {
  source = "../gateway"
  providers = {
    aws = aws
  }

which I believe is referring to this

provider "aws" {
    region = var.region
    access_key = var.access_key
    secret_key = var.secret_key
}

[meravbe]

Hi,

The comments:

provider "aws" {
//    region = var.region
//    access_key = var.access_key
//    secret_key = var.secret_key
}

Need to be in two places:
1. main.tf in gateway folder

2. main.tf in gateway-master folder

Do you have it in both places?
 

[Daniel_Kavan]

When we comment it out in both places it prompts us to ask for the region and keys

although, we do have the region and keys in terraform.tfvars 

commenting it out in both places is for putting the region and keys in environment variables

If we put those in environment variables and run terraform plan we get these errors now.   Well the overall network is 10.4.0.0/16 we want several 24 bit subnets.

╷
│ Warning: Redundant empty provider block
│
│   on ../gateway/main.tf line 1:
│    1: provider "aws" {
│
│ Earlier versions of Terraform used empty provider blocks ("proxy provider configurations") for child modules to declare their need to be passed a provider configuration by their callers. That approach was ambiguous and is now
│ deprecated.
│
│ If you control this module, you can migrate to the new declaration syntax by removing all of the empty provider "aws" blocks and then adding or updating an entry like the following to the required_providers block of
│ module.launch_gateway_into_vpc:
│     aws = {
│       source = "hashicorp/aws"
│     }
╵
╷
│ Error: Error in function call
│
│   on ../modules/vpc/main.tf line 17, in resource "aws_subnet" "public_subnets":
│   17:   cidr_block = cidrsubnet(aws_vpc.vpc.cidr_block, var.subnets_bit_length, each.value)
│     ├────────────────
│     │ while calling cidrsubnet(prefix, newbits, netnum)
│     │ aws_vpc.vpc.cidr_block is "10.4.0.0/16"
│     │ each.value is "1"
│     │ var.subnets_bit_length is 24
│
│ Call to function "cidrsubnet" failed: insufficient address space to extend prefix of 16 by 24.
╵
╷
│ Error: Error in function call
│
│   on ../modules/vpc/main.tf line 30, in resource "aws_subnet" "private_subnets":
│   30:   cidr_block = cidrsubnet(aws_vpc.vpc.cidr_block, var.subnets_bit_length, each.value)
│     ├────────────────
│     │ while calling cidrsubnet(prefix, newbits, netnum)
│     │ aws_vpc.vpc.cidr_block is "10.4.0.0/16"
│     │ each.value is "2"
│     │ var.subnets_bit_length is 24
│
│ Call to function "cidrsubnet" failed: insufficient address space to extend prefix of 16 by 24

[Daniel_Kavan]

We are moving ahead now, changing var.subnets_bit_length to 8 may fix it, 16+8=24

variable "subnets_bit_length" {
type = number
description = "Number of additional bits with which to extend the vpc cidr. For example, if given a vpc_cidr ending in /16 and a subnets_bit_length value of 4, the resulting subnet address will have length /20."

[Daniel_Kavan]

I closed this case, but I'm still trying to figure out what this does

 each.value is "2"

[meravbe]

We are using the 'cidrsubnet' function from Terraform (https://developer.hashicorp.com/terraform/language/functions/cidrsubnet).

The 'each.value' parameter represents the value in either public_subnet_map or private_subnet_map,

which will be used to populate the additional bits added to the 'vpc_cidr'.

In your case, for 'public_subnet_map' you set the region to 1, 'vpc_cidr' to 10.4.0.0/16 and 'subnets_bit_length' to 24.
The 'cidrsubnet' function attempted to calculate a subnet address, but the result was invalid - '10.4.1.0/40'.
After you corrected the 'subnets_bit_length', the function now returns 10.4.1.0/24.

[Daniel_Kavan]

Interesting.  So, what would change in the above scenario  setting the region/'each.value to 2?    Using 1 as each value the public network of 10.4.1.0/24 and private network of 10.4.2.0/24 was created. 

Actually, 'each.value'isn't in Main.tf, that was just in the error message, so there is no each.value variable to set.

[meravbe]

One of the parameters in terraform.tfvars is:
 

public_subnets_map = {
  "us-east-1a" = 1
}

During the deployment preperation we use the 'for_each' function (from terraform) in vpc/main.tf:

resource "aws_subnet" "public_subnets" {
  for_each = var.public_subnets_map
  vpc_id = aws_vpc.vpc.id
  availability_zone = each.key
  cidr_block = cidrsubnet(aws_vpc.vpc.cidr_block, 
  var.subnets_bit_length, each.value)
  map_public_ip_on_launch = true
  tags = {
    Name = format("Public subnet %s", each.value)
  }
}

According to the code above:
for_each = { "us-east-1a" = 1}
each.key = "us-east-1a"
each.value = 1

When a function fails, terraform prints the function's name and the value of the parameters.
This is why in your case 'each.value' represents the value of the region in 'public_subnets_map'.
 

[Daniel_Kavan]

Thanks meravbe!

Another issue we're running into is that the gw was created with R81, jhf82 and we wanted R81.20 jhf24.   We are looking for the scripts.

[Roman_Kats]

Hi Daniel,
In the terraform.tfvars file you can change gateway_version from R81-BYOL to desired version
In the README.md file we provide all possible options

Thanks,
Roman

[Daniel_Kavan]

Looking good now!  

Currently, we have a CP gw being created in one VPC and the linux servers using another VPC and networks.  We're trying to consolidate it all into one being under one umbrella (VPC/network).  Specifically getting a couple of nginx & haproxy servers to form in the same private network and VPC we just created, behind this new CP gateway. 

Also, Is CME just for auto-provisioning?   I’m wondering if there is any use with terraform as far as when a gw is destroyed and added.

https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CME/Content/Topics-CME/CME_Structure_...