I'm trying to build an AWS terraform IPSec VPN config. However, I can't remember where to find the AWS IPSec IP address; the terraform cgw documentation says the ip_address field is required.
The answer should assume the VPN will be attached to my AWS Transit Gateway.
My terraform:
resource "aws_customer_gateway" "cgw-abbv-for-local-and-remote" {
bgp_asn = 65001
ip_address = "A.B.C.D" #<-- I need this IP before terraform apply
type = "ipsec.1"
tags = {
Name = "insert-cgw-name-here"
}
}
resource "aws_vpn_connection" "vpn-abbv-for-local-and-remote" {
customer_gateway_id = aws_customer_gateway.cgw-abbv-for-local-and-remote.id
transit_gateway_id = aws_ec2_transit_gateway.my-tgw-name.id
type = aws_customer_gateway.cgw-abbv-for-local-and-remote.type
tags = {
Name = "insert-vpn-name-here"
}
}
Seems like OP already found the answer, but let me add my two cents since I spent a lot of time figuring things out when it comes to AWS VPN two years ago in order to pass the AWS Advanced Networking cert. This could potentially turn out useful for folks that are new to VPN - especially in the AWS ecosystem:
There is a fantastic book called AWS Certified Advanced Networking Official Study Guide which I would recommend everyone in a cloud network engineer role to read. [1]
It points out the following:
After you create a VPN connection, the VPN tunnel activates when traffic is generated
from your side of the VPN connection. The VGW is not the initiator; your customer gateway must initiate the tunnels. If your VPN connection experiences a period of idle time (usually
10 seconds, depending on your configuration), the tunnel may go down. This is because
AWS uses an on-demand DPD mechanism. If AWS receives no traffic from a VPN peer for
10 seconds, AWS sends a DPD “R-U-THERE” message. If the VPN peer does not respond
to three successive DPDs, the VPN peer is considered dead and AWS closes the tunnel. [pp. 100, 101]
At the non-AWS end of a VPN connection, the VPN is terminated on a customer gateway.
A customer gateway is the AWS term for the VPN termination device at the customer’s onpremises end. A customer gateway can also be hosted in AWS as an EC2 instance running
VPN software that meets the requirements given in the next section.
Most customers don’t require the purchase of an additional device and can reuse an
existing on-premises VPN termination device to create a tunnel to a VPC. [p. 110]
You can use any third-party VPN device that supports Layer 3 VPN technologies. AWS
does not support Layer 2 VPN technologies.
IPsec is used for the VGW at the AWS end of VPN termination, and so the IPsec protocol must be supported by your VPN device. You will set up two VPN tunnels per VGW.
Support for BGP routing protocol is optional but recommended for advanced routing capabilities. Other routing protocols like Open Shortest Path First (OSPF) are not supported by
AWS. You must ensure that you have opened the right ports in your on-premises firewall
for the IPsec traffic to flow. [p. 111]
That is in particular: both ends of the VPN connection must possess a public IP address!
If you didn't already, I really really recommend skipping through these pages to be aware of best-practices and the AWS-way of thinking when it comes to (hybrid) cloud architectures. You avoid getting confused afterwards if things didn't go the way you wanted to. IPSec (i.e. Layer-3) VPNs are harder to get right then most people think. One should be aware of all the routing and security relevant stuff such as: IKE, SAs, Policy-based routing, NAT-Traversal, ISAKMP etc. [see also p. 97: VPN Features -> Security & Routing sections].
Another good reference is the AWS Site-to-Site VPN guide (PDF). [2]
Also good to know: Many terraform attributes can also be found in the AWS CloudFormation docs. The docs for the AWS::EC2::CustomerGateway resource's IpAddress attribute state [3]:
The Internet-routable IP address for the customer gateway's outside interface. The address must be static.
[1] https://www.programmer-books.com/wp-content/uploads/2019/04/AWS-Certified-Advanced-Networking-Official-Study-Guide.pdf
[2] https://docs.aws.amazon.com/vpn/latest/s2svpn/s2s-vpn-user-guide.pdf
[3] https://docs.aws.amazon.com/de_de/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-customer-gateway.html#cfn-ec2-customergateway-ipaddress
This is not very clear in the terraform documentation, but I found an example on the internet that clarified this question.
In short, the aws_customer_gateway config is not on the AWS side of the IPSec tunnel... these resources are "remote" with respect to AWS:
So in this case, the ip_address will be the destination ip address of AWS IPSec packets leaving the AWS Transit Gateway; the aws_customer_gateway ip_address is not owned by AWS.
The ip_address for the Customer Gateway is the IP of the physical appliance/router sitting on-premise in the customer's data center. You need this ip_address to establish a VPN connection. The AWS docs help when you get lost in terraform as well.
Related
I have what I think is a reasonably straightforward setup in Google Cloud - A GKE cluster, a Cloud SQL instance, and a "Click-To-Deploy" Kafka VM instance.
All of the resources are in the same VPC, with firewall rules to allow all traffic to the internal VPC CIDR blocks.
The pods in the GKE cluster have no problem accessing the Cloud SQL instance via its private IP address. But they can't seem to access the Kafka instance via its private IP address:
# kafkacat -L -b 10.1.100.2
% ERROR: Failed to acquire metadata: Local: Broker transport failure
I've launched another VM manually into the VPC, and it has no problem connecting to the Kafka instance:
# kafkacat -L -b 10.1.100.2
Metadata for all topics (from broker -1: 10.1.100.2:9092/bootstrap):
1 brokers:
broker 0 at ....us-east1-b.c.....internal:9092
1 topics:
topic "notifications" with 1 partitions:
partition 0, leader 0, replicas: 0, isrs: 0
I can't seem to see any real difference in the networking between the containers in GKE and the manually launched VM, especially since both can access the Cloud SQL instance at 10.10.0.3.
Where do I go looking for what's blocking the connection?
I have seen that the error is relate to the network,
however if you are using gke on the same VPC network, you will ensure to configure properly the Internal Load Balancer, also I saw that this product or feature is BETA version, this means that it is not yet guaranteed to work as expected, another suggestion is that you ensure that you are not using any policy, that maybe block the connection, I found the next article on the community that maybe help you to solve it
This gave me what I needed: https://serverfault.com/a/924317
The networking rules in GCP still seem wonky to me coming from a long time working with AWS. I had rules that allowed anything in the VPC CIDR blocks to contact anything else in those same CIDR blocks, but that wasn't enough. Explicitly adding the worker nodes subnet as a source for a new rule opened it up.
I have some Cloud SQL instances that currently have public IP's. It would make certain security-minded people happy if I changed them to have private IP's.
I am following the instructions documented here: https://cloud.google.com/sql/docs/mysql/private-ip
A summary of those instructions:
Ensure your shared VPC host has servicenetworking.googleapis.com enabled
Ensure your project has servicenetworking.googleapis.com enabled
Allocate an IP address range for your new private IP's
Configure VPC network peering (https://cloud.google.com/sql/docs/mysql/configure-private-services-access)
Create cloud sql instance without public IP
Expect new instance's private IP to be in allocated range
I've completed these through step 4, and I'm seeing this:
My interpretation of that page is that I've done my part and now it's google's turn--but that was several days ago. Do I have do do something to prompt google to create the connection?
I think I'm focusing in the right place because if I try to use I private IP, gcloud tells me to go create the network that I'm waiting on:
❯ gcloud --project=my-project-name beta \
sql instances patch foo \
--network=my-network-name --no-assign-ip
The following message will be used for the patch API method.
{"name": "foo", "project": "my-project-name", "settings": {"ipConfiguration": {"ipv4Enabled": false, "privateNetwork": "https://compute.googleapis.com/compute/v1/projects/my-project-name/global/networks/my-network-name"}}}
Patching Cloud SQL instance...failed.
ERROR: (gcloud.beta.sql.instances.patch) [INTERNAL_ERROR] Failed to create subnetwork. Please create Service Networking connection with service 'servicenetworking.googleapis.com' from consumer project '11111111111' network 'my-network-name' again.
In general private services access is implemented as a VPC peering connection between your VPC network and the Google services VPC network where your Cloud SQL instance resides. As #JohnHanley pointed out, the VPC peering should be created within minutes so it’s not expected you have to wait more than that.
To check the peering creation on Stackdriver you can use the following Advanced Filter:
jsonPayload.event_subtype="compute.networks.addPeering"
That said, it makes sense the error you are observing when trying to patch your SQL Instance as the Peering hasn’t been created. Instead of ‘Inactive’ it should be ‘Peer VPC network is connected’
To sum up, in your scenario the Cloud SQL instance cannot get an IP on the aforementioned network as it cannot reach it.
At this specific point I would suggest you focus on the Peering creation. As you mentioned you tried recreating it and the status remains the same, it’s possible that there’s something in your project preventing the peering to be established.
I would also suggest you check the peering limits quota in case it has been reached:
gcloud compute networks peerings list --network='your network'
Also it would be good to review the VPC Peering Restrictions.
All that being said, if you still experience the same issue when creating the VPC Peering, an internal investigation may be required and I would suggest you to you to report this using this link
I hope this helps.
I am trying to replicate the steps in this post. However, When I get to the step where I create the ad connector, it fails with the following error:
Connectivity issues detected: DNS unavailable (TCP Port 53) for IP 10.0.0.4, DNS unavailable (TCP Port 53) for IP 10.0.0.5. Please ensure that the listed ports are available and retry the operation
I am very proficient with AWS. However, I'm struggling with Azure and feel I may have misconfigured something. I have carried out the following steps thus far:
In Azure, I used an existing resource group and created "Azure AD Domain Services" instance using default configuration
Basics
Name: sy******k.com
Subscription: Pay-As-You-Go
Resource Group:
Default Region: UK South
SKU: Standard Forest type: User
Network
Virtual network: (new) aadds-vnet
Subnet: (new) aadds-subnet
Subnet Address: 10.0.0.0/24
Network Security Group: (new) aadds-nsg
I created a site to site vpn connection with azure virtual network. However, I am not sure about this step in the post: "The tunnels must be configured to allow traffic from your AADDS endpoints and the Subnets" How exactly do I do this?
In AWS VPC cidr is 10.1.0.0/16 and both tunnels between AWS VPC and Azure Virtual Network are up and connected. I tried to contact the post author: "Justin Stokes" directly but can't find any emails for him. I cannot find a single online guide on how to set this up step by step along with the site to site ipsec setup. It would be very very helpful if someone can provide a video tutorial for this step by step from A-Z instead of leaving a chunk of the steps out of the guide.
The troubleshooting guide here suggest that the firewall i.e. network security group is not allowing port 53TCP/UDP inbound for AD Connector. But I updated the networks security group as a test with a rule to allow any source, any destination and any port and still I'm getting the same error.
I am not the expert in both AWS and Azure but succeeded to setup VPN using this guide.
Then set up AD Connector and had to take tip of creating DHCP Option set from this post.
AD Connector created successfully now. EC2 instances launch with correct DNS server and suffix however they are not joined to AD, that's where I am now. If you have anything or completed this setup, please share.
We have a very difficult problem here, we have a Windows Server 2019 Base x64 on Amazon EC2, connected through RDP and setup-ed forest and activated AD DS , also activated DNS. But whenever we try to connect we are not allowed to.
We have opened all the relevant ports on inbound traffic rules.
We have added users.
We have tried searching internet and various tutorials.
In Server Manager=:
Added the public ipv4 address to our ipv4 settings of the adapter.
Went to the computer setting in computer domain entered the domain but no fun.
Disabled the firewall in server manager.
We want to connect our clients on different network to connect to the server hosted else-where on AWS.
We are really new into this can some one guide through this?
Please make sure there is network connectivity between your client and you DC which is set up on EC-2 Instance.
[1] In case your clients are on AWS (meaning different EC-2 Instances), and in a different network, you need to create VPC peering or use Transit Gateway, so that it has proper network connectivity.
[2] In case your clients are not on AWS, and in an On-prem Environment, you need to have a VPN connection between your client and your DC.
So in Summary, you need to have network connectivity between your client and DC so that clients can join your Domain.
What do you mean whenever we try to connect we are not allowed to?
What are you trying to connect to, the Windows EC2 instance?
Are you saying that the instance is joined to AWS Directory Service domain but you can't connect to the instance using one of the users in your AWS directory?
Edit: This should have been a comment but couldn't post comments at the time of answering.
Customer Gateway
A customer gateway is the anchor on your side of that connection. It
can be a physical or software appliance.
Customers can connect multiple customer gateways
(CGW) to a single VPC virtual private gateway (VGW) or can connect a
single router to multiple VPC VGWs.
Is there a difference between a router and customer gateway? From AWS faq section https://aws.amazon.com/vpc/faqs/#C9, it seems they are one and the same.
A Customer Gateway is the generic name describing a device that can speak IPSec and terminate the tunnels.
It could be a router, it could be a Linux server, but perhaps the most commonly used device is a hardware firewall device from a vendor like Cisco, Juniper, Sonicwall, etc.
Some routers can serve the purpose, but many routers do not have the capability of performing all of the things a customer gateway needs to do.
The section called Your Customer Gateway is written from the perspective of explaining this device to a technical person responsible for implementing one.
Your company has decided to use an optional Amazon VPC VPN connection that links your data center (or network) to your Amazon VPC virtual private cloud (VPC). A customer gateway is the anchor on your side of that connection. It can be a physical or software appliance.
It explains the necessary requirements in high-level, yet technical terms.