Building “servers” in AWS is a funny play: one credential to access in multiple data centers spreaded across the globe, and few clicks to be able to launch instances… and you’re ready to deploy your application in a kind of Infrastructure as a service way in very few minutes, but with some differences from the classic model of consumption. In fact it’s a bit wrong talking about Virtual Machines in AWS environment for two reasons:
- similar to a virtual data center, the foundation is the same: CPU, Memory, NIC and storage; but the way to consume it is conceptually different: in AWS EC2 there are instances and every instance born to AMI (Amazon Machine Image: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)
- AWS doesn’t provide a full IaaS access (like vCenter and vCloud director), but has a plenty tools and services that literally move your perspective to another vision of cloud computing: you literally consume resources at code, and EC2 is only the beginning of the show.
But what will happen to the major part of the companies that are bringing public cloud as a complement for hybrid cloud solution in AWS? For VMware vSphere perspective going in cloud with AWS means buy resources that AWS dedicates for this purpose (actually you could move VM to AWS EC2). But if you want to extend your environment with AWS EC2 services, you should consider another way: extend your network.
The easiest way is establishing a VPN tunnel using VPC service in AWS… but I want to share my altenrative experience with my lab, using pfSense. Yet I don’t know if this could be applied in production environment due to connection performances…
My home-lab is realized with some VMs deployed in a nested ESXi 6.5 that is instantiated on my VMware Workstation Pro 14 installed in my DELL Latitude E5570 (Intel i5 vPro with 16GB RAM).
The role of AWS pfSense is build an openvpn tunnel with the on-premise pfSense that share the access to the entire local network, without using a public IP (other than my lab, in a lot of little and non IT companies, you could drive in the same situation).
AWS pfSense AMI and launch
First of all, start in AWS EC2 environment deploying pfSense instance from this AMI: Netgate pfSense Certified 2.3.2.
Then proceed with configuration and update process, connecting via web to the public ip or fqdn assigned to that instance:
- In the security group enable (and disable when is not necessary) the https inbound connection from your public IP or from 0.0.0.0/0
- Enable also:
- Inbound Port TCP 1194 from 0.0.0.0/0 (or better from your public ip) and the needed traffic in the whole network 172.31.16.0/20
- configure new password
- update to la last pfSense version (Note: every reboot must be executed manually in AWS console)
Now it’s time to configure openvpn server:
- Install openvpn-client-export package
- Create CA and Server self-signed certificate
- Create a user with or without certificate, depending on your preferred authentication method (I suggest to use client certificate)
- Use the following configuration options:
- Use TCP port 1194 (or UDP as you like)
- Use SSL/TLS Remote access or User Auth Remote Access (or both)
- CA and Server CA
- Certificate depth One (Client + Server)
- Use TLS Key
- IPv4 tunnel 10.0.8.0/24
- IPv4 local network 172.31.16.0/20
- Optionally permit communications with clients
- Insert a client customization to permit the traffic from “server” to “client”:
- Common Name: Use the user certificate CN
- IPv4 tunnel: 10.0.8.2/24 (or whatever except .1)
- IPv4 remote network: 192.168.56.0/24
Export the configuration to test your connection using openvpn client or similar (depending on your PC) and test a ping or ssh using internal connection.
Client Side configuration
The final part of the show could be painful even if you don’t copy CA, and other certificates and the key used in server communication. Use the following options in openvpn client configuration:
- Server mode: Peer to Peer (SSL/TLS)
- Protocol (the same used in server)
- Server hostname: ip address or FQDN of the AWS pfSense instances
- Insert the right authentication system (Key exchange and TLS Auth and/or username and password)
- IPv4 remote network: 172.31.16.0/20
AWS routing and networking checks
The last part is configure the routing that could be a classic route instruction in pfsense, but in AWS is important to act with the following steps:
- Under EC2 instance, choose actions then disable the source/destination checks under networking
- Under VPC, select the route table options, then insert the route to 192.168.56.0/24 to the instance ID referred to the pfSense instance
Now my local laboratory is connected to the cloud to realizing a low-cost hybrid cloud.