Example for VPC + VPN configuration in yaml files

vpcs.yaml

# This file describes all subnets on our WAN. The name 'vpc' is a bit
# misleading since it also refers to non-VPC subnets (e.g. office network,
# physical data centre etc.)
# and also defines the IPSec tunnels between the various locations.
# For the sake of this document, "VPC" is used to refer to any location.
#
# VPC's are configured by a separate stack template than the IPSec tunnels,
# but both template types read this file to know what to do.
#
# The rule is that each VPC can have EITHER incoming OR outgoing
# connections, NOT BOTH.
# (the reason is that if it has both then it will setup both
# a Virtual GW for incoming connections and configure the NAT EC2 for
# outgoing connections, and both will expect to own the public IP and routes
# in the VPC).
#
# 'vpcs' array:
#
# Defines any location, not just AWS VPC's (e.g. offices,
# data centres, old manually configured VPC's)
# A 'real' AWS VPC is denoted by having a 'region' field, which indicates the
# AWS region.
# The 'cidr' field defines the subnet of that VPC and must NOT overlap with
# other VPC's.
# The 'bgp_asn' numbers are taken from the 'private' range of 64512-65534
# (ref: https://tools.ietf.org/html/rfc6996#section-5).
# Unless it's already defined, pick a unique number from this range and use
# it here.
#
# 'connections' array:
#
# Defines the IPSec tunnels between the nodes which are defined in 'vpcs'
# The names directly underneath the 'connections' array are arbitrary and meant
# to be descriptive.
# Under these descriptive grouping names, there are two entries: 'to' and 'from'
#
# Each VPC appearing under 'to':
# * Creates a Virtual Gatwaay (aka VGW) and Customer Gateways (CGW) to
#   accept incoming connections from each of the 'from' entries.
#
# Each VPC appearing under 'from'
# * Run up VyOS EC2 instances controlled by AutoScalingGroup which pulls
#   the IPSec tunnel parameters from the VGW configuration and configures
#   itself according to it.
#
# Each 'connections' entry can define a group of edges with common 'from'
# and 'to', e.g.:
#
# connections:
#   to-sydney-hub:
#     to:
#       - sydney-hub
#     from:
#       - virginia-1
#       - ireland-1
#       - sydney-office:
#         - ip: 203.34.56.78
#
# Defines that:
# * sydney-hub setup a Virtual GW to accept connections and Custom Gateways
#   for each of virginia-1, ireland-1 and sydney-office
# * virginia-1 and ireland-1 configure VyOS EC2 instances to talk to the
#   VGW in sydney-hub
# * sydney-office, which is not a VPC, will have to be configured manually to
#   setup the IPSec tunnels to sydney-hub. It can still use parts of the VyOS
#   automation script to do that since it too runs VyOS.
#   For now, its public IP should be manually inserted to
#   configuration/eips.yaml under the 'public_ip' field.
#   (this is a pending enhancement to the EIP allocation script)
#
# The 'to' array can take multiple entries too, if all the 'from' entries
# are relevant. e.g. add extra hubs in other regions in parallel to
# the Sydney one
vpcs:
  sydney-hub:
    # dedicated VPC just for network hub
    region: ap-southeast-2
    cidr: 10.255.255.240/28
  sydney:
    # existing manually configured VPC in Sydney AWS
    region: ap-southeast-2
    cidr: 192.168.1.0/24
  sydney-dc:
    cidr: 192.168.2.0/24
    bgp_asn: 65002
  office:
    cidr: 192.168.3.0/24
    bgp_asn: 65003
  virginia:
    region: us-east-1
    cidr: 192.168.4.0/24
  oregon:
    region: us-west-2
    cidr: 192.168.5.0/24
  ireland:
    region: eu-west-1
    cidr: 192.168.6.0/24

connections:
  to-sydney-hub:
    to:
      - sydney-hub
    from:
      - sydney
      - sydney-office
      - sydney-dc
      - virginia
      - oregon
      - ireland