Monday, 21 July 2025

AWS Site-to-Site VPN


How to Setup a VPN Connection between the office router and AWS VPN?

How to setup a IPSEC VPN Connection between our office router e.g. Cisco ASA and the AWS VPN endpoints?

AWS Virtual Private Network solutions establish secure connections between our on-premises networks, remote offices, client devices, and the AWS global network. 

AWS VPN is comprised of two services: AWS Site-to-Site VPN and AWS Client VPN. 

Each service provides a highly-available, managed, and elastic cloud VPN solution to protect our network traffic.

In this article we'll talk about AWS Site-to-Site VPN.


AWS Site-to-Site VPN 


Network diagram:


on-premise LAN: 192.168.0.0/16 
-----------------------------------------
/ \                         / \
 |                           |
 |  active tunnel            |  passive (standby) tunnel
 |                           |
\ /                         \ /
-----------------------------------------
Router1                    Router 2

VGW - Virtual Gateway 
VPC: 172.16.0.0/16; Route Table: 192.168.0.0/16 ---> VGW-xxxx


Can VPC CIDR and LAN CIDR overlap?

VPN connection consists of two tunnels:
  • active (up and running)
  • passive (down); if first one goes down, this one will take over

VPC route table will need to be modified so traffic destined for 192.168.0.0/16 to be routed to VGW-xxxx


AWS VPN service consists of 3 components:

Creating and configuring a Customer Gateway


Customer Gateway is a resource that we create in AWS that represents the a (customer) gateway device in our on-premises network.

When we create a customer gateway, we provide information about our device to AWS. We or our network administrator must configure the device to work with the site-to-site VPN connection.


We first need to create a Customer Gateway in AWS. We can do that via AWS console or Terraform provider. 



If we click on Create customer gateway, we'll see this form:



Details

  • Name tag
    • optional
    • Creates a tag with a key of 'Name' and a value that we specify.
    • Value must be 256 characters or less in length.
  • BGP ASN
    • The ASN of our customer gateway device.
    • e.g. 65000
    • Value must be in 1 - 4294967294 range.
    • The Border Gateway Protocol (BGP) Autonomous System Number (ASN) in the range of 1 – 4,294,967,294 is supported. We can use an existing public ASN assigned to our network, with the exception of the following:
      • 7224 - Reserved in all Regions
      • 9059 - Reserved in the eu-west-1 Region
      • 10124 - Reserved in the ap-northeast-1 Region
      • 17943 - Reserved in the ap-southeast-1 Region
    • If we don't have a public ASN, we can use a private ASN in the range of 64,512–65,534 or 4,200,000,000 - 4,294,967,294. The default ASN is 65000.
    • It is required if we want to set up dynamic routing. If we want to use static routing, we can use an arbitrary (default) value.
    • Where to find BGP ASN for e.g. UDM Pro?
    • If we want to use IPSec and dynamic routing, then our router device needs to support BGP over IPSec
    • When to use static and when to use dynamic routing?
  • IP address
    • Specify the IP address for our customer gateway device's external interface. This is internet-routable IP address for our gateway's external interface.
    • The address must be static and can't be behind a device performing Network Address Translation (NAT)
    • If office router is connected to ISP via e.g. WAN1 connection, this is the IP of that WAN connection 
    • Basically, this is the office's public IP address.
  • Certificate ARN
    • optional
    • The ARN of a private certificate provisioned in AWS Certificate Manager (ACM).
    • We can select certificate ARN from a drop-down list
    • How is this certificate used?
    • When to use this certificate?
  • Device
    • optional
    • A name for the customer gateway device.

Creating and configuring a Virtual private gateway


A virtual private gateway is the VPN concentrator on the Amazon side of the site-to-site VPN connection. We create a virtual private gateway and attach it to the VPC we want to use for the site-to-site VPN connection.


A VPN concentrator is a specialized networking device designed to manage numerous secure connections (VPN tunnels) for remote users or sites accessing a central network. It acts as a central point for establishing, processing, and maintaining these connections, enabling large organizations to securely connect many users simultaneously. 

Key Functions:
  • Multiple VPN Tunnel Management: VPN concentrators handle a large number of encrypted VPN tunnels simultaneously, allowing multiple users to securely connect to the network. 
  • Centralized Security: They provide a central point for managing and enforcing security policies for all remote connections, ensuring consistent protection. 
  • Scalability: VPN concentrators are designed to handle a large number of users and connections, making them suitable for large organizations with many remote workers or sites. 
  • Traffic Encryption: They encrypt all data transmitted between the remote user and the central network, ensuring secure communication and protecting sensitive information. 
  • Enhanced Security Posture: By managing and controlling all VPN connections, they help organizations maintain a strong security posture and minimize risks associated with remote access. 
How it Works:
  • 1. Remote User Connection: Remote users initiate a VPN connection, which is then routed to the VPN concentrator. 
  • 2. Authentication and Authorization: The concentrator authenticates and authorizes the user, verifying their identity and permissions. 
  • 3. Tunnel Establishment: If the user is authorized, the concentrator establishes an encrypted VPN tunnel between the user's device and the central network. 
  • 4. Secure Communication: All data transmitted through the tunnel is encrypted, protecting it from eavesdropping or interception. 
  • 5. Traffic Management: The concentrator manages and prioritizes traffic within the network, ensuring efficient and secure communication. 
Use Cases:
  • Large Enterprises: Companies with numerous remote employees often use VPN concentrators to provide secure access to their internal network. 
  • Extranet VPNs: VPN concentrators are also used in extranet setups, where multiple organizations need to securely share resources and information. 
  • Large Scale Remote Access: They are ideal for organizations that need to provide secure remote access to a large number of users from various locations. 
In essence, a VPN concentrator is a robust and scalable solution for managing secure remote access in larger organizations, providing the necessary infrastructure for secure and efficient communication across the network




If we click on Create button we'll get this form to fill:


If we select Custom ASN:



Upon creation, VGW will be in detached state. We want to attach it to VPC.
We can select to which VPC we want to attach it to.

To which VPC should Virtual Gateway be attached if we have multiple VPCs, connected via peering connections?


When we have multiple VPCs connected via VPC peering, and we’re setting up a site-to-site VPN to our on-premises network (via UDM Pro + AWS VPN), the Virtual Private Gateway (VGW) must be attached to only one VPC — not multiple.

We should attach the VGW to the VPC that:
  • Has the strongest need for the VPN connectivity
  • Or is logically central to our network design
  • Can route traffic to/from all other VPCs through VPC peering

This is typically a “hub” VPC in a hub-and-spoke architecture.

+-------------------+
|  On-Prem Network  |
| (via UDM Pro VPN) |
+--------+----------+
         |
         | Site-to-site VPN
         |
+--------v----------+
| VPC-A (Hub VPC)   | <-- Attach VGW here
| CIDR: 10.0.0.0/16 |
+--------+----------+
         | VPC Peering
+--------+----------+      +--------+----------+
| VPC-B (Spoke)     |      | VPC-C (Spoke)     |
| CIDR: 10.1.0.0/16 |      | CIDR: 10.2.0.0/16 |
+-------------------+      +-------------------+


Then we need to set up routing
  • In VPC-A (with VGW attached): Add a route to our on-prem CIDR (e.g., 192.168.1.0/24) pointing to the VGW
  • In VPC-B and VPC-C: Add a route to the on-prem CIDR, pointing to the peering connection with VPC-A
  • In on-prem (UDM Pro): Route traffic for 10.0.0.0/8 (or specific VPC CIDRs) over the VPN

Important Caveats:
  • VGW cannot be attached to more than one VPC
    • If we need VPN access to all VPCs, our routing must go through the attached VPC (via peering)
  • We cannot route traffic between peered VPCs and VPNs unless explicitly configured
    • Ensure peering connections allow transitive routing
    • Update route tables manually — AWS does not auto-propagate routes between VGW and peered VPCs
  • Security groups and NACLs in each VPC must allow traffic from on-prem CIDRs


Site to Site VPN Connection


A Site-to-Site VPN connection offers two VPN tunnels between a virtual private gateway or a transit gateway on the AWS side, and a customer gateway (which represents a VPN device) on the remote (on-premises) side.




If we click on Create button:



  • Target gateway type - Choose the existing virtual private gateway or transit gateway for the site-to-site connection. We can select 'Not associated' if we wish to specify at a later time, or we want to use for a connection to Cloud WAN.
  • Customer gateway - A customer gateway provides information to AWS about our customer gateway device or software application. Select an existing customer gateway or create a new customer gateway to use for the VPN connection.
  • Routing options - The type of routing that we select can depend on the make and model of our customer gateway device. 
    • If our customer gateway device supports Border Gateway Protocol (BGP), specify dynamic routing when we configure our Site-to-Site VPN connection.
    • If our customer gateway device does not support BGP, specify static routing. In this case we'll have to set:
      • Static IP prefixes - Enter one or more IP prefixes in CIDR notation separated by commas to advertise to our VPC. It matches on-premise LAN CIDR, e.g. 192.168.0.0/16
      • We need to create aws_vpn_connection_route | Resources | hashicorp/aws | Terraform | Terraform Registry in Terraform. If we plan to use BGP (dynamic routing), we would NOT need aws_vpn_connection_route; instead, we would enable route propagation on our route tables.
  • Pre-shared key storage - Allows us to choose how the pre-shared key (PSK) is stored and managed.
  • Local IPv4 network CIDR
    • optional
    • The IPv4 CIDR range on the customer gateway (on-premises) side that is allowed to communicate over the VPN tunnels. The default is 0.0.0.0/0.
  • Remote IPv4 network CIDR
    • optional
    • The IPv4 CIDR range on the AWS side that is allowed to communicate over the VPN tunnels. The default is 0.0.0.0/0.

The next two sections are about setting Tunnel options for both VPN tunnels.

The fields in this section are the tunnel options that we can configure. This section has been pre-populated with AWS default values.





  • Inside IPv4 CIDR for tunnel 1 (2) - A size /30 IPv4 CIDR block from the 169.254.0.0/16 range.
  • Pre-shared key for tunnel 1 (2) - The pre-shared key (PSK) to establish initial authentication between the virtual private gateway and customer gateway. The pre-shared key must have 8-64 characters. Valid characters: A-Z, a-z, 0-9, _ and . The key cannot begin with a zero.
  • Advanced options for tunnel 1 (2)
  • VPN logging - We can configure tunnel activity logs and publish them to CloudWatch to gain deeper visibility into our VPN.
    • Tunnel activity log - it captures log messages for IPsec activity and DPD protocol messages.
  • Tunnel maintenance
    • Tunnel endpoint lifecycle control -  provides control over the schedule of endpoint replacements.  Tunnel endpoint lifecycle control provides control over the schedule of endpoint replacements. With this feature, we can choose to accept AWS managed updates to tunnel endpoints at a time that works best for our business. Use this feature if we have short-term business needs or can only support a single tunnel per VPN connection.

Configuring VPC Route Table


This is necessary so VPC knows how to route traffic to our on-premise LAN.

We won't use the standard way of editing routs but add a new Route Propagation:



After some time, among Routes, we'll have a CIDR of our on-premise LAN, marked as propagated. This means that all traffic from this VPC to that LAN will go via VGW.


Configuring Firewall


Route tables only direct traffic but firewalls control if and which traffic is allowed at all. There are two types of virtual firewalls in AWS, working at different levels:
  • Access Control List (ACL)
    • works at subnet level - can be attached to VPC or subnet
    • stateless - does not remember the ingress (return traffic is not automatically allowed) so if we want to have a two-way traffic, for each ingress rule we need to define a matching egress rule
    • ACLs operate at the subnet level within a VPC. Each subnet must have exactly one ACL, and all subnets in the VPC default to the VPC's default ACL until changed
    • A subnet can only be associated with one network ACL at a time.
    • A network ACL (NACL) can be associated with multiple subnets.
  • Security Group (SG)
    • works at instance level - can be attached to EC2 instance
    • stateful - we only need to define a single ingress rule which will automatically also apply both for egress; we typically add a single egress rule, which allows all traffic from the resouce
    • Security group rules in AWS are always permissive (there are no deny rules), so the most permissive rule applies
    • EC2 instance can be associated with multiple security groups (up to five security groups by default)
We can use either of these but each approach has its benefits and drawbacks.

ACL rules apply to any resource that gets provisioned in the subnet so we don't need to attach SG to each resource. 


Example of Network Access Control List ingress and egress rules which allow SSH protocol traffic from both remote office LAN and local subnet associated with a referenced ACL:

resource "aws_network_acl_rule" "office_lan_ingress_ssh" {
  network_acl_id = var.acl_id
  rule_number    = 100
  egress         = false
  protocol       = "tcp"
  rule_action    = "allow"
  cidr_block     = var.office_lan_cidr
  from_port      = 22
  to_port        = 22
}

resource "aws_network_acl_rule" "office_lan_egress_ssh" {
  network_acl_id = var.acl_id
  rule_number    = 110
  egress         = true
  protocol       = "tcp"
  rule_action    = "allow"
  cidr_block     = var.office_lan_cidr
  from_port      = 22
  to_port        = 22
}


Example of Security Group in Terraform:


resource "aws_security_group" "office_lan" {
  name        = "allow-office-lan"
  vpc_id      = local.vpc_id
  description = "Allow desired protocols to/from office LAN"

  ingress {
    description = "Allow SSH from office LAN"
    protocol    = "tcp"
    from_port   = 22
    to_port     = 22
    cidr_blocks = [local.my_corp_office_lan_cidr]
  }

  ingress {
    description = "Allow ping (ICMP Echo Request) from office LAN"
    protocol    = "icmp"
    from_port   = 8
    to_port     = -1
    cidr_blocks = [local.my_corp_office_lan_cidr]
  }

  ingress {
    description = "Allow HTTP from office LAN"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = [local.my_corp_office_lan_cidr]
  }

  ingress {
    description = "Allow HTTPS from office LAN"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = [local.my_corp_office_lan_cidr]
  }

  ingress {
    description = "Allow MySQL from office LAN"
    from_port   = 3306
    to_port     = 3306
    protocol    = "tcp"
    cidr_blocks = [local.my_corp_office_lan_cidr]
  }

  ingress {
    description = "Allow MongoDB from office LAN"
    from_port   = 27017
    to_port     = 27017
    protocol    = "tcp"
    cidr_blocks = [local.my_corp_office_lan_cidr]
  }

  egress {
    description = "Allow all egress to office LAN"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = [local.my_corp_office_lan_cidr]
  }

  tags = {
    Name        = "allow-office-lan"
    Environment = terraform.workspace
    Terraform   = true
  }
}


Configuring Gateway Device 


In VPC >> Virtual private network (VPN) >> Site-to-Site VPN connections we'll select newly created VPN Connection and then hit the Download Configuration button in order to download its configuration file. We need to select:
  • Vendor - This is the brand of the on-site Gateway device e.g. Cisco
  • Platform - The model of the on-site Gateway device
  • Software - The OS version of the on-site Gateway device
As this file is very verbose, extract only the config part (not the comments) into a new file.
Open the file in text editor and modify the config. (I'll expand on this)

Load and execute this file in the on-side gateway device terminal.

After this, tunnel should be established.



Checking the Tunnel


The State column should show: available.

Tunnel Details tab should show:
  • Tunnel 1: UP
  • Tunnel 2: DOWN

It is expected that Tunnel 2 is Down as this is the passive (standby) tunnel, activated in case of failover.

To verify that VPN connection is set up properly, we need to test connectivity from both sides.

From the workstation in the office LAN we can try to ping e.g. a test EC2 instance which is running in VPC and has IP e.g. 172.16.0.34.



Posted by at
Labels: , , , , , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)