WordPress on EC2 with DB in private LAN
We have all known and talked about a hybrid cloud solution to spill over an On-Prem infrastructure to cloud providers like AWS. Recently I had a need to do (a POC that needed) the same for my private lab where part of my software runs on the cloud while still communicating with the in house components.
The standard solution for this is to setup a VPN connection between your private lab and AWS. Only problem is that I don’t have a public IP available to setup the tunnels and also I am behind the ISPs NAT. So the VPN solution does not work for my case.
Hence I used SSH to setup the poor mans version of VPN tunnels.
The setup in detail
Basic idea is that you have a pair of tunnel host setup on the VPC and your private lab as seen in the figure below and use the tunnel to route traffic between the networks.
Setting it up
Following steps will bring up the setup.
- First start the pair of tunnel host one on the the Private LAN (TH1) another on VPC with a Public IP (TH2). These hosts will act as the tunnel gateway. I used Ubuntu based VMs for the tunnel hosts.
In our case the tunnel host on the private LAN will act as SSH client to initiate the tunnel connection.
- Update the SSH configuration file /etc/ssh/sshd_config on the server side (TH2) to allow creation of tunnels.
Note: SSH sessions are terminated if there are no activity for a certain amount of time. I found some help full suggestion to keep the connection alive, you can also read about it the sshd_config man page. Here is the gist of it
Update your SSH server (TH2) configuration with the following options
ClientAliveInterval 120 ClientAliveCountMax 720
Update Client (TH1) config ~/.ssh/ssh_config with the following
- Next setup the tunnels using SSH connections.
As the tunnels are setup using SSH connection so having a Public IP (TH2_Public_IP) on the AWS side is enough. Client side can reside behind the ISP provided NAT with no need of public IP. SSH connections are setup as root user.
On the client(TH1): # ssh -i AWS_SSH_KEY.pem -f -w 0:0 <TH2_Public_IP> true # ifconfig tun0 22.214.171.124 netmask 255.255.255.0 up
Similarly setup the tunnel host on AWS
On the server(TH2): # ifconfig tun0 126.96.36.199 netmask 255.255.255.0 up
- Check if you tunnel connection is up by pinging the tunnel IPs (188.8.131.52 and 184.108.40.206 from each other).
- Next setup routing on the tunnel hosts to connect the private lab to your VPC.
On the client(TH1): # route add 172.31.0.0/20 220.127.116.11 On the server(TH2): # route add 192.168.56.0/24 18.104.22.168
Here is the route table on the TH2 after update
- Then setup routes on the EC2 instances to redirect traffic to your tunnel host(TH2) on AWS using its Private IP (TH2_Private_IP) (can be automated using Systems manager).
On each EC2 instance on the VPC
# route add 192.168.56.0/24 <TH2_Private_IP>
Same changes updates needs to be done on the private LAN instances using the Private ip of the local tunnel host(TH1_Private_IP)
# route add 172.31.0.0/20 <TH1_Private_IP>
Although you can also update the route on the LANs gateway if you have access to if you don’t want to every individual host on your LAN.
Test application: WordPress on EC2 with DB in private LAN
To test my setup I ran a WordPress server on the AWS while my DB remained on my local LAN.
You will have to make MySQL/MariaDB listen to the all IPs on the machine, open up firewall rules to allow MySQL access on port 3306 and setup a db user and database with proper privileges.
Once done start an EC2 instance (I used ubuntu 18 image) on the VPC and make sure that you can connect to MySQL on the private LAN.
Also make sure that you add SecurityGroup rules to provide access to HTTP port for WordPress
Install WordPress on this host along with php and a web server (used Nginx). You should be able to use the private LAN IP of the MySQL server and complete the install.
and ons installed you should be able to use the WordPress app as usual.
This is definitely not a production type of setup. I set this up for my personal need to experiment. The tunnel depends on liveness of SSH connection, although we have increased the timeout the connection may drop if there is no communication beyond the timeout period.