How to connect remote premises network to AWS network

Hi,

More and more companies are migrating infrastructure at Cloud solutions. Such migration requires a lot of time and resources. In most cases it can’t be done instantly within one day. As result, such migration is mostly done gradually, and some hybrid on premises-cloud architecture are existing within months or even years. Such a situation requires remote premises networks should be connected with cloud private networks, which appears to be not so pleasant in realization. This article explores common methodologies to connect a premises network to an AWS Virtual Private Cloud (VPC), focusing on Virtual Private Network (VPN) solutions, including AWS’s offerings and WireGuard as a cost-effective alternative. Though principles described below can be easily extrapolated at any Cloud. So, let’s start.

AWS offers several VPN solutions to securely connect your remote networks to AWS resources, such as EC2 and RDS instances, located in a private VPC. Two primary methods include:

AWS Site-to-Site VPN: Connects your on-premises network to an AWS VPC using IPsec VPN tunnels.
AWS Client VPN: Allows users to securely access AWS and on-premises networks.

Both AWS VPN solutions are robust but may involve significant costs and complexity in configuration and maintenance. If you tried to configure it – then you know what I mean 🙂

Reasonable question appears: Are any cost effective alternatives that would be easy to configure and maintain? At appears that such solution exists – it is WireGuard. WireGuard is an open-source VPN solution known for its simplicity, performance, and security. It is positioned as an alternative to traditional VPN solutions like IPsec and OpenVPN, offering a lighter, more efficient way to connect premises networks to an AWS environment.

What is WireGuard?

A modern VPN protocol using state-of-the-art cryptography.
Simple to configure, with smaller codebase, allowing for easier auditing and security.

Pros:

Cost-Effective: Free to use, reducing financial overheads associated with commercial VPN solutions.
Ease of Configuration: Straightforward setup with concise configuration files.
Performance: Designed to be lightweight and fast, with minimal latency.

Cons:

Requires Management: While the setup is simple, ongoing management and updates are user responsibilities.

Here’s a practical guide on setting up a WireGuard VPN between two nodes, which can apply to connect to an AWS EC2 instance.

1. Install WireGuard:

sudo apt install wireguard

2. Generate Key Pairs for Both Nodes:

wg genkey > privatekey

3. Derive Public Keys from Private Keys:

wg pubkey < privatekey

Save public/private pairs for every node somewhere, lets assume we save them as: private_key_node_1, public_key_node_1, private_key_node_2, public_key_node_2

4. Configure WireGuard Interfaces:

On each node, create a WireGuard configuration file (e.g wg1.conf).
Assign IPs (e.g., 10.0.x.y/32, 10.0.x.z/32), set ports, and specify peer information.

Node 1, e.g. EC2, configuration example:

[Interface]
Address = 10.0.21.2/32 
PrivateKey = {{private_key_node_1}}
ListenPort = 1197  

[Peer]
PublicKey = {{ public_key_node_2}}
AllowedIPs = 10.0.21.3/32
Endpoint = {{ ip_address_node_2}}:1197

# add more premises servers if you need it, using Peer section
# [Peer]
# PublicKey = {{ public_key_node_3}}
# AllowedIPs = 10.0.21.4/32
# Endpoint = {{ ip_address_node_3}}:1197

Node 2, e.g VM at premise network, configuration example:

[Interface]
Address = 10.0.21.3/32
PrivateKey = {{private_key_node_2}}
ListenPort = 1197

[Peer]
PublicKey = {{ public_key_node_1}}
AllowedIPs = 10.0.21.2/32
Endpoint = {{ ip_address_node_1}}:1197
# PersistentKeepalive = 25 - in case you need it - look at info below

By default, WireGuard tries to be as silent as possible when not being used; it is not a chatty protocol. For the most part, it only transmits data when a peer wishes to send packets. When it’s not being asked to send packets, it stops sending packets until it is asked again. In the majority of configurations, this works well. However, when a peer is behind NAT or a firewall, it might wish to be able to receive incoming packets even when it is not sending any packets. Because NAT and stateful firewalls keep track of “connections”, if a peer behind NAT or a firewall wishes to receive incoming packets, he must keep the NAT/firewall mapping valid, by periodically sending keepalive packets. This is called persistent keepalives. When this option is enabled, a keepalive packet is sent to the server endpoint once every interval seconds. A sensible interval that works with a wide variety of firewalls is 25 seconds. Setting it to 0 turns the feature off, which is the default, since most users will not need this, and it makes WireGuard slightly more chatty. This feature may be specified by adding the PersistentKeepalive = field to a peer in the configuration file, or setting persistent-keepalive at the command line. If you don’t need this feature, don’t enable it. But if you’re behind NAT or a firewall and you want to receive incoming connections long after network traffic has gone silent, this option will keep the “connection” open in the eyes of NAT.

5. Start the WireGuard Interface:

wg-quick up wg1

6. Persistent Configuration to ensure interfaces start on boot:

systemctl enable wg-quick@wg1

Using AWS EC2 as a WireGuard Endpoint

An EC2 instance can act as a WireGuard endpoint if placed in a public subnet with a floating IP. This instance can relay/forward traffic to private network resources:

Security: Use AWS Security Groups to restrict access to EC2 instances.
High Availability: Switch the floating IP between instances using an AWS Lambda script to ensure continuous availability in the event of failure.

By implementing WireGuard, organizations can maintain secure connections to an AWS VPC without incurring the costs associated with commercial VPN solutions, while benefiting from a protocol known for speed and simplicity. Of course, all it makes sense it you are using EC2 instances for performing some useful work, and in addition you want to use them as proxy to private AWS resources. After migration is finished you may hide your EC2 at AWS private network.

Just several words in the end – it is not some theory. I’ve used current scheme at practice during 1 year migration to AWS cloud. Wireguard showed himself as non problematic cost effective solution, which indeed is easy to configure and maintain.

Hope you have found current article to be interest. If you are interested at AWS cloud, the same as I am, then, welcome to my Udemy courses, related with it:

Best regards