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.

Tuesday, 8 July 2025

How to install MongoDB Shell (mongosh) on Mac

 


The main Homebrew repository no longer includes MongoDB due to licensing changes made by MongoDB Inc. So to install MongoDB-related tools (like mongosh, mongodb-community, or mongod), we need to use their own tap (mongodb/brew), which contains these formulas.

Tap is a package source (formula repository).


Let's add tap maintained by MongoDB to our local Homebrew setup:

% brew tap mongodb/brew

To install mongo shell:

% brew install mongosh

Verification:

% mongosh --version 
2.5.3


If we now run it with no arguments, it will try to connect to the local instance:

% mongosh                    
Current Mongosh Log ID: 6853eadee32b5e6cd3cc5d2f
Connecting to: mongodb://127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&appName=mongosh+2.5.3
MongoNetworkError: connect ECONNREFUSED 127.0.0.1:27017

Let's explore the arguments:

% mongosh --help

  $ mongosh [options] [db address] [file names (ending in .js or .mongodb)]

  Options:

    -h, --help                                 Show this usage information
    -f, --file [arg]                           Load the specified mongosh script
        --host [arg]                           Server to connect to
        --port [arg]                           Port to connect to
        --build-info                           Show build information
        --version                              Show version information
        --quiet                                Silence output from the shell during the connection process
        --shell                                Run the shell after executing files
        --nodb                                 Don't connect to mongod on startup - no 'db address' [arg] expected
        --norc                                 Will not run the '.mongoshrc.js' file on start up
        --eval [arg]                           Evaluate javascript
        --json[=canonical|relaxed]             Print result of --eval as Extended JSON, including errors
        --retryWrites[=true|false]             Automatically retry write operations upon transient network errors (Default: true)

  Authentication Options:

    -u, --username [arg]                       Username for authentication
    -p, --password [arg]                       Password for authentication
        --authenticationDatabase [arg]         User source (defaults to dbname)
        --authenticationMechanism [arg]        Authentication mechanism
        --awsIamSessionToken [arg]             AWS IAM Temporary Session Token ID
        --gssapiServiceName [arg]              Service name to use when authenticating using GSSAPI/Kerberos
        --sspiHostnameCanonicalization [arg]   Specify the SSPI hostname canonicalization (none or forward, available on Windows)
        --sspiRealmOverride [arg]              Specify the SSPI server realm (available on Windows)

  TLS Options:

        --tls                                  Use TLS for all connections
        --tlsCertificateKeyFile [arg]          PEM certificate/key file for TLS
        --tlsCertificateKeyFilePassword [arg]  Password for key in PEM file for TLS
        --tlsCAFile [arg]                      Certificate Authority file for TLS
        --tlsAllowInvalidHostnames             Allow connections to servers with non-matching hostnames
        --tlsAllowInvalidCertificates          Allow connections to servers with invalid certificates
        --tlsCertificateSelector [arg]         TLS Certificate in system store (Windows and macOS only)
        --tlsCRLFile [arg]                     Specifies the .pem file that contains the Certificate Revocation List
        --tlsDisabledProtocols [arg]           Comma separated list of TLS protocols to disable [TLS1_0,TLS1_1,TLS1_2]
        --tlsFIPSMode                          Enable the system TLS library's FIPS mode

  API version options:

        --apiVersion [arg]                     Specifies the API version to connect with
        --apiStrict                            Use strict API version mode
        --apiDeprecationErrors                 Fail deprecated commands for the specified API version

  FLE Options:

        --awsAccessKeyId [arg]                 AWS Access Key for FLE Amazon KMS
        --awsSecretAccessKey [arg]             AWS Secret Key for FLE Amazon KMS
        --awsSessionToken [arg]                Optional AWS Session Token ID
        --keyVaultNamespace [arg]              database.collection to store encrypted FLE parameters
        --kmsURL [arg]                         Test parameter to override the URL of the KMS endpoint

  OIDC auth options:

        --oidcFlows[=auth-code,device-auth]    Supported OIDC auth flows
        --oidcRedirectUri[=url]                Local auth code flow redirect URL [http://localhost:27097/redirect]
        --oidcTrustedEndpoint                  Treat the cluster/database mongosh as a trusted endpoint
        --oidcIdTokenAsAccessToken             Use ID tokens in place of access tokens for auth
        --oidcDumpTokens[=mode]                Debug OIDC by printing tokens to mongosh's output [redacted|include-secrets]
        --oidcNoNonce                          Don't send a nonce argument in the OIDC auth request

  DB Address Examples:

        foo                                    Foo database on local machine
        192.168.0.5/foo                        Foo database on 192.168.0.5 machine
        192.168.0.5:9999/foo                   Foo database on 192.168.0.5 machine on port 9999
        mongodb://192.168.0.5:9999/foo         Connection string URI can also be used

  File Names:

        A list of files to run. Files must end in .js and will exit after unless --shell is specified.

  Examples:

        Start mongosh using 'ships' database on specified connection string:
        $ mongosh mongodb://192.168.0.5:9999/ships

  For more information on usage: https://mongodb.com/docs/mongodb-shell.

To test connection:

% mongosh "mongodb://myuser:pass@mongo0.example.com:27017,mongo1.example.com:27017,mongo2.example.com:27017"
Current Mongosh Log ID: 6853ed1a745676a15bb62b1f
Connecting to: mongodb://<credentials>@mongo0.example.com:27017,mongo1.example.com:27017,mongo2.example.com:27017/?appName=mongosh+2.5.3
Using MongoDB: 8.0.8-3
Using Mongosh: 2.5.3

For mongosh info see: https://www.mongodb.com/docs/mongodb-shell/


To help improve our products, anonymous usage data is collected and sent to MongoDB periodically (https://www.mongodb.com/legal/privacy-policy).
You can opt-out by running the disableTelemetry() command.

------
   The server generated these startup warnings when booting
   2025-06-11T15:17:19.361+00:00: While invalid X509 certificates may be used to connect to this server, they will not be considered permissible for authentication
------
[mongos] test>

To test if this is a master cluster:

[mongos] test> db.runCommand({ isMaster: 1 })
{
  ismaster: true,
  msg: 'isdbgrid',
  topologyVersion: {
    processId: ObjectId('68499daa6d644d093f3230a7'),
    counter: Long('0')
  },
  maxBsonObjectSize: 16777216,
  maxMessageSizeBytes: 48000000,
  maxWriteBatchSize: 100000,
  localTime: ISODate('2025-06-19T10:58:20.543Z'),
  logicalSessionTimeoutMinutes: 30,
  connectionId: 7122158,
  maxWireVersion: 25,
  minWireVersion: 0,
  ok: 1,
  '$clusterTime': {
    clusterTime: Timestamp({ t: 1750330700, i: 1 }),
    signature: {
      hash: Binary.createFromBase64('2yaQ2MNlRYg3aXYhfRzQ4jxXIA0=', 0),
      keyId: Long('7511354796578701336')
    }
  },
  operationTime: Timestamp({ t: 1750330700, i: 1 })
}

To issue hello command (which returns a document that describes the role of the mongod instance): 

[mongos] test> db.runCommand({ hello: 1 })
{
  isWritablePrimary: true,
  msg: 'isdbgrid',
  topologyVersion: {
    processId: ObjectId('68499d52d772b382ee78bcc8'),
    counter: Long('0')
  },
  maxBsonObjectSize: 16777216,
  maxMessageSizeBytes: 48000000,
  maxWriteBatchSize: 100000,
  localTime: ISODate('2025-06-19T10:58:43.289Z'),
  logicalSessionTimeoutMinutes: 30,
  connectionId: 7126567,
  maxWireVersion: 25,
  minWireVersion: 0,
  ok: 1,
  '$clusterTime': {
    clusterTime: Timestamp({ t: 1750330723, i: 1 }),
    signature: {
      hash: Binary.createFromBase64('4en7J3oSF9fRGUUOHmkq4icWsOQ=', 0),
      keyId: Long('7511354796578701336')
    }
  },
  operationTime: Timestamp({ t: 1750330723, i: 1 })
}
[mongos] test>